Josh Zeidner wrote: <SNIP>

...

automated through the net. *Anything* that has to do with accounting should be the domain of the accounting system.

I tend to agree... Absolutely the worst place in a company to have redundant or inconsistent data is in accounting systems... unless you're the US Internal Revenue Service -- then you compute the average of the six systems... :^| Other comments have been made on this thread alluding that storage in an RDBMS is an answer. We've found *NUMEROUS* times with "Open-, RDBMS-backed solutions" that while the data are available for SELECTs and UPDATES that the table keys are generated in a proprietary fashion. Of course anything without a valid key is ether discarded or ignored. I know the vendors do this to keep incident-based support from losing money. However, the notion that you can report-all-day-long doesn't meet the requirement of having a fully e-integrated business. One package we used actually FORCED you to make a DDE call to generate the ID!!! BLECH, BLECH, BLECH. One of our biggest selling points for Zope is that people don't want the software to become their organization, they want their organization (at least the online part) to be manifest in some software. This is the design notion behind the Zope Portal TOOLKIT. We can't design The Portal -- what we can do is identify, through experience, recurring components and spend some infrastructure time developing and hardening those. For these reasons and consistent with other posts (Scott Robertson?) on this list I'd LOVE to see a ZCommerce TOOLKIT. If everyone writes their own primitive systems or, worse, writes their own monoliths, none of it will improve in the Zope Bazaar. If we all write using notions of toolkits the underlying components will get better and better over time. Don't know about you, but the notion of supporting my OWN cybercash adapter isn't too interesting... --Rob