Assign ownership before connecting feeds
A retailer may have a point-of-sale system for sales, a warehouse management system for physical handling, an order management system for customer commitments and an enterprise resource planning system for purchasing and finance. None is automatically the authoritative source for every field. Decide which system owns each product attribute, stock movement and reservation rule.
A useful ownership register names the source, responsible team, permitted updates and reconciliation process. If two systems can independently overwrite the same available-stock balance, a faster connection may simply spread disagreement more quickly. Prefer clear event ownership and documented derived balances over an undefined promise of one universal source of truth.
Make the product and location records explicit
Product master data should distinguish a selling unit from a case, size or multipack. Record conversion factors and their effective dates. Keep discontinued items separate from deleted identifiers so historical sales retain their meaning. Location records should distinguish a store, its stockroom, quarantine and collection holding areas where the workflow requires it.
GS1 identifiers can help organisations exchange consistent references. Internal stock-keeping units, or SKUs, still need maintained mappings to the relevant GTINs and packaging levels. A shared number does not resolve every difference in description, condition or unit. Validate mappings before allowing them to drive automated orders.
Design for duplicate and delayed messages
Network retries are normal. An event should carry a stable identifier so the receiver can recognise a repeated delivery and avoid applying the same movement twice. This behaviour is often called idempotency. Merely attaching a new message identifier on every retry does not solve the problem if the underlying business event is unchanged.
Preserve both event time and processing time. A sale made during an outage might arrive after a later receipt. Its original occurrence time remains important for investigation and historical reporting. Specify how the system handles out-of-order events, returns received before a delayed original transaction, and corrections to previously accepted messages.
| Test | Expected check |
|---|---|
| Same sale delivered twice | One business movement is applied |
| Case of 12 received | Conversion produces 12 selling units |
| Unknown location code | Event is held for resolution, not silently discarded |
| Delayed transfer receipt | In-transit status remains traceable |
Reconcile even when every connection looks healthy
A successful application programming interface response proves that a request was handled according to that interface, not that the business quantity is correct. Monitor rejected messages, processing lag, duplicate rates and unresolved exceptions. Also compare meaningful totals: opening stock plus movements should reconcile to closing stock within the agreed scope.
Worked example A receipt of four cases, each containing twelve units, should add 48 selling units. If an integration adds four, its event count may still look correct: one receipt sent and one received. A quantity reconciliation and a unit check expose what transport monitoring misses.
Keep access and evidence proportionate
Inventory data can include staff identifiers, supplier contacts or customer-linked reservations. Minimise personal information in operational feeds and restrict access by role. A colleague who can investigate a count does not necessarily need authority to alter supplier bank details or export customer information. Separate sensitive permissions and log relevant changes.
ISO/IEC 27001 is a standard for information security management systems; ISO 8000 addresses aspects of data quality. Referencing these standards does not establish certification. The Information Commissioner's Office provides UK guidance on data protection. Use the relevant requirements to frame responsibilities rather than treating a standards logo as proof that a stock interface is safe.
Release changes in controlled steps
Start with one defined movement and a limited operational scope. Test valid events, malformed records, reversals, outages and recovery. Run a comparison period before switching off the previous control. Define rollback arrangements that prevent duplicate orders or lost adjustments when reverting to an earlier process.
Document what the team should do when data becomes stale. A visible timestamp and a clear temporary workflow are more useful than an apparently live number with no freshness guarantee. Review data quality with the people who receive, move and count stock; many integration defects are first noticed as an awkward task on the shop floor.
References: GS1 standards, ISO/IEC 27001, ISO and ICO guidance for organisations. This website does not claim certification or affiliation.