Data sources

Four things can create a delivery in Goods Received, and three other services supply the data it needs to accept one. If receiving is not behaving as expected, the cause is usually in this page rather than in the receiving screen.

Where deliveries come from

Source	Who triggers it	Shipper recorded as	Typical use
GS1 import	An external ERP, OMS or WMS posts a despatch advice	businessPartnerId for a supplier, businessUnitId for another store	The main integration path — the supplier tells the store what is coming
Created in the store	Store staff, in the app	Always businessPartnerId	Goods arrived unannounced, or with a paper note the store types in
Completed store transfer	Another Hii Retail store completing a transfer	businessUnitId — the sending store	Goods moving between stores; no integration work needed

The first two are what most customers run. GS1 import carries the document from the system that shipped the goods; creating in the store covers everything that arrives without one.

GS1 import

An external system posts a GS1 despatch advice XML file to the import endpoint. The service parses it, resolves the receiving store and the items, and creates the delivery with its containers and lines.

This is the only ingress designed for machine-to-machine use. See GS1 import.

Created in the store

Staff record the delivery themselves — either because the goods turned up unannounced, or because they arrived with a paper note that nobody sent electronically. The delivery note is created first and its lines added to it, which mirrors reading a paper document, and works equally well when there is no document to read.

This is the route for the many suppliers who will never send an electronic document at all — a local baker, butcher or grower delivering daily. It fits them where GS1 import cannot, because containers are optional: a supplier arriving with no pallets and no SSCC labels is perfectly expressible, and one who does bring a labelled unit can have its id recorded so staff can scan it.

The shipper is always recorded as an external business partner on this path, so a store-created delivery is never mistaken for goods arriving from another store.

⚠ A delivery created this way must have a delivery date within the last 14 days. It is a guard against a mistyped date, where a wrong year or month is easy to enter and lands the delivery in the wrong accounting period.

The asymmetry with GS1 import is deliberate. An integration has to accept the date the sending system states — rejecting a supplier's own delivery note because we disagree with its date would drop a real delivery. Typing one in has no such constraint: staff are recording goods they can see, so there is no reason to reach for a date weeks in the past, and a date weeks in the past is far more likely to be a slip than an intention.

Completed store transfer

When a store transfer completes, Goods Received automatically creates a matching delivery at the receiving store, with the sending store as the shipper. Staff at the receiving end then verify and approve it exactly like any other delivery, which is what turns the transfer into an accepted quantity at the destination.

Nothing needs to be configured or called for this to happen, and re-processing the same completed transfer will not create a second delivery.

⚠ Lines created this way carry the transfer's unit price when it has one and zero when it does not, and a currency of NIL where the transfer carried none. Treat a zero price on a transfer-originated line as unpriced rather than as free goods.

Services Goods Received depends on

Service	What Goods Received asks it	What happens if the answer is missing
Product, Price and Promotion (PnP)	Resolve a GTIN to an item, and get the item's name	A GTIN-only line is rejected; a line that already carries an item id is accepted without a name
Business Unit Management (BUM)	Resolve a GLN to a business unit	The GS1 import is rejected — see below
Customer Controlled Configuration (CCC)	The reason codes valid for this store	Adjustments cannot be saved; see Configuration

Item resolution is asymmetric — and it matters

A delivery line can identify its item by item id, by GTIN, or by both. What happens next differs:

The line carries	Behaviour
An item id	Accepted. The item is looked up to get its name, but the line is kept even if the item is unknown to PnP
Only a GTIN	The GTIN must resolve to an item for that store. If it does not, the whole delivery is rejected

🛑 Send the item id if you have it. A GTIN-only import is only as reliable as the barcode data in PnP: an item whose barcode has not been set up for that store, or a supplier-specific barcode that Hii Retail does not know, fails the entire delivery rather than the one line. Sending the item id makes the import robust and costs the supplier nothing.

Store identity: register GLNs before importing

GS1 identifies parties by GLN (Global Location Number). Goods Received translates the receiver's and shipper's GLN into a Hii Retail business unit by asking Business Unit Management.

🛑 A GLN that is not registered against a business unit makes the import fail. This is the single most common first-day integration failure, and the error is explicit: the delivery cannot be resolved because the business unit for that GLN was not found. Register each store's GLN in Business Unit Management before the first import, or have the sending system send the Hii Retail business unit id directly (see GS1 import) — that skips the lookup entirely.

What Goods Received publishes

One event source, consumed both inside Hii Retail and by external subscribers:

Event source	Consumed by
grc.public.event.goods-received.v1	Stock services, and any external subscriber via External Events

See External Events for the payload, the delivery guarantees and how to consume it.