Receiving goods at store level: checking the delivery against the order

Store operations · 7 min read

Receiving is where inventory accuracy is won or lost. Every quantity posted at receiving becomes the system's truth — it drives what the store can sell, what replenishment calculates, and what the next stock count is compared against. Post what the paperwork says instead of what actually arrived, and the error is baked in until a count finds it months later. The receiving routine below is built around one rule: check the delivery against the order first, post second.

How receiving works in LS Central and Business Central

In LS Central's Mobile Inventory app, receiving runs on a Retail Receiving document. Since LS Central 15.2, that document is automated: once a Retail Purchase Order has been created and released, the Retail Receiving is created automatically from the action in the Mobile Inventory app. The store flow is short: open Receiving Menu All from the Main Menu, go to Receive PO, open the Retail Receiving in the list, enter the quantity received for each line, and tap Send. Back in the system, the receiving line is updated with that quantity; then Confirm and Post, and the posted document can be verified in BackOffice.

Underneath, Business Central purchase orders carry the receipt arithmetic. A receipt is recorded in the Qty. to Receive field, and posting updates Qty. Received. On a partial receipt, Qty. Received stays lower than the ordered Quantity — the remainder stays open on the order for the next delivery. Purchase orders are the document to use precisely because they support this: recording partial receipts of an order quantity, for example when the vendor does not have the full quantity available. One boundary to know: where warehouse handling is in use, the receipt is not posted from the purchase order — a warehouse employee posts it through the warehouse flow instead.

Stores also receive inside LS Store Inventory, which handles store-specific inventory processes — including Purchase — in a single worksheet, with multiple users able to work in the same worksheet at once. Whichever surface is used, the discipline is the same: the document proposes what was ordered; the person at the door records what arrived.

What arrives vs what was ordered

The receiving procedure

1. Start from the order, not the boxes. Open the receiving document that matches the delivery — the Retail Receiving for the released Retail Purchase Order in the Mobile Inventory app (Receive PO), or the purchase order itself where receiving is done in Business Central. Receiving without the order open turns the check into a guess.
2. Check the delivery note against the order first. Before any system entry, compare the carrier's delivery note with the order: same order reference, same number of cartons. A delivery for another store, or a note that does not match the order, is resolved at the door — not in the stock records.
3. Count and inspect line by line. For each line, count what is physically there and check its condition. Enter the quantity that was actually received — in the app, on the Retail Receiving line before Send; on the purchase order, in Qty. to Receive. Never copy the ordered quantity down the column and adjust later; later rarely comes, and the posted receipt becomes the record.
4. Stop on discrepancies while the driver is still there. Short, over, wrong and damaged are handled per the table above, while the goods and the paperwork are both still in front of you. Note the discrepancy on the delivery paperwork before signing.
5. Send, confirm, post. In the app: Send the quantities, then Confirm and Post the Retail Receiving. On a purchase order: Post the receipt with the Qty. to Receive values set. The moment of posting is when quantities become stock — everything before it is checking, everything after it is correction.
6. Verify the posted receipt. Confirm the posted document in BackOffice: quantities received match what was counted, Qty. Received on the order moved by exactly the delivered amounts, and any balance still open is a real expected delivery — not a line that was received but never recorded.

Short, over, wrong and damaged: the decision rules

Short deliveries are normal, and the system expects them. Partial receipts are standard behaviour: enter the actual quantity, post, and the remaining quantity stays open on the purchase order for the next delivery — the same receipt flow is simply repeated when the balance arrives. The error to avoid is receiving the full ordered quantity to "close the order" and planning to fix it when the rest arrives; that books stock the store does not have and can sell.

Over-deliveries are a vendor decision. Business Central handles an over-receipt through the Over-Receive field, and only where the vendor is set up to allow over-receipts. If the store did not order it and does not want it, it is not received — accepting it silently inflates stock and, eventually, the bill. LS Central has a related behaviour worth knowing at the receiving screen: a Retail Receiving created over the receive quantity turns the posting action into a return, and a Retail Purchase Return Order is created automatically. Quantity entry at receiving is never just data entry; it decides which document the system posts.

Wrong and damaged goods never enter stock as ordered. Receiving a wrong variant against the ordered line corrupts two records at once — the ordered item shows stock it does not have, and the delivered item exists physically but not in the system. That pair of errors is exactly what later surfaces as a count difference with a surplus next to a shortage. Keep data clean at the door: unknown or mismatched goods are not entered until they are identified and resolved, because a process downstream cannot fix data it does not know is wrong. (The counting side of these errors is covered in stock counting and physical inventory.)

What success looks like

• Every posted receipt matches a physical count made at the door — quantities entered are counted quantities, not copied order quantities.
• Partial deliveries show as partial: Qty. Received is below Quantity exactly where the vendor short-shipped, and the open balance is expected, not forgotten.
• Over-deliveries were either accepted deliberately through the over-receipt handling or returned — none were absorbed silently.
• The posted receiving document verifies in BackOffice against the delivery note, discrepancies noted, the same day the goods arrived.

FAQ

The vendor short-shipped. Receive the full order and adjust later? No. Enter the actual quantity in Qty. to Receive and post the partial receipt; the balance stays open on the order and is received when it arrives. Receiving stock that is not there creates sellable inventory out of nothing.

More arrived than was ordered. Just receive it all? Only if the store accepts the excess and the vendor is set up to allow over-receipts — the excess goes through the Over-Receive field. Otherwise the excess is refused or returned, not posted.

Why not fix receiving errors at the next stock count? Because until the count, the wrong quantity drives sales availability and replenishment — and the count then has to disentangle a receiving error from genuine shrinkage. Checking at the door is minutes; unwinding it later is a project.