--- 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 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 Tables for data storage. This is recommended (over using Completions) because it means this same Table can be used across multiple apps, a critical characteristic of 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 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) The Orders table is the bare bones needed to drive visibility into your process. Some Table Record Fields 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 Functional Example the order status is set to OPEN* ### Required Fields **ID** (Text)- All tables need an ID column to uniquely represent each Table Record. In this use case we are using the order number as the ID. 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 Records (orders) can share a single Material Number. --- **Target Quantity** (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** (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** (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** (Linked Record) - Materials is a Linked Record field to the `[Materials]` Table. This field is intended to link materials required to complete this order to the parent order. This is also where the BOM for your assembly can be stored. Warning In this Functional Example, The `[Materials]` table is not being used. --- **Customer** (Text) - This field is a place to store customer names, customer IDs, etc. **Functional Example** **Functional Examples** are intended to explain the right approach to core Tulip use cases. Functional example applications cover the core applications, their underlying data models, and ways those concepts can be extended when combined with others. *Functional Example apps aren't intended to be run in production, but rather as tools to learn the underlying concepts needed to implement core Tulip use cases.* **Tulip Tables** **Tulip Tables** are a global location to store your production data. Tables are made up of Records (rows). A single can be accessed from multiple apps or stations at the same time. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Tulip%20Tables%20Overview%20-%20Feature%20Overview.gif) **App Completion** **App Completions** are a mechanism to store immutable data from a Tulip app. When an app is completed, all **Variable's** current values will be stored in the app completions tab. This completion data can be analyzed in **Analytics.** By default, after a Completion users will be brought back to the **Begin Screen** of your application. This behavior can be adjusted with other **Transition** types. **Composability** **Composability** in software is the concept that resources, logic, and assets can be reused throughout solutions. When this comes to Tulip, Compostability matters when developing apps and data architecture that can be used by multiple teams, facilities, and roles. **Linked Records** **Linked Records** are interconnections between multiple **Tulip Tables.** Fields in one Table can be mapped to another table. Linked records simplify traceability, genealogy, and data association for more advanced Tulip apps and app suites. **Table Record Field** **Table Record Fields** are single columns within a **Tulip Table.****![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Table%20Record%20Field.gif)** **Table Record** A **Table Record** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from with an App Trigger. To edit a record it must be loaded into a **Table Record Placeholder.** **Table Record** A **Table Record** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from with an App Trigger. To edit a record it must be loaded into a **Table Record Placeholder.** **Number** **Number** is a Tulip Datatype. Numbers can be any positive or negative number. Numbers support decimals. *ex. -5, 15, 47, 155, 15.2, -12.73* **Datetime** **Datetimes** are a Tulip Datatype. Datetimes represent a time in the ISO8601 format. *ex. 2022-08-31T19:56:16+00:00* **Image** **Images** are a Tulip Datatype. Images are a reference to a web-hosted location for all Tulip Images. **Tulip Tables** **Tulip Tables** are a global location to store your production data. **Tables** are made up of **Records** (rows). A single can be accessed from multiple apps or stations at the same time. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Tulip%20Tables%20Overview%20-%20Feature%20Overview(1).gif) **Bill of Materials** The **Bill of Materials** is the list of items needed to complete an assembly.