Re: [Zope-dev] the birth of ZCommerce
Accounting packages are just wierd. How companies use them are even wierder. Getting a compnay (or their accoutants) to change accounting systems (le alone learn any new software) is a lesson in futilalty. Probally the best thing you can do is provide ways to export data, and pray. In other words this shouldn't be made a priority, although it would be a nice sell.
Thats is why we should offer an API and let the developers "hook" in whatever accounting software they want.
3) many of the features in packages such as Intershop
If you want to have some fun start the debate in the office wether you should store your inventory in Zope or a SQL database. Clearly both approaches have their merits but it all depends on the situation. I have yet to see an off the shelf integrated e-commerece solution that makes anyone happy yet.
Possibly NEITHER! (put that in your pipe and smoke it). Maybe the inventory info can come from our accounting system? That would be a feature not really offered by any existing commerce package- what most ecommerce packages attempt to do is EVERYTHING. What the aim of this project should be is to offer a way to sell products that live in an existing system( such as Quicken or SAP ) and allow the process of marketing/retail to be automated through the net. *Anything* that has to do with accounting should be the domain of the accounting system.
My current line of thingking on e-commerece in Zope would be to provide a series of components, not necesaryily an integradted store.
This seems like the natural OpenSource/Zope way to do stuff.
* Some form of shopping cart object
- you are correct sir
* Inventory control objects that can categorize items for sale but can come from different datasources ZODB, SQL, etc...
- you forgot the exterior accounting system.
* Credit Card Processor object *cough Wampum Generator cough cough* * And a way to do reporting (This makes my head hurt)
- this could be taken care of by the accounting software.
Let the developers glue it all together.
- thats what were here for. -Josh Zeidner Phylogenic Inc. _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com
On 3 Aug 99, at 18:44, Josh Zeidner wrote:
Possibly NEITHER! (put that in your pipe and smoke it). Maybe the inventory info can come from our accounting system? That would be a feature not really offered by any existing commerce package- what most ecommerce packages attempt to do is EVERYTHING. What the aim of this project should be is to offer a way to sell products that live in an existing system( such as Quicken or SAP ) and allow the process of marketing/retail to be automated through the net. *Anything* that has to do with accounting should be the domain of the accounting system.
I'd like to mention that Peachtree 2000 (don't wince) is essentially a double-entry accounting system that runs on top of ODBC, which could be MS Jet, SQL Server or Oracle based. This is the first "low cost" small business accounting system that I've seen that is open and extendable. The price: $99 Its fully multi-user LAN capable, blah blah blah.. Too bad we're using an older version that is based on Btrieve.. :-( Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937
On Tue, 3 Aug 1999, Josh Zeidner wrote:
Accounting packages are just wierd. How companies use them are even wierder. Getting a compnay (or their accoutants) to change accounting systems (le alone learn any new software) is a lesson in futilalty. Probally the best thing you can do is provide ways to export data, and pray. In other words this shouldn't be made a priority, although it would be a nice sell.
Thats is why we should offer an API and let the developers "hook" in whatever accounting software they want.
Possibly NEITHER! (put that in your pipe and smoke it). Maybe the inventory info can come from our accounting system? That would be a feature not really offered by any existing commerce package- what most ecommerce packages attempt to do is EVERYTHING. What the aim of this project should be is to offer a way to sell products that live in an existing system( such as Quicken or SAP ) and allow the process of marketing/retail to be automated through the net. *Anything* that has to do with accounting should be the domain of the accounting system.
Most high end accounting packages would use a SQL backend, I would presume.
My current line of thingking on e-commerece in Zope would be to provide a series of components, not necesaryily an integradted store.
This seems like the natural OpenSource/Zope way to do stuff.
Well yeah, I like to take other peoples ideas and claim that they're my own. That's a trick I learned from Paul :)
* Some form of shopping cart object
- you are correct sir
* Inventory control objects that can categorize items for sale but can come from different datasources ZODB, SQL, etc...
- you forgot the exterior accounting system.
It's been my experince that alot of companies will have some POS (That's point of sales) system and then have some other accounting system say MAS90, QuickBooks, or some retched little thing still running under dos. What I was thinking was just a MarketItems object (to steal from EMarket) that can be placed anywhere in the zope DB that provides a solid api for listing, adding, and removing inventory items. It can then be inherited from so that it can pull from a SQL db, use MS Com to talk to Quicken if possible, or pull information our of the stack of papers on my desk.
* Credit Card Processor object *cough Wampum Generator cough cough* * And a way to do reporting (This makes my head hurt)
- this could be taken care of by the accounting software.
There again, not all accounting packages process credit cards. If you check out the Wampum Generator (excuse me while I pat myself on the back) at www.zope.org/Download/Contrib you'll find a CyberCash connector that I just uploaded yesterday for Zope. Of course it dosen't compile under Windows yet, I don't have access to a windows compiler. --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
On Tue, 3 Aug 1999, Scott Robertson wrote:
just uploaded yesterday for Zope. Of course it dosen't compile under Windows yet, I don't have access to a windows compiler.
Would you like me to add it to "Zope for Windows" with a Zmake file to go with it? Alternatively, if it is "simple" just create a Setup file and then it is sure to be cross-platform. When I next release Z4W I'll add it but it is not a must for me. Cheers, Anthony Pfrunder
On Wed, 4 Aug 1999, Anthony Pfrunder wrote:
On Tue, 3 Aug 1999, Scott Robertson wrote:
just uploaded yesterday for Zope. Of course it dosen't compile under Windows yet, I don't have access to a windows compiler.
Would you like me to add it to "Zope for Windows" with a Zmake file to go with it? Alternatively, if it is "simple" just create a Setup file and then it is sure to be cross-platform. When I next release Z4W I'll add it but it is not a must for me.
That would be very cool. It's needs to compile against some precompiled libraries that you must download from CyberCash, www.cybercash.com. The currentsource already has a Setup file made for it. Unfortunatly I could not figure out how to make it detect that the certain subdirectories need to be built. The CyberCash libraries use encryption, so there might be that whole Crypto/Export issue to worry about as well. --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
Josh Zeidner wrote:
Possibly NEITHER! (put that in your pipe and smoke it). Maybe the inventory info can come from our accounting system? That would be a feature not really offered by any existing commerce package- what most ecommerce packages attempt to do is EVERYTHING. What the aim of this project should be is to offer a way to sell products that live in an existing system( such as Quicken or SAP ) and allow the process of marketing/retail to be automated through the net. *Anything* that has to do with accounting should be the domain of the accounting system.
Until there is an open-source accounting package, this should not be the only option. It should be a option. I do not want to have to depend on a proprietary accounting program to store my products in, even if does run on Unix. Or perhpas the accounting package may not be designed for this kind of thing. So the design should be such that it also allows the inventory to be stored in ZODB3 or in an SQL database. -- Itamar - itamars@ibm.net ----------------------------o----------------------------------------------o Sealingwax Greeting Cards | Trust? Ha! The US dollar is backed by ICBMs! | http://www.sealingwax.com | --Anonymous Coward, Slashdot |
participants (5)
-
Anthony Pfrunder -
Brad Clements -
Itamar S.-T. -
Josh Zeidner -
Scott Robertson