Define product/order data models
-
Create product model -
Create order model -
Create order cost model (snapshots costs into an order) -
Create product cost model, attaches to product
Products
- Break products down into their parts (company, name, details, ...)
- Define a way to attach variant information (stock numbers, location, etc) to each product such that products are mostly static and data about them is what changes
- Define product variants..."Red Rhino tshirt" is the product, the variants are S, M, L, XL...
- "Effort" values apply to variants
- Variants hold the physical attributes (solid, liquid, unit of measurement, dimensions, etc)
- The idea is you might have "89 octane gasoline" product, then a "89 gas 5gal container" or "89 gas by the liter delivered by tanker semi"...same product, physical attributes attached to variants.
Orders
- Orders connect two companies (a third if shipping is involved)
- Orders operate on product variants, not products
Orders are not just the intent, but also the event that triggers the attachment of the disaggregate "costs" of inputs, labor, etc onto the products as a function of that order. In other words, I order 10 widgets, once those widgets are complete, the order doesn't just describe the 10 widgets, but also the inputs, labor, and other costs associated with those widgets attached to each widget such that each widget will have 1/10 of all the data attached to it.
This way, orders are a "freeze frame" of those products and memorialize the data making up their production.
Shipping
Moved to issue #19 (closed) (and punting until after v0.1)
Models should reflect the anarcho-communist principles of this project, not the Basis <--> market interfacing (in other words, we are building this assuming the entire economy is using it and markets are no more).