In addition to a reference to the product in the catalog, the Shopping Item object contains additional data that it collects throughout the shopping journey. Sometimes the data is provided by a shopper, while in other cases it is calculated programmatically. So, let's look at all the steps in that journey and see what happens to the Shopping Item (SI) object:
- When a SI is presented to a shopper, the ecommerce system needs to determine the product's price. Depending on the sophistication of the system and the complexity of the online store implementation, this process can involve either a simple lookup based on its Product/SKU ID or a complex algorithm which finds a price in one of the price lists. (See my previous blog post "Why Prices Are Moving Out of the Catalog")
- After the base price is known, the system applies catalog promotions and discounts that the shopper is eligible for.
- Now the shopper has a number of decisions to make, and the Shopping Item object needs to keep track of the shopper's choices. The shopper may select different quantities and/or SKU options for multisku product. These choices, in turn, may cause price and discount re-calculation.
- There can also be dependencies between different Shopping Items when they are added to the shopping cart. For example, when a shopper buys a TV with a warranty, two Shopping Items are added to the cart. The TV SI needs to keep track of the dependent SI - the warranty. If the shopper changes his or her mind and deletes the TV item from the cart, the warranty item needs to be removed as well.
A Bundle is an interesting beast in that it deserves several separate blog posts. From one side, it is a product that has a name, attributes, and pictures. From the other side, it is a collection of products. When a Bundle is added to the cart, you need to create Shopping Items for both the Bundle itself and all the products it includes (Bundle Items). This needs to be done because, while you sell a Bundle, you ship Bundle Items.
You will discover all the power of Shopping Item objects when tasked with implementation of customizable products. For example, I created a custom t-shirt on the http://www.customink.com by entering text and uploading my picture.
Let's see how this can be modeled using the Shopping Item object.
An ecommerce system needs to store this information in the Shopping Item object, and be able to carry it through the checkout for the order post-processing. If you are designing a generic ecommerce platform that is used to sell a variety of goods and services, it would be a good idea to provide a generic mechanism for attaching a collection of custom data to the Shopping Item object. This will save a lot of time for developers who will be customizing your platform for a particular implementation. Custom data stored in the Shopping Item objects should not be limited to information entered by a shopper. You may find it useful to allow to store system generated data as well. For example, based on the customer's address and the product that was added to the shopping cart, your ecommerce software can determine the code of the warehouse that allocated inventory to fulfill the order. To record this information, you can add the code of the warehouse to the Shopping Item. Another example would be a store that sells installation services for its products. In this case, the Shopping Item should store the date and time of the installation appointment, and pass it to the IT system responsible for scheduling field technicians. Gift-wrapping instructions can be implemented in a similar way. As a Shopping Item object travels through the checkout, the system should also calculate each object's portion of taxes and the shipping cost. This information will be useful if at some point the customer decides to return or exchange the product, or one product out of a Bundle. The Shopping Item concept provides a very flexible model for Shopping Cart implementation.