Clarify editable operational fields on posted ledger entries

Addresses review feedback from @JeremyVyska on PR #57: the immutability rule applies to financial content, not the whole entry. Reframes the Description around financial content and gives the operational-field exception (payment/application data, on-hold, applies-to, communication fields edited via CustEntry-Edit/VendEntry-Edit and the ledger entry pages) its own paragraph in Best Practice instead of understating it as a narrow set.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
Jesper Schulz-Wedde 2026-06-29 15:04:36 +02:00
parent 3cb00e4d2d
commit 5e779c702f

View file

@ -1,7 +1,7 @@
--- ---
bc-version: [all] bc-version: [all]
domain: finance domain: finance
keywords: [ledger-entry, immutable, reversal, audit-trail, correction, reverse, custentry-edit] keywords: [ledger-entry, immutable, reversal, audit-trail, correction, custentry-edit, non-financial-fields]
technologies: [al] technologies: [al]
countries: [w1] countries: [w1]
application-area: [finance] application-area: [finance]
@ -11,11 +11,13 @@ application-area: [finance]
## Description ## Description
A posted ledger entry is an immutable record in Business Central's audit trail. The financial content of `G/L Entry`, `Cust. Ledger Entry`, `Vendor Ledger Entry`, and similar tables — amounts, accounts, posting date, quantities — must not change after posting, because registers, applications, VAT statements, and statutory reports all assume entries are append-only. Corrections are themselves postings: BC provides reversal (the `Reverse` / `Reverse Register` routines) and correcting documents (credit memos, correcting journals) that post a new, offsetting entry and leave the original intact. A posted ledger entry is part of Business Central's permanent audit trail, and its **financial content** is immutable. The amounts, accounts, posting date, and quantities on `G/L Entry`, `Cust. Ledger Entry`, `Vendor Ledger Entry`, and similar tables must not change after posting, because registers, applications, VAT statements, and statutory reports all assume that content is append-only. Correcting financial content is therefore itself a posting: BC provides reversal (the `Reverse` / `Reverse Register` routines) and correcting documents (credit memos, correcting journals) that post a new, offsetting entry and leave the original intact. This immutability rule is about financial content — it is not a blanket ban on touching the entry (see Best Practice).
## Best Practice ## Best Practice
To undo or correct a posting, post a reversing or correcting entry through the normal posting path so the offset is itself a balanced, dated, traceable transaction. The original entry stays in place and the two net to zero, preserving the audit trail. A narrow set of non-financial fields (for example an entry's `Open` / `On Hold` status or a due date) is editable through dedicated platform routines such as `CustEntry-Edit` and `VendEntry-Edit`; use those routines rather than a raw `Modify`. To undo or correct a posting's **financial** content, post a reversing or correcting entry through the normal posting path so the offset is itself a balanced, dated, traceable transaction. The original entry stays in place and the two net to zero, preserving the audit trail.
Non-financial **operational** fields are a deliberate exception and are meant to be edited after posting. BC supports updating a defined set of post-posting fields — payment and application data such as due date, payment-discount dates, on-hold status, applies-to ID, and recipient/communication fields — and the Customer and Vendor Ledger Entries pages expose several of them as editable. Make those changes through the dedicated `CustEntry-Edit` / `VendEntry-Edit` routines (which those pages call), not a raw `Modify`, so the edit stays within the supported set and leaves the entry's financial content and audit trail intact.
## Anti Pattern ## Anti Pattern