Data integration¶

An integration is complete only when a planning process can identify each record, resolve its references, interpret its unit and time scope, and explain what was accepted or rejected. Receiving a file or request is not evidence that the data became usable.

Four connected data families¶

The families form a dependency chain. A sales record references a material, location, date, and unit. A Demand Plan references configuration and history. A Supply Plan references demand, network, policies, and an execution profile.

Contract of a data set¶

Every published data page should answer:

1. Path in Data: where a planner reaches the data set in the product.
2. Purpose: which decision consumes it.
3. Grain: what one row represents.
4. Key: how a row is uniquely identified.
5. Required fields: values that must be provided; they do not have a default.
6. Optional fields: values that may be omitted and, only for these fields, the default applied when not provided.
7. References: master or configuration records that must already exist.
8. Enumerated values: exact English payload values and their meaning.
9. Dependencies and used by: upstream requirements and downstream consumers.
10. Validation and reconciliation: how to prove the load is complete and coherent.

Defaults belong only to optional fields. A required identifier never receives a fabricated default.

Recommended preparation order¶

1. Create stable material, location, and unit identifiers.
2. Load unit conversions and planning characteristics.
3. Load network, production, and economic master data.
4. Load transactional facts such as sales, inventory, and open orders.
5. Configure clusters, execution profiles, workflows, and policies.
6. Reconcile counts, quantities, coverage, and reference resolution.
7. Execute a small controlled plan.
8. Compare the generated plan with known totals before expanding scope.

The exact sequence depends on the workflow. Demand Planning starts with Prepare the data; Supply Planning follows the physical data model.

Time and calendar¶

For every time-dependent data set, define:

• business time zone;
• date meaning: occurrence, document, shipment, receipt, availability, or period end;
• inclusive or exclusive cutoff;
• daily, weekly, or monthly bucket rule;
• closed-period policy and late-arriving data handling;
• historical correction and reload policy.

Do not aggregate records into a planning bucket before their date meaning is agreed. A shipment date and receipt date can belong to different periods because of lead time.

Units and quantities¶

Every quantity must be interpretable through a declared unit or a governed default. Conversions are material-aware when the business relationship depends on the item. Missing conversion is a validation error, not permission to mix units.

Reconciliation should compare source and accepted totals in both the source unit and the planning unit. Economic values also require explicit currency, valuation date, and gross/net interpretation when applicable.

Keys, updates, and duplicate control¶

A source identifier may be a natural transaction ID or a stable concatenation of business elements such as date, material, and location. The rule must remain stable across loads.

Before choosing replace, merge, or append behavior, document:

• unique key and duplicate policy;
• whether a repeated key updates or rejects;
• how cancellations and corrections are represented;
• how historical reloads affect already released plans;
• whether missing source rows mean deletion or simply no new event.

Transport-level retry and duplicate behavior are versioned API or file contracts. Do not infer them from the business key alone.

Validation layers¶

Structural validation¶

Checks required columns, data types, exact enum values, and parseable dates and numbers.

Referential validation¶

Confirms that materials, locations, units, profiles, network versions, and other referenced records exist and are valid for the row.

Business validation¶

Checks quantity signs, validity windows, eligible routes, production consistency, calendar boundaries, and other domain rules.

Reconciliation¶

Compares received, accepted, rejected, updated, and unchanged rows, plus control totals by period and key dimension. A successful HTTP response or completed import task is not enough.

Error contract¶

An actionable rejection identifies the data set, record key or row, field, received value, rule violated, and corrective action. Batch imports should preserve the accepted/rejected summary and make partial acceptance explicit.

Never hide an invalid financial or conversion input with zero. Zero is a business value only when the data contract defines it as such.

Operational checklist¶

• source owner and planning owner identified;
• cutoff, cadence, time zone, and service level agreed;
• schema version and enum values controlled;
• credentials and secrets kept outside files and logs;
• reference data loaded before dependent facts;
• restart and retry behavior tested;
• counts and quantities reconciled;
• a controlled plan validates downstream consumption;
• monitoring detects late, empty, duplicated, or unusually large loads.

Version boundary¶

File layouts, endpoints, authentication, pagination, retries, and transport semantics must be published with the executable version they describe. The data catalog describes durable business meaning; release documentation provides the exact transport contract.

Continue to Architecture, the data catalog, or the first Community workflow.