fa63d5526c
Move Finance knowledge to the Microsoft-owned layer, add nine scoped rules with eighteen AL samples, and register bounded Finance review with complete paired evaluation coverage. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
3.1 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
finance |
|
|
|
|
Correct posted financial content through posting workflows, not row surgery
Description
Changing a posted entry's original amount, account, posting date, or tax amounts in place does not correct the related ledger, register, or source document. Deleting one erroneous row has the same problem. Business Central provides reversing and correcting posting workflows that retain the relationship between the original transaction and its correction; this is not a blanket prohibition on every write to a posted table.
Best Practice
Use a supported transaction/register reversal, credit memo, or correcting journal appropriate to the original posting and its current state. Request the standard reversal workflow rather than negating a single row or setting Reversed yourself. Let that workflow enforce eligibility; do not change source or application fields to make a rejected reversal pass.
Supported operational edits are deliberate exceptions: for example, "G/L Entry-Edit" supports description changes, and "Cust. Entry-Edit" / "Vend. Entry-Edit" handle their table-specific editable fields. Due-date synchronization, application/unapplication, G/L dimension correction, and supported date compression have their own workflows. Do not flag their standard implementations, temporary simulation buffers, or extension-only metadata updates as financial row surgery. A subscriber is not exempt merely because it runs inside a supported workflow: inspect the fields it actually changes.
See sample: do-not-modify-or-delete-posted-ledger-entries.good.al.
Anti Pattern
Persist a change to original financial content, delete posted rows, or fabricate reversal flags/links to repair or undo a transaction outside the supported correction/maintenance workflow. Require an existing, non-temporary standard ledger record and evidence of the fields or rows affected; a Modify token alone is insufficient. Settlement-state writes belong to the application article rather than a duplicate finding here.
See sample: do-not-modify-or-delete-posted-ledger-entries.bad.al.