Initial Load & Load Order
The order of a first full load, waiting for each step to complete, and keeping GAINS current afterwards.
The first time you connect a system to GAINS, you load everything it holds, kind by kind. This page gives the order to load in, how to wait for each step, and how to keep GAINS current afterwards.
Why order matters
Records refer to each other: a SKU-location names an item and a location, a sales order names a customer and a ship-from location. GAINS checks those references while it loads a task, and refuses a record that refers to data it does not hold yet; see Rejections while loading. Load what other records refer to first.
Load order
| Step | Load | Subjects |
|---|---|---|
| 1 | Master data | SKUs, locations, customers, vendors |
| 2 | SKU-locations | SKU-locations, after the SKUs and locations they combine |
| 3 | Sourcing and product structure | Vendor alternatives, vendor constraints, bills of material, supercessions, SKU-location alternatives, price breaks |
| 4 | Inventory and supply | Inventory availability and lots, supply transactions, work order components |
| 5 | Transactions | Demand transactions, usage transactions |
| 6 | Planning inputs | Demand events, imported forecasts, leading indicator inputs, calendar overrides |
Each subject's endpoint is listed in Inbound Subjects.
Wait for each step
Each kind of data loads on its own schedule in GAINS, so a task accepted after another can still be loaded before it. Before you submit records that depend on an earlier step, wait until that step's tasks are Completed:
- Submit every batch of the step, one after another, and store each
TaskId. - Follow the tasks until they are final, by polling or with the
TaskStatusUpdatewebhook; see Following a task. - Check each task's
Batch.RejectedRecords, correct the refused records and submit them again before you move on. A record refused here, such as a location, would cause every record that refers to it to be refused in the next step. - Start the next step.
Within a step, watch for records that name another record of the same kind: a location's ParentDefaultCode, for example, names another location, so load parent locations in an earlier batch. How to handle each batch, from submit to loaded, is in Load Throughput & Retries.
After the first load
Once the full load is in, send only what changes: new and changed records, in the same order when a change touches several subjects (a new item and its SKU-locations, for example). Remove records with the delete endpoints; see Deleting Data.
Vendor constraints are the exception: each submit replaces the whole set, so always send it complete; see Vendor constraints.
Related
- Loading Data: sending a batch and the submit responses.
- Inbound Subjects: every inbound endpoint and its task type.
- Integration Tasks: following a task to its final status.
- Load Throughput & Retries: batch sizing and pacing large loads.
- Rejected Records: correcting refused records.
Updated about 18 hours ago