Re: [Zope-dev] the birth of ZCommerce
Just going to toss in my $1.50 w/inflation :-)
1) integration with accounting packages such as Quicken
Define an API, but don't specifically choose an accounting package. Deal with what the "use cases" are, rather than what Quicken expects. Quicken is nothing like what most companies use, with a full double-entry ledger system
2) secure transactions
Ah, there's the rub, this is a much more complex thing to do than it first appears. SSL is easy, but dealing with storage of credit-card information, and more so, delivery of goods via electronic means, is much more complex.
3) many of the features in packages such as Intershop
The first thing to tackle is whether this is US only or not, if not, then your tax issues just went through the ceiling. (I've had to deploy 3-4 instances of Open Market and Netscape Commerce Server) Taxation alone can require a HUGE database to back it up to do it correctly. Just wanna make sure you know how big the box is before you open it. Having said that, I'd love to see something down this road. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
On Tue, 3 Aug 1999, Christopher Petrilli wrote:
Just going to toss in my $1.50 w/inflation :-)
1) integration with accounting packages such as Quicken
Define an API, but don't specifically choose an accounting package. Deal with what the "use cases" are, rather than what Quicken expects. Quicken is nothing like what most companies use, with a full double-entry ledger system
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.
2) secure transactions
Ah, there's the rub, this is a much more complex thing to do than it first appears. SSL is easy, but dealing with storage of credit-card information, and more so, delivery of goods via electronic means, is much more complex.
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. My current line of thingking on e-commerece in Zope would be to provide a series of components, not necesaryily an integradted store. The things you would need are: * Some form of shopping cart object * Inventory control objects that can categorize items for sale but can come from different datasources ZODB, SQL, etc... * Credit Card Processor object *cough Wampum Generator cough cough* * And a way to do reporting (This makes my head hurt) Let the developers glue it all together. --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
participants (2)
-
Christopher Petrilli -
Scott Robertson