So, these are the notes we kept at the sprint today covering order / line item definitions and how the shopping cart relates to the order object. I'll try to boil this down into a set specification that's a little more easily consumable, but I'd love to get any feedback on what's below! Feel free to ask any questions so we can be sure to explain it fully in the spec.

Looking forward to tomorrow. : )

Defining an Order

Line items on the order: technically the same data structure, but categorized into header, product, and footer line items.

An order has meta data, addresses, line items, and comments.

• Top level fieldable entity; no bundles (i.e. multiple order types), but the entity system preserves the ability to add them via contrib.
• Serial numeric order ID and a merchant-defined order ID (alphanumeric, pattern based), like product_id vs. sku.
• Meta data (created, changed, creator_uid, customer_uid, etc.)
• Order status added as a default field, not deletable. Order states remain, defined in code via hook_commerce_order_state().
• Customer information added via default fields:
  • Primary e-mail
  • Billing address
  • Shipping address concerns: non-shippable, single address shipping, split shipping (has ramifications for line item display)
    • Core assumptions vs. packaged products; shippable products module that adds required functionality
    • We do want to preserve Ubercart's ability to hide unnecessary fields on checkout and order review
  • Line items
    • Defined as a fieldable entity
    • Inherent meta data (order_id).
    • Requires a merchant-defined ID (SKU, Coupon code), title, quantity (default values and visibility), and a price field.
      • Store the total price of the line item (qty. * unit price) to avoid rounding snafus.
      • Ex: Product line item;
    • Bojhan can figure out how to make it usable
  • Orders are versionable by default and any modification of the order should be logged w/ the equivalent of a "revision message" field; order comments will always be handled through the revision message. (Dreaming of a diff feature, woohoo.)

  Shopping Cart Relation to an Order

  When a product is added to the shopping cart, it is instantly saved as a new order. If an item is removed, delete the item from the order. If all items are deleted from the order, delete the order and provide a hook for modules to preserve any bit of data entered for reuse.

  A shopping cart when loaded needs to validate the product line items against the latest prices, availability, etc. Line items need to specify at what point they're saved; i.e. a discount line item doesn't need to be saved before an order is checked out, because discounts will be recalculated every time the order is loaded and persisting the potential application of a discount to a shopping cart order isn't useful.

  Shopping cart orders are identified by an order state / status. A cart is separate from an order by not having a merchant-defined order ID.

  We should ensure rel=nofollow on cart links (but we'll still have bot orders... perhaps contrib can take care of IP address / user agent exemptions).

  Orders will not be revisioned until checkout has been completed.

  When it comes to marketing, we definitely want to track customer interaction, including adding / removing items, discounts, final date of purchase, etc. Talk with fago about Rules integration for every significant action... let's mine this data!