Processed Documents Realtime-enabled

Read-only history of the ledger documents, expenses and inventory adjustments SmartConnect has already put through Business Central. Look a document up by the integrationId you sent it with, and read back the document number it posted as.

Why this exists

The staging endpoints delete their document the moment it becomes journal lines, so a document that has been processed is not on customerPayments, expenses or inventoryAdjustments any more. That left SmartConnect no way to answer the one question that matters after a failed call: did Business Central take this document or not? This feed answers it. Every processed document keeps a row here, keyed by the integrationId it arrived with.

Two states, and the difference matters

status is Processed or Posted, and they are not the same thing:

• Processed: the document left staging and its draft journal lines were written - general journal lines, or item journal lines for an inventory adjustment. Nothing has posted. This is the normal resting state for an endpoint set to Manual or Auto Draft, where a person in Business Central reviews the draft before posting it.
• Posted: the draft posted. postedDocumentNumber and postedPostingDate are filled in, and glTransactionNumber too for everything except an inventory adjustment - an adjustment posts to the item ledger, so its glTransactionNumber stays 0.

A row that stays Processed long after you expected it to post means its draft journal lines were deleted instead of posted. Treat that as a document to chase, not as a document that failed: SmartConnect was told the import succeeded, and it did.

See Journal wrapper endpoints.

Reading back the posted numbers

postedDocumentNumber is read from the posted entry, not copied from the staged document. A journal batch with a posting number series renumbers its documents as it posts. The number the draft was written under and the number in the general ledger are often different. Use postedDocumentNumber for anything you write back to the source system, and documentNumber only when you are looking for the draft.

glTransactionNumber groups every general ledger entry the posting produced. Filter generalLedgerEntries on it to read the entries themselves. Inventory adjustments have no such number; find their item ledger entries by postedDocumentNumber instead.

Rejecting a document you already sent

A retried POST is the normal response to a timeout, and a timeout tells you nothing about whether Business Central accepted the document. So the ledger and expense endpoints reject an integrationId that already belongs to a staged or processed document. The error names the earlier document, and when it was processed or posted. That check is Reject Duplicate Integration Ids on the eOne Integration Setup page, on by default.

To send the same integrationId again on purpose, delete its row on the eOne Processed Documents page in Business Central. Deleting the row releases the key. Nobody can edit a row, only delete it, so history never disagrees with the general ledger.

The sales and purchase document endpoints have their own setting, Reject Duplicate Documents, because they write into Business Central's own tables and keep no row here. Inventory adjustments keep a row here but are not covered by the duplicate check yet: their staging lives in its own table with its own lifecycle. See The Integration Id.

Receipts and notes come across too

Anything attached to a staged document travels with it. When the document is processed, its attachments and notes are re-keyed onto the processed document, so the receipt that justified an expense stays reachable after the expense report itself is gone. Read them back with parentType processedLedgerDocument or processedExpense and the same integrationId; the attachment's own id does not change either. They appear in the Attachments factbox on the eOne Processed Document Card as well.

Retention

There is no automatic purge. Processed documents are financial history, and how long a company keeps it is that company's decision. Both history tables are registered with Business Central's standard Retention Policy module. An administrator sets a policy on the Retention Policies page. It gets the same audit log and controls as every other retention rule in the environment. Until they do, nothing is deleted.

Deleting a processed document, whether by policy or by hand, deletes its lines and its attachments and notes with it. History is where a receipt came to rest, so that deletion is the point at which the company stops keeping the paperwork. If a receipt has to outlive the accounting record, keep a copy outside Business Central.