Ben, your order process is similar to the project I am working on. I need to contend with constantly changing prices and stock levels. In my case, suppliers are required to keep the website up-to-date. I believe that I will need to provide some kind of xml based remote update capability for suppliers, in addition to a web interface. I assume that customers will want products that are not completely specified, or even listed on the website, or products which are listed, but don't have a current supplier. Another capability that will find it's way into this system at some point is a shipping cost calculator. I'm not sure exactly how this will work yet, but at least UPS and FedX will be included. Shipments are separate from orders, and are applied to order items.
The Merchant System also assumes a high degree of customer/merchant interaction. I am more interested in automating the maintainance of the website and less intersted in automating the complete order process. Human interaction is required and desired for effective selling. What the merchant system is going to provide is a hopefully simple framework that can be expanded easily to satisfy the specific needs of a particular merchant.
In thinking about travel, this is a very complex set of products. I am guessing that a product could be something like 'round trip to Boston from St. Louis'. So this description could go into the products table. Several suppliers could offer 'stocks' that satisfied this 'product' in various ways. Each stock can have a separate description and price. In this case, the time and carrier might be what distinguishes the different stock items. Customers can search first for product and then list available stocks. In my case, I will probably not have separately listed prices, unless the quality of the stocks are different (used, referb, new ). Right now orders are placed by submitting a purchase order (order template). The order template lists only products. At the time the template is converted into an order, the stocks will appear and the user can select which stock, and set the quantity.
Something that might be nice for supporting corporate clients is that 'customers' are assigned things like credit, etc. whereas users are assigned to customers. Each user is assigned an appropriate privilege level that applies to the customer objects.
What I don't know is when this will be available for release as a package. It took me quite a while to organize my query-writer package which I will release this week, after OACS4.5 gets out, and it is a relatively simple package.
One thing I am currently struggling with is how to elegently extend the attributes of products. I thought I could use the content repository, but it looks like the external attribute table needs to be a table whose primary key references the content_revisions table. Also, this table is going to be just as difficult to extend as the current product table. So what I was thinking is a skinny table. With a wide array of product types, each with different relevent attributes, this might be more extensible. Maybe this table could then reference the cr table? Does anyone have an idea that would help me get a grip on this whole cr thing? I would like to come up with a simple interface to create new attributes, and make it easy to edit the product template to display these new attributes. Attributes could be things as diverse as manufacturer links, to product manuals. Probably I am thinking about this incorrectly.
