Fundamental to digital / physical agreement is confirming that your data objects correspond to the physical objects that you are working with. For example, as a Third Party Logistics (3PL) company, when evaluating a Warehouse Management System (WMS) or Order Management System (OMS), one of the first things we look for is the notion of a Company or a Catalog within the system – a Data Object that will correspond to the fact that, as a 3PL, we have more than one client (hopefully) under roof, each with their own sets of items, orders, configurations, etc. It’s not sufficient to have Company or Catalog be an attribute of an order and/or an item. We need Company or Catalog to be an object in its own right, allowing for its own appropriate sets of attributes and methods on the Company/Catalog-level.

It’s also important to be thorough in declaring new Data Objects when something might appear to merely be an attribute. In our work, one of the areas we see this in high resolution is the distinction between Orders, Shipments and Shipping Containers.

We receive Orders from our Clients. The OMS associates Orders with a given Client and their Product Catalog of Items. In addition to its header information (sender, recipient, catalog, ship method), an order has Order-Item information – instances of Items from the Client’s Product Catalog. These Order-Items both inherit attributes from its associated Item and also carry Order-specific information for that given item – maybe a sale price or a revised description.

Orders allocate in our OMS when there’s sufficient inventory in our WMS to fulfill the order. The Order Allocation process in our OMS creates one to many Shipping Orders for a given order. An Order might have more than one Shipping Order for any number of reasons – perhaps some lines of the order are in stock while others are backordered, so you ship-ahead the Order-Items that are ready to go; or maybe some lines qualify for media mail and others are better suited for a light-weight shipping method – Ship Method is actually a Shipping Order-level attribute. An Order could have multiple Shipping Orders each with a different Ship Method.

Our OMS hands its Shipping Orders off to our WMS where the corresponding Data Object is called a Shipment. Just as an Order can have one to many Shipping Orders/Shipments, so, too, can a Shipment have one to many Shipping Containers. As a consumer, you see this when UPS delivers a set of Shipping Containers and the Ship Label has 1 of 3, 2 of 3, etc. The tracking number / label, then is an attribute of the Shipping Container, but, also, a Shipment might have a Master Tracking Number which is then a Shipment-level attribute. Postage, Weight, Dimensional-Weight is an attribute of the Shipping Container, but Total Postage, Total Weight, etc would be a Shipment-level attribute. At the same time, it’s not sufficient to take the sum of the weight of the Shipping Containers for a given Shipment and do a Rate Table lookup – the lookup must happen on the Shipping Container-level, and the summation is the summation of the Rate Table calculations for each discrete Shipping Container.

Finally, it’s important not to lose this resolution as you report activity back up the chain of your data objects. For example, consider an Order where your Client’s Customer ordered two collectible figurines and two vinyl LPs. The figurines are over-sized and are already packaged each in its own shipping container. The Order allocates in 2 Shipments – one for the figurines shipping UPS Ground and the other for the LPs shipping Media Mail. The figurines containerize separately resulting in two Shipping Containers, each with their own UPS tracking number, and the two LPs ship together in the same Shipping Container with one Media Mail tracking number.

What’s needed, then, is for our the message chain all the way back up to the Order to handle the reality that an Order with a “Standard” Shipping Method and two lines of Order-Items resulted three Shipping Containers with two Ship Methods among them, in the case of one of the lines, splitting a qty 2 Order-Item line into two qty 1 Shipping-Container-Item line, each with its own tracking number. The correct, informed understanding of the physical flow in our warehouse allows for correct, well-architected Data Objects that maintain the required resolution of information up and down the chain of Data Objects.