Positional Data Handling
The largest sets of fact data in the platform tend to be those that represent every possible item/location combination (such as prices or costs). To efficiently store and process these data volumes, a data warehouse technique known as compression is used to capture only the changed records on a day-to-day basis, effectively maintaining a “current position” for every set of identifiers, which is updated during each batch execution. The output of this compression process is called positional data, and the following functional areas use this method of data load and storage:
-
Inventory (INV and INVU)
-
Prices (PRICE)
-
Costs (BCOST and NCOST)
-
Purchase Orders (PO_ONORD) and Allocations On Order (PO_ONALC)
Positional data loads follow very specific rules and cannot be processed in the same manner as non-positional data such as sales transactions.
Table 8-12 Positional Data Rules
Rule | Explanation |
---|---|
Data Must be Sequential |
Positional data must be loaded in the order of the calendar date on which it occurs and cannot be loaded out-of-order. For example, when loading history data for inventory, you must provide each week of inventory one after the other, starting from Week 1, 2, 3, and so on. |
Data Cannot be Back Posted |
Positional data cannot be posted to any date prior to the current load date or business date of the system. If your current load date is Week 52 2021, you cannot post records back to Week 50: those past positions are unable to be changed. Any corrections that need to be loaded must be effective from the current date forward. |
Data Must be Seeded |
Because positional data must maintain the current position of all data elements in the fact (even those that are inactive or not changing) it is required to initialize or “seed” positional facts with a starting value for every possible combination of identifiers. This happens at two times:
|
Throughout the initial data load process, there will be additional steps called out any time a positional load must be performed, to ensure you accurately capture both historical and initial seed data before starting nightly batch runs.