Re: [Zope-dev] the birth of ZCommerce
Josh Zeidner wrote:
2) Maybe we should agree on an accounting system to implement the API in ( Beachtree seems like a likely candidate ).
No, we shouldn't. We want this done the Unix fashion, where you have choice.
An unfortunate reality for anyone who has not spent their entire life mired in accounting is that you have to have a *starting point* for all implementations. To design an API in a vacuum is a foolish thing indeed. It is best to try and look at what one instance requires and make it as generic as possible. It is not unreasonable to choose a commercial product for this given the fact that I know of no "Open Source" accounting packages, and even if they did exist, I'd hazard they have market share measured on a single hand. This wouldn't be the most prudent method to grain a scalable API. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
With respect to "API" for ZCommerce At what level are you trying to interface with the accounting system? 1. Query inventory items, price levels by cust type 2. Query/Create customer record a. mailto/billto address b. ship to address c. tax rate at destination d. customer status 3. Submit post transaction data (double entry) a. credit a/r b. debit sales c. credit inventory d. debit cost of goods sold -- I think each one of these "steps" could/should be modularized and distinct. Though certainly in the post transaction phase some kind of customer number/id needs to be passed in.. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937
On Thu, 5 Aug 1999, Christopher Petrilli wrote:
Josh Zeidner wrote:
2) Maybe we should agree on an accounting system to implement the API in ( Beachtree seems like a likely candidate ).
No, we shouldn't. We want this done the Unix fashion, where you have choice.
An unfortunate reality for anyone who has not spent their entire life mired in accounting is that you have to have a *starting point* for all implementations. To design an API in a vacuum is a foolish thing indeed. It is best to try and look at what one instance requires and make it as generic as possible. It is not unreasonable to choose a commercial product for this given the fact that I know of no "Open Source" accounting packages, and even if they did exist, I'd hazard they have market share measured on a single hand. This wouldn't be the most prudent method to grain a scalable Well, there is something called Kantor, done in Java and being GPL. It's done by some German company, but I'm not sure how far advanced they do.
What they did have last time I've checked (last year), was a sensible table layout :) (I didn't look for the Java stuff, I'm not the biggest Java fan on this planet ;) ) Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
participants (3)
-
Andreas Kostyrka -
Brad Clements -
Christopher Petrilli