Number series for retail documents: receipts, statements, and orders that never collide

Configuration · 8 min read

Numbering looks like housekeeping until two stores reach for the same number at the same time. In a retail business the pressure is constant: terminals create receipts all day, staff calculate statements at close, and the back office raises orders, invoices, and credit memos in parallel. If those document families share one casual series — or several series with overlapping ranges — the result is duplicate-number errors, blocked posting, and numbers nobody can trace back to a store. The fix is not a cleverer prefix. It is a deliberate series map, built before anyone creates a single code.

Why retail numbering collides

Business Central uses number series to create unique identification numbers for master records such as customers, vendors, and items, for sales and purchase documents such as orders, invoices, shipments, and receipts, for posted documents, and for journals and journal batches. That breadth is the trap: one mechanism serves everything, so a setup that works for a single back-office user gets copied for high-volume retail documents without anyone asking how the numbers behave under concurrency, deletion, or a year-end range change.

Three collision patterns account for most of the damage. First, two document families draw from one series, so an order and a posted invoice compete for the same sequence and the audit trail becomes unreadable. Second, two series have overlapping starting and ending ranges, so each looks fine alone and collides as soon as both are in use. Third, a strict no-gaps series is applied to a working document where lines are routinely deleted: the reserved numbers block the next step instead of protecting anything. Each pattern is a design decision made early — and each is avoidable on paper.

The building blocks Business Central gives you

Number series are first set up on the No. Series page. Each series carries a Code and a Description. The values that actually hand out numbers live on the underlying No. Series Lines: a starting number, an optional ending number, a starting date, and an Increment-by-No. — commonly 1, so each new record gets the next number. The No. Series page shows the starting and ending numbers, the last date used, and the last number used from whichever line is currently applicable according to the work date. That last detail matters: a series can hold several lines, for example one per year, and the work date decides which line is live.

Two switches on the series control behaviour. Default Nos. specifies whether the series assigns numbers automatically. Manual Nos. specifies that a number can be entered manually instead of using the series. Business Central also supports relationships between series: when more than one series exists for the same kind of information or transactions, the related series are associated to one primary series, and that primary code is what gets entered on the Numbering FastTab of a setup page such as Sales & Receivables Setup. Relationships give the user a controlled choice at creation time — they are not a licence to let unrelated document families share a sequence.

One retail-specific exception sits outside this page entirely. The LS Central POS receipt number is unique and is a combination of the POS number and an incremental number: without its control characters it is 19 digits, of which the first 10 are the POS terminal number padded to 10, followed by a perpetual number allowing 9 digits. Terminals therefore cannot collide with each other on receipt numbers by design — provided nobody tries to replace that mechanism with a shared back-office series. Where fiscal rules apply, the receipt also has to carry a receipt number using a number series that goes up in an unbroken series, alongside the retailer name and registration or VAT number, the address, the date and time, and the terminal identification. Unbroken means the gap policy for receipts is not a preference; in those jurisdictions it is a compliance setting.

Decide the series map before creating anything

Write the map down as a table first: one row per document family, with the series code, the range, and the gap policy. A workable retail map looks like this:

Two rules keep the map honest. Ranges must never overlap, even across years — when a new dated line starts, its starting number begins after the previous line's ending number, not at a round number that happens to look tidy. And every family gets exactly one owner: if two people can both invent a series for the same document type, the map will drift within a quarter.

Setup procedure: create and assign the series

1. Open the No. Series page. Use Search, enter No. Series, and choose the related link. Review the existing codes first — a duplicate series for the same document family is itself a collision waiting to happen.
2. Create the series. Choose New, enter a short Code that names the document family (not the year — years belong on lines), and a Description a new administrator can understand without asking.
3. Set the switches. Turn on Default Nos. so numbers are assigned automatically. Leave Manual Nos. off unless the map for that family explicitly allows manual entry.
4. Add the line. Open the No. Series Lines for the series. Set the Starting Date, the Starting No., an Ending No. that leaves real headroom, and Increment-by-No. to 1 unless the map specifies otherwise.
5. Relate only genuine alternatives. If a second series exists for the same kind of transaction, select the primary series line, choose Relationships, and enter the related Series Code. Skip this step entirely for families with one series — most of them.
6. Assign the series where it is used. Open the relevant setup page — for sales documents, Sales & Receivables Setup — and on the Number Series FastTab select the chosen series for each card or document type. Repeat for the purchasing equivalents. An unassigned series hands out nothing.
7. Verify before go-live. Back on the No. Series page, confirm the line applicable by work date shows the intended Starting No., that Last No. Used is empty or matches the expected cutover value, and that no other active series shares any part of the range. Create one test document of each type, confirm it received the expected number, then delete the test document where the document type allows it.

Gap policy: receipts, posted documents, and journals are not the same

The Allow Gaps in Nos. decision deserves its own pass, because the wrong setting hurts in both directions. With gaps disallowed and Default Nos. on, posting is strictly sequential: numbers cannot be skipped or reused, and numbers reserved by journal lines that are later deleted can block a payment file export with a must-be-posted-first error. That strictness is exactly right for a posted-document sequence an auditor will read — and exactly wrong for a working journal where suggested lines are routinely deleted.

The practical pattern for journals is two series doing two jobs. The Document No. series allows gaps and, where needed, manual entry, so approvals stay tied to a consistent pre-assigned number and exports are not blocked when lines are deleted. The Posting No. series stays strict — no manual entry, no gaps — so the posted sequence remains unique and sequential. For retail receipts under a fiscal regime, follow the unbroken-series requirement rather than this pattern; for statements and orders, allow gaps, because a deleted order or a recalculated statement is a normal working event, not an audit event.

What success looks like

• Every document family in the map has exactly one active series, and no two active lines overlap in range.
• A test order, a test posted invoice, and a test statement each receive numbers from their own series, in order, with no duplicate-number error.
• A POS sale produces a receipt number built from the terminal number and its incremental number — not a number from any back-office series.
• Deleting a test journal line and exporting does not produce a must-be-posted-first error on the Document No. series, while the Posting No. series still refuses manual entry.
• The No. Series page shows a Last No. Used for each live series that matches the last document actually created — no phantom consumption.

Note: number series design affects audit trails and, in some jurisdictions, fiscal reporting. Treat this guide as configuration information, not tax or legal advice, and confirm fiscal numbering requirements with the responsible adviser for the jurisdiction the store trades in.