--- title: "Order Tracking Data Model" slug: "order-tracking-data-model" updated: 2022-12-14T20:56:20Z published: 2022-12-14T20:56:20Z canonical: "support.tulip.co/order-tracking-data-model" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Order Tracking Data Model ## Overview Getting the data architecture right is critical to driving the right actions to improve your process. Data is never *one-size-fits-all* because the problems being solved are seldom identical. This {{glossary.Functional Example}} outlines the core *minimum* data model recommended for Order Tracking. Orders at a fundamental level are simple. They have a set of Attributes, and a set of inputs. The `[Orders]` table is where order 'metadata' is stored. The [Extending the Concept](https://support.tulip.co/docs/order-tracking-extend-the-concept) document goes into some ways this data model could be built on top of to drive even more value. ## Tables This application relies on {{glossary.Tables}} for data storage. This is recommended (over using {{glossary.Completion}}s) because it means this same Table can be used across multiple apps, a critical characteristic of {{glossary.Composability}}. This Application relies on a single `[Orders]` table. [Extend the Concept](https://support.tulip.co/docs/order-tracking-extend-the-concept) covers how this table could be combined with {{glossary.Linked Record}} to the `[Materials]` table to track dependent materials. ## `[Orders] Table` ![https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Orders.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Orders.png){height="" width="200"} The Orders table is the bare bones needed to drive visibility into your process. Some {{glossary.Table Record Field}}s are optional, and others really are required to maintain visibility into your operations. Keep in mind, these fields don't necessarily need to be populated by a person. Order information could come from an external datasource, or be inferred based on conditional logic. *ex. At the beginning of an order in this {{glossary.Functional Example}} the order status is set to OPEN* ### Required Fields **ID** (Text)- All tables need an ID column to uniquely represent each {{glossary.Table Record}}. In this use case we are using the order number as the ID. :::(Warning) (Warning) Record IDs cannot be used for multiple records, so if your process might have 2 orders with the same order number, we would recommend using a prefix or suffix to insure the record ID is unique ::: --- **Material Number** (Text) - The material number for this use case is the part number (or SKU) this order is producing. Because this **isn't** the ID field, multiple {{glossary.Record}}s (orders) can share a single Material Number. --- **Target Quantity** ({{glossary.Number}}) - The number of units required to complete the order. --- **Status** (Text) - The current state of this order. In our use case, orders move through 6 statuses: 1. NEW 2. RELEASED 3. IN-PROGRESS 4. COMPLETE 5. ON-HOLD 6. CANCELLED --- **Due Date** ({{glossary.Datetime}}) - Without a target date, prioritizing work can be a sizable challenge. --- ### Optional Fields **Material Description** (Text)- Any semantic information that might help your operators better understand what they are making. *For example - I don't know what PN-24136 is, but the Material description is "3/16x2" bolt", so I can act on the order* --- **Material Photo** ({{glossary.Image}})- An optional photo of the final product to be produced. --- **Final Quantity** (Number)- As the name implies, this is the final quantity of parts. The intention is this field could be used for a final part count by a quality department or shipping department before the order is shipped. --- **Unit of Measurement** (Text) - What is the unit to describe the material being produced? This field can be leveraged to inform if they are to make 15oz of product or 15 tons of product. --- **Type** (Text) - This is a higher-level categorization for the order that could be used to group orders. *ex. We always run printing jobs earlier in the week so the machines don't need to be cleaned twice, so all printing orders are given the PRINTING type so they can be prioritized first.* --- **Scheduled Manufacture Date** (Datetime) - When *should* this order be started to insure it can be delivered on time? --- **Manufacture Date** (Datetime) - When did manufacturing actually start? --- **Complete Date** (Datetime) - When was the order completed? --- **Current Location** (Text) - The current location of the order. Incredibly useful in larger facilities to insure finished goods can be found. --- **Materials** ({{glossary.Linked Record}}) - Materials is a {{glossary.Linked Record}} field to the `[Materials]` {{glossary.Table}}. This field is intended to link materials required to complete this order to the parent order. This is also where the {{glossary.BOM}} for your assembly can be stored. :::(Warning) (Warning) In this {{glossary.Functional Example}}, The `[Materials]` table is not being used. ::: --- **Customer** (Text) - This field is a place to store customer names, customer IDs, etc.