Product merchandise
Vespolina makes a conceptual difference between a product which is offered for sale and a product which isn't offered for sale. The former we'll be calling a Product and the latter we'll be calling a Merchandise from now on.
Why do we make this difference?
For starters it helps us to improve the typical product publication process. One can start with loading products from vendors (manually or automatically) without any risk of publishing them directly. Secondly it allows a company to have only a subset of products available on-line while having other products registered for inventory purposes. As a bonus you'll have a performance boost as only one needs to query published Merchandise instances. But there are more reasons why we make the split. Just read along.
Suppose you have a merchandise instance for a t-shirt which is available in black and white. Both types of t-shirts should be referenced with a different SKU for inventory and handling purposes. Do you really need two merchandise instances for both SKU? No, it would just clutter the data and make it harder to manage the merchandise offering.
Vespolina looks at it differently. A merchandise can reference one or multiple products and 'groups' them together. For instance in our example we would have one merchandise "t-shirt" for which each option is referencing a different product. The pricing information is maintained at merchandise level, dimensions of the goods are stored at product level.
Of course this just a simple case where one option references a product. It becomes more tricky if multiple product options need to be mapped to different SKU's. (eg. t-shirt small, color red in cotton -> TSHIRT-S-RED-2). A basic mapping mechanism will be foreseen (behavior to be determined).
Multiple merchandises can reference the same product. Typically this happens in multi-store environments where products are offered at different prices. A t-shirt might be offered in store A for 10 euro whereas the same t-shirt might be offered in store B for just 15 euro. Internally the product will be the same and therefor will have the same SKU for both stores.
By splitting up the sales related information into the merchandise object you can easily define different prices or even adjust product information (name, description, images) for each individual store.
Often a web store is just another sales channel. A local(physical) shop might want to increase their sales by offering products on-line. Prices are typically different between the physical store and the on-line store. Does this mean that the local shop needs two IT systems, one to track and manage sales orders from the physical store and another one for the on-line part? Although you might find this situation ridiculous this is often how things are.
Vespolina understands that e-commerce is not always the core business. In this case two sales channels would be defined. One for the physical store and one for the on-line store. Merchandise instances could be assigned to just one or both sales channels, potentially storing different prices for the same product.
In cases where you don't (yet) need this approach you don't want to go into the hassle of first creating a merchandise and subsequently linking it with a product. For that Vespolina should "abstract" the complexity in such a way that a product and merchandise instance is the same. (the merchandise instance will be updated when the product is updated).