Forum OpenACS Development: ecommerce: reason behind item-quantity-change design

Collapse
1: ecommerce: reason behind item-quantity-change design
Posted by Max Pakhutkin on 08/21/02 01:21 PM
I keep reading code and doing searches in the forums, but can't seem
to find an explanation for the reason behind the way the item quantity
change is implemented in ecommerce.

From what I understand, currently, when you add an item, a new row is
inserted into ec_items. I haven't found yet elsewhere in the code
where this design decision is exploited and I suspect the reason a new
row is inserted and not just a quantity field is incremented has to do
with the possibility of there being a need to keep track of customer
service actions on each individual item in the cart. However, that is
my guess and I am not sure it's correct.

I would appreciate it if someone familiar with the code could explain
the decision behind this design or point me to the code that utilizes
it.

The reason I'm interested is two-prong: 1) I am currently writing my
first shopping cart for a client in php and am basing it on ecommerce
(improving on it every chance I get though, with unlimited category
hierarchy and unlimited product attribute (such as style, grade, size,
etc) customizations, including an ability to specify a price for each
combination of such custom attributes, so far :)). 2) I am thinking of
creating an accounting package and/or prospect-tracking package for
openacs when I'm in any position to do so, being new to openacs and
tcl, and ecommerce is the most closely related to accounting package
that I could find.

Thank you.
Max.

Collapse
2: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Janine Ohmer on 08/21/02 08:08 PM
I have wondered this myself.  I came up with a potential reason for this once but I no longer remember what it was, and I remember thinking it was kind of lame back then.

My hunch is that it has something to do with the color/size/style attributes, which were added to the e-commerce package after it was already completed;  I'm guessing that someone thought it was easier to just add new rows all the time than check to see if the product with the options you wanted is already in the order.

Not a good reason, mind you, but the only one I can think of.

Ok, wait, here's another possibility - it probably makes partial shipments easier, since you can just mark each individual line item as shipped or not shipped and don't have to split up a single row.  But I haven't checked the code to see if it actually makes use of this.

If you figure it out, please let us know! :)

Collapse
3: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Bart Teeuwisse on 08/21/02 08:36 PM
Janine is right on the way (partial) shipments are handled in by the ecommerce package. Each individual item that has been shipped is marked as 'shipped' and its shipment_id is set to the ID of the shipment that it is part of.

The shipped items are marked by fulfill-3.tcl in ecommerce/www/admin/orders. Take a look at the whole series of fulfill-* files for a complete overview of how shipments are handled.

Collapse
4: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Torben Brosten on 08/21/02 08:39 PM
I have had nothing to do with creating this package, so can only share in my ignorance of the details.

Partial shipments, or perhaps shipments from multiple points may be a reason for this behavior. On some orders, one may have to ship from point A to point C, and other similar items from point B to point C. This happens, for example, when stock is distributed to multiple points for inventory, and then a single order requires fulfillment from multiple points.

In any case, I hope the behavior doesn't change, because it seems to be setup for anticipating many possibilities which might otherwise be more complicated to adapt to within the system.

Collapse
5: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Tom Jackson on 08/22/02 04:47 AM

The purpose of this is to track the item state. If you order more than one of something, a partial shipment could occur. After shipment, a partial return might also occur. The alternative is to complicate the data model. You would have to split the item into two rows each time a partial state transition occured. I once posted that you could bring an ecommerce site to a halt by ordering a huge number of any item, actually just placing a huge number of any item in your basket, which doesn't even require a user account.

In the merchant-system package I am working on, I use a single row until a split is needed. I would rather handle the complexity in one place instead of on every page of the checkout system as in ecommerce.

Collapse
6: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Max Pakhutkin on 08/22/02 01:56 PM
I tend to agree with Tom. Partial orders or returns on partial orders
are less likely to occur than a person ordering several items of the
same product. Plus a lot of fields are needlessly duplicated in
ec_items, wasting db space and making searches take longer (can you tell
I'm coming from a MySQL background? :)).

Tom, is your package in cvs? I'd dearly love to look at your code :).
I might be able to contribute a few ideas or even write some code too.

Max

Collapse
7: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Tom Jackson on 08/22/02 05:31 PM

I am working on releasing it. I have recently discussed this with Don. The requirements are that the package gets ported to Oracle. It is currently written for PostgreSQL.

Notes:

  • Merchant-System relies on Query-Writer for insert/update/delete operations. This has to be ported first to Oracle. It is available from http://multi.zmbh.com:8300/query-writer-0.5.3.apm
  • This package is about 240 files, with only a few .xql files, but the customer UI is very small and simple. My thought was that each site would want their own method of organizing the ui, I didn't spend much time on that part.
  • This package doesn't have an interface with a payment gateway. It should be easy to add because the coded doesn't really rely on how the order state change is triggered. This trigger pushes the order along.
Collapse
8: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Bart Teeuwisse on 08/22/02 07:58 PM
Tom, that is great news. I hereby volunteer to integrate Merchant-System with the payment-gateway. Can't help porting Query-Writer though as I don't have Oracle up and running.

/Bart

Collapse
9: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Tom Jackson on 08/22/02 09:19 PM

If there is no big rush, I am leaving on vacation today, back on Sept. 3. I can maybe set up an account on a working copy of the merchant-system, or somehow get you the code. Anyone interested, please send me an email.

Collapse
10: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Torben Brosten on 08/22/02 11:09 PM
Tom, thanks for showing a more appropriate way to handle split orders. This example serves to remind me of potential serious repercussions of using an inapporpiate data model.

Among other projects, later this fall I want to work on the openacs ecommerce/merchant code for integrating ecommerce merchants with distributor inventory/supply-chain-management systems --perhaps using the xml/soap implementation to handle import/export of data. At this point, for all I know, the concept may be redundant somehow by using the existing content management system. Anyway, I am looking forward to tapping the universal mind of the openacs.org community to prevent making poor programming decisions etc.

Collapse
11: Response to ecommerce: reason behind item-quantity-change design (response to 1)
Posted by Don Baccus on 08/23/02 01:25 AM
Actually, let me clarify my comment to Tom regarding release.

He's free to release it on his own in any way, shape or form he wishes to, of course.  And in fact I hope we'll put up a "user contributed" download repository on our new openacs.org site where folks can put up any OpenACS 4 package they want.  In its current state he could put it into such a (currently non-existent) repository if he wanted.

My comment was in regard to packages we might want to put up in our standard "this is really an OpenACS package" repository.  In this case I think we need to insist on dual RDBMS support, using the appropriate service packages that are available, etc ... the things Tom mentions.

Just to clarify so no one thinks I or anyone else is trying to place restrictions on what people release on their own!