Order / Lines Philosophy
This post relates mostly to Ubercart being able to be integrated with back-end accounting and ERP systems. Right now, there is not really a distinction between the properties of an order, and the properties of an order line.
IMO - here is what we should be thinking about.
An order is comprised of three separate parts:
- The order header
- The order lines
- The order footer
The order header
The order header is where all the information about who is placing the order goes. This would include the company placing the order (or the user... depending on how that's implemented). It would include the shipping address, the billing address, and any terms that are being given on the order (meaning a due date). It would also have any FOB information if applicable, and contact details.
The order lines
Order lines represent the "meat and potatoes" of the order. They're the individual lines that are each related to the order header. All of the information on the order header applies to each line unless it is specifically overridden at the line level (i.e. the shipping address for one line is different than the shipping address for the whole order). Each line retains its own identity independent of other lines, and the order as a whole, but it is linked via the common header.
The order footer
The order footer is dependent upon values in the order lines. It contains information like the total of the order, the total of tax, and the total of the freight. All of these are factors of what is actually in the order lines, and must be calculated based upon them.
What this allows is for a truly flexible ordering system that is capable of being integrated via an API into many back-end systems. First, having a common header allows for entities or objects like customers and users to easily be associated with an order without that order needing to exist first. In fact, there should be some master record for most of the data on the header, and that master data should be replicated (and even available to be edited) on each order.
Similarly, having order lines act independently allows for the partial fulfillment of orders, and the management of back orders by the system. Each line could have an open or close status based upon delivery, or an open and delivered quantity if a line is partially delivered. Additionally, it allows for things like freight an tax to be more easily tied to a line for costing and accounting purposes. It also makes multi-site capabilities easier, as well as the ability to do different things with different product classes that are part of the same order.
Finally, a footer is nice because it allows for another integration hook between the calculation of the value of the lines and the calculation of the value of the order total. For example, "Free shipping on orders more than $100 and free shipping on individual products of more than $30" is difficult to implement without footer functionality - you'd have to go back and remove/recalculate the freight line by line in a pretty dynamic way. However, if I have a footer sub-total, and a freight total, it makes it a lot easier. There are countless other examples of this being useful.
This is essential for integration to most systems. Almost every ERP at least looks at orders as a collection of lines tied to a header. Most do a one-to-many relationship between an order and it's lines in the DB as well. I'll see if I can dig up some good examples of this in product literature for ERP systems.
