How Sales-Post actually works: the posting routine from Release to ledger entries

When a user posts a sales order, codeunit 80 Sales-Post runs. It is long, it has been refactored many times, and it is where most sales-side extension code wants to hook in. Knowing its shape means you subscribe to the right event, with the right data available, and you never try to reproduce what it does.

The stages

1. Entry and checks. OnRun receives the Sales Header. OnBeforePostSalesDoc fires here (with IsHandled): the last point to stop the whole posting. Then CheckAndUpdate: status released, posting dates in range, customer not blocked, dimensions valid, VAT, item tracking, e-document rules. Most "cannot post because" errors come from here.
2. Lock and prepare. The header and lines are locked; temporary copies of the lines are made; prepayments, invoice discounts and rounding lines are calculated. OnAfterCheckSalesDoc and the line-level OnBeforePostSalesLines fire around here.
3. Line loop. For each line: quantity to ship/invoice decided; for items, the Item Journal Line is built and posted through Item Jnl.-Post Line (codeunit 22), producing Item Ledger Entries, Value Entries and, through the inventory posting setup, the inventory G/L lines collected for later; for resources, Res. Jnl.-Post Line; for G/L account lines, nothing yet but the amounts are accumulated. Warehouse shipment and reservation entries are updated. OnBeforePostItemJnlLine, OnAfterPostItemJnlLine, OnPostSalesLineOnBeforeInsertShptLine and dozens of others fire per line.
4. Posted documents. The Sales Shipment Header/Lines and Sales Invoice Header/Lines (or Credit Memo / Return Receipt) are inserted, copying from the temporary lines. OnBeforeSalesInvHeaderInsert, OnAfterSalesInvLineInsert and so on: this is where your fields get copied to the posted tables (and why lengths must match).
5. Finance. The accumulated amounts become Gen. Journal Lines in memory (revenue, VAT, discounts, the customer receivable) and are posted through Gen. Jnl.-Post Line (codeunit 12), which writes G/L Entries, VAT Entries, the Cust. Ledger Entry and Detailed Cust. Ledger Entry, using the posting groups. OnBeforePostCustomerEntry, OnBeforePostInvoicePostingBuffer (the invoice posting buffer is the grouped amounts by account and dimension set).
6. Clean-up. The order is updated (quantities shipped/invoiced) or deleted if fully posted; the posting preview, if that is what was requested, rolls everything back and shows the entries instead. OnAfterPostSalesDoc fires with the posted document numbers: the point for "send to courier", "email the invoice", "notify the web shop". By then it is committed; do not error here.

What to take from this

• Validation goes in OnBeforePostSalesDoc or the line-level before events, not after.
• Copying your fields to posted tables goes in the insert events for the posted headers/lines.
• Anything that changes amounts goes through the invoice posting buffer events, carefully, and is tested with posting preview.
• Side effects (emails, integrations) go in OnAfterPostSalesDoc and must not throw.
• If you need a ledger entry, you build a journal line and call codeunit 12 or 22, as Sales-Post does. Never Insert into G/L Entry.

Purchase posting (codeunit 90) is the mirror image. Read codeunit 80 once in the symbol browser with the stages above as a map; it will save you a week over the life of any sales extension. The events post covers the subscription mechanics.

Related posts