Removing document postings

A service for one rare but dead-end case: the document's confirmation flag has been cleared while its transactions remained. Such a document gets stuck for good — it cannot be confirmed again (the unique index on postings rejects the second one) and it cannot be deleted either (the accounting guard sees live postings). The only way out used to be editing the database by hand. Now the administrator removes the postings with this service, after which the document can be deleted or confirmed anew.

Where to find it: Modules → Nominal Ledger → Maintenances → Removing document postings

A worked example

The window asks for exactly two things, and neither has to be looked up — the system has already printed them:

• Posting mark (register) — the internal name of the register that owns the posting;
• Document number.

Where to get them: when the system refused to delete the document, the last line of the refusal printed the mark and the number — for example CashOut 42. Those two words are carried into the fields as they are. The hint inside the window says the same.

The "Scheduled" button is in the window but inactive, and that is not an oversight: the operation is irreversible and is never handed to the scheduler — a scheduled run sent as a direct request is refused by the server too ("This operation is irreversible and cannot be scheduled!").

What the service verifies before removing anything

It does not trust the input. It establishes three facts in turn, and may refuse on any of them.

The posting exists. If there is no posting with this mark and number, the answer is an honest refusal, "No postings found for this mark and number", rather than a quiet "done".

The mark is a document register. The owner is determined by a sign: a mark that matches a register definition is that register. Compound marks of currency operations and marks of fixed assets are not register definitions — the owner cannot be established from them, so the service refuses instead of deleting blindly. Postings of fixed assets are removed by their own services.

The service looks for the owning document at the address the register declares for its postings: usually the document number, for "Income / Expense Items" the record itself. If the register's records have no such address, a mark matching a register definition proves nothing, and the service refuses just as it does for marks that are not registers. This is the case for the AutSimPeriods mark: it matches the definition of the "Deferred Expenses" register, but such postings are created by the "Create transactions from simulations" service under a numbering of its own, so the posting number is not a card number. Such postings are removed by an administrator. The document really is in a contradictory state. If the document is there and its confirmation flag is set, the service refuses: those postings are legitimate and must be removed by unchecking the document the regular way. Production and Production operations have no flag — a status posts the document, and the service judges by it: "Started" or "Finished" gets the same refusal, while "Created" with a live posting is the contradictory state, and the service removes the posting. If the register has no confirmation flag at all ("Service Payments", "Income / Expense Items"), the service refuses: the postings belong to a live record. Yet such a record cannot be deleted either while postings remain under it — the deletion refusal refers you to an administrator. There is no regular way out for these registers: their postings are removed by an administrator. If the document does not exist at all, the posting is an orphan — and that is exactly what should be removed.

The removal itself goes through the same path that the regular unchecking uses, with the same hooks and the same recalculation. The service does not invent a second way of doing the same thing. That is also why the closed-period lock applies: a posting dated in a closed period is not removed.

After the removal it asks the database once more whether the posting is really gone. If it somehow remains, the service fails and rolls everything back instead of reporting success.

Typical situations

"No postings found for this mark and number." Either the mark or the number was carried over with a typo, or the postings have already been removed — try deleting the document again.

"The document is confirmed — its postings are legitimate." This is not the case the service was built for. Open the document and uncheck it the regular way: the postings will go on their own. The exception is "Worksheets": they have no regular unchecking, so the postings of a confirmed worksheet are removed by an administrator.

"Period closed!" The posting is dated in a period closed in "Closing changes". The service removes it the same way a manual deletion does, so it has to wait until the period is reopened or you are added to the list of users allowed to change it.

The mark does not look like a register name (a currency operation, for instance, or fixed assets). The service refuses on purpose. Fixed assets have their own services; everything else needs an administrator.

A refusal about a register shared from another company. If your company uses the transactions (or the document register) shared from another company, the service refuses before it even looks for the posting and names that register: only the company that owns the register may remove its postings — otherwise the service would wipe a posting of that company's document. Run the service in that company.

The postings are gone but the document still will not delete. Something else is holding it — read the new refusal in full: it names the reason.