Treasure Chest 2: Scalability vs End user convenience.

Just to throw in my 2 pennies... I’ve worked with some large systems, specifically I’m thinking about Microsoft Navision. When you get into that stuff you start seeing inventory management, bundles or BOMs, stock keeping units, warehouse locations, fulfillment managers, cycle stock calculations with purchase reminders, vendors/suppliers, purchase orders, requisitions, etc, etc... I haven’t even mentioned how these things are married to your accounting system as well as your customer management system. This is just what I can remember off the top of my head without having the software in front of me.

My point is, it can get very complex. Some companies need that level complexity to function.

Others just need to know that they have 10 widgits, they sold 2 and now have 8 left.

Building a system that can easily expand or contract to handle both worlds would be pretty challenging. If you start building something to handle these types of challenges, I’d recommend having a very clear strategy on what you are and are not going to accomplish. Otherwise your customers needing a complex solution might be frustrated and your customers needing a simple widgit solution might also be frustrated but the middle of the road guys would be stoked... until they grow to want something more.

In the end, if your goal is to serve people and give them tools to help them build their business, you will do well.

Quote from: luke.stokes at Jun 28, 2008, 04:03 PM

Building a system that can easily expand or contract to handle both worlds would be pretty challenging.

There’s the understatement of the century I think!

Can this be used to also have a payment system for membership fees? It may have it already. I just have not looked through it yet, but if it does not have this option I think it would be very helpful if it could do this with WLPE.

Just to throw in my 2 pennies... I’ve worked with some large systems, specifically I’m thinking about Microsoft Navision. When you get into that stuff you start seeing inventory management, bundles or BOMs, stock keeping units, warehouse locations, fulfillment managers, cycle stock calculations with purchase reminders, vendors/suppliers, purchase orders, requisitions, etc, etc...

I’ve found that most established companies deploy their own ERP systems to manage their resources, and we rarely have the chance to spec the software that we are expected to hook in to for the customer facing web site. To my mind a ’general purpose’ ecommerce system shouldn’t try to replicate this functionality at all, rather it should have an extensive API to allow for easy integration, and be modular so it can be extended as necessary. If Scotty’s other work is anything to go by I have high hopes for this being the case with TC2.

Quote from: therebechips at Jun 30, 2008, 09:00 AM

To my mind a ’general purpose’ ecommerce system shouldn’t try to replicate this functionality at all, rather it should have an extensive API to allow for easy integration, and be modular so it can be extended as necessary.

Therebechips, I think you’re absolutely right. One app that suits all is not possible. For instance, when does someone want to update its inventory? After adding to cart, after payment, after shipping or keep no track at all since an external app takes care of it? An API function updateInventory($product,$quantity) can be built and the user decides when to call it. Maybe we could add events listeners here too, like onAfterPayment etc.

I just blew up my modx site by adding 20.000 dummy records to the documents table, so a separate table for the products it is! I also like the idea of mapping products to documents (that act as categories).
But therebechips, what do you mean exactly with putting the product options also in the documents table? How would you map that to products and create a view for it?

I agree with therebe, the best solution would be an ecommerce API with:
- onAddtoBasket
- onRemovefromBasket
- onAddtoCart
- onRemovefromCart
- onUpdateCart
- getShipping
- calculateTotalPrice
- calculateTax
- onBeforePayment
- onPaymentComplete

I think Ryan is correct that how the products are setup should be flexible. Some would want to use ditto and each product is a document, some would want to use an external db, some would want to use a module.

This would be a framework for developers to customize the cart. One place virtuemart has a good idea is their management for choosing shipping methods, taxes, discounts (tho the implementation is buggy), and I could see where a module for the global shopping cart configs could be populated would be nice (or snippet params, or even a parent doc with TVs).

I’ve not seen 2 shopping carts that have the same requirements- they’re like snowflakes and fingerprints. So a flexible, open API would be best.

Chuck

Quote from: ProWebscape at Jun 30, 2008, 06:33 PM

- onAddtoBasket
- onRemovefromBasket
- onAddtoCart
- onRemovefromCart

Chuck, what’s the difference in those two sets of events?

Also, I really think there needs to be some additional events centered around shipping, if that’s the ultimate way this would work. Probably an onBeforeShip and onShipComplete. That way you could send tracking numbers back to the client along with a final invoice, or do authorization captures, and actual processing of credit cards more in line with how Visa/MC say you should do it (only charge when the item actually goes out the door).

I agree with you that there should be some additional events, especially onBeforeShip, onShipComplete.

- onAddtoBasket
- onRemovefromBasket
- onAddtoCart
- onRemovefromCart

Chuck, what’s the difference in those two sets of events?

I was thinking onAddtoBasket is adding the products to the basket from the product page. And onRemovefromCart, onUpdateCart would be looking at the actual cart/checkout page. (onAddtoCart is probably not necessary).

I like the way this discussion is developing.

If I may generalize for a moment, and try to capture the highlights so far:

• Focus on API as a collection of loosely coupled, easily extendable modules
• Define a standard group of MODx System Events
• Don’t limit the end user by pigeon-holing into one paradigm

I guess the above list could be a "Mission Statement", so maybe that is a good place to start? Get the project goals in a list like this?

-sD-
Dr. Scotty Delicious, DFPA.

Quote from: ProWebscape at Jun 30, 2008, 08:01 PM

I agree with you that there should be some additional events, especially onBeforeShip, onShipComplete.

...

I was thinking onAddtoBasket is adding the products to the basket from the product page. And onRemovefromCart, onUpdateCart would be looking at the actual cart/checkout page. (onAddtoCart is probably not necessary).

An event based e-commerce system that totally ignores the catalog (how counterintuitive!) with some basic "modules" implemented would be super-yummy the more I think of it ...

I’d nuke the "basket" stuff personally, and just stick with a simpler and probably standard terminology. The following is a revised event/function list in progress, with descriptions and rough order of where they’d fall. Probably a bit overkill in spots and totally lacking in others, but just a quick brain dump:

[*] createCart - session or DB with expiration flag; could also be used for wishlists, wedding/baby registries, etc.
[*] onAddtoCart - putting something in your cart/basket, from the catalog
[*] onRemovefromCart - removing line items from the cart itself
[*] onUpdateCart - updating line items from the cart itself
[*] getCartLine - reference individual cart line items
[*] modifyCartLine - modify individual cart line items; useful for applying per-line qty discounts, trap for alternate shipping handling (e.g., drop shipped items), etc.
[*] calculateOrderSize - where total weight, price and piece count is calculated; could be used to calculate qty or dollar volume discounts, etc.; also for shipping estimates based on total shipping weight
[*] getShippingMethods - available shipping methods (per line item, taking inventory availability into account?)
[*] getShipping - determines shipping cost based on weight and shipping method
[*] onStartCheckout - moving from the cart/catalog into the checkout process; could be used to switch payment options based on customer type (wholesale vs. retail) or trap the cart to send to alternate checkout flows
[*] onBeforeCalculateOrderTotal - could apply coupons at this point, or calculate quantity/dollar based on iterating through each item via getCartLine (yes this provides multiple points to check for modifying cart line items, and multiple ways to handle discounting and promotions ... pick what works best for you)
[*] calculateTax - calls getCartLine to determine if tax applies to each line
[*] calculateTotalPrice - sums all product, shipping, handling, tax and any other items inserted at onStartCheckout or onBeforeCalculateOrderTotal
[*] onBeforePayment - trap for previous payment errors (e.g., offer to use a different card based on error codes) or insert other logic here
[*] onPaymentComplete - when payment or authorization processes finishes; could post to accounting system here
[*] onBeforeShip - event provided to modify shipping parameters based on logic and calling each getCartLine to determine costs based on logic (e.g. takes special shipping per line item into account); also could do rate shopping here, or splitting back-ordered items off to new orders
[*] shipItem - when item is paid for and optionally logged to the shipping system (could do the capture part of authorize and capture here)
[*] onShipComplete - immediately after shipping, includes tracking information; could post to accounting system here, too if it suits our business better