Discussions

Root level entities and systems notes

Irreducible complexity: the components without which we do not have a coherent whole or which we need to develop other essential systems.

Root level entities:

  • Product - a product is anything that can be added to an order (but there is other stuff that can be added to an order, too).
  • Order -> Cart / Invoice, made up of Line Item
  • Price
  • Address (external)
  • Payment (collection / receipt)

Root level systems:

  • Inference engine
  • Cart / checkout
  • Price handler
Ryan Szrama
Ryan Szrama
Posted: Oct 16, 2009

Comments

redben on October 31, 2009

I don't know if this is the riht place to comment on this but...here it is
Can we imagine having a flexible way to setup product units. I mean having a unit of measure. For example
- a unit for goods (T-shirt) is item. default
- for a service, this would be hour
- For a vegetables web site that would be pounds/kg
It basically would be what answers the question "what do you track in your sales ?"

Just to let you know, i'm working on a travel website using UC, and on the cart i can have an item "Room stay at Hotel XYZ" with quantity 2. For this, a customer can hardly tell if it's 2 Rooms or 2 night at one room.
I have even seen some travel websites do not use quantities explicitly...

Also, this has been brought up by the community here and there ; payment plans / conditions.
This might be just an api that lets others contribute "Payment plan types/engines"
From the top of my head i can think of the following:
+ Paid in full at checkout - default
+ Paid at delivery
+ Prepayment at chekout
- Based on quantity
- Based on percentage
+ Scheduled payments (recurring fee) (thinking of a subcription product which quantity unit is months)

This would add info on the order that specifies the payment plan/conditions

Ryan Ryan Szrama on November 1, 2009

Yep, with products being a fieldable entity, you can create "bundles" in Fields API lingo which amount to different "product classes." We'll be able to do with products what you're already able to do with node types.

redben on November 26, 2009

Sorry for getting back to this so often :p
how do you expect the whole product model would be ?
Take this basic example :

  • Product type T-Shirt
    • Product line Halloween T-Shirts
      variations:
      • - Halloween tee Black XL
      • - Halloween tee Blue XL
      • - ...

Which of these three levels is an instance of product entity (the deepest one, i think!). Which is the Product class (meaning content type/bundle type). Finally, how would you define the third ?

My thoughts

are that level one (T-shirt) is the bundle type or product class. And that level 3 (variation) is the product instance.
Level 2, is just a logical (business) grouping for handling common properties (what are they?) of variations.

Another way of seeing it

Another way would be to make bundle type as level 2, variation as level 3 and for level one a kind of template that helps define bundles. But then again, one bundle type per product line...may be that would be too much...
How do you see things ?