# Processed Documents _(Realtime-enabled)_

`GET` _(Table: EONE Processed Txn)_

```
eOne/core/v1.0/processedDocuments
```

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](https://eonesolutions.github.io/eone-bc-integration/core-inventoryAdjustments.md). 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](https://eonesolutions.github.io/eone-bc-integration/journal-wrappers.md).

## 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.

> **Tip:** This entity set supports webhooks. Subscribe and you are pushed the row twice: once when the document is processed, and again when posting stamps the posted numbers on it.

## 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](https://eonesolutions.github.io/eone-bc-integration/integration-id.md).

## Receipts and notes come across too

Anything attached to a staged document travels with it. When the document is processed, its [attachments](https://eonesolutions.github.io/eone-bc-integration/core-documentAttachments.md) and [notes](https://eonesolutions.github.io/eone-bc-integration/core-notes.md) 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.

## Processed Documents fields

_API column → BC field._

**Legend**

- _(req)_ required on create
- _(res)_ resolver
- _(cur)_ currency-translated
- _(ro)_ read-only
- _(ext)_ added to this endpoint by another extension (BC field name shown; its API column name is not known here)

| API | BC field | Notes |
| --- | --- | --- |
| `id` | SystemId | BC record GUID. _(ro)_ |
| `bcCompanyId` | bcCompanyId | The company this row belongs to - the same GUID that appears in the request URL. Present on every endpoint so a store pooling several companies can keep them apart without relying on which URL it called. _(ro)_ |
| `bcCompanyName` | bcCompanyName | The name of the company this row belongs to. _(ro)_ |
| `integrationId` | EONE Integration Id | The integrationId the document was sent with. Look a document up by this to find out what became of it. _(ro)_ |
| `documentType` | Document Type | Which endpoint the document came from: customer or vendor payment, refund, credit memo or invoice, employee payment, expense, bank/G/L entry, or inventory adjustment. _(ro)_ |
| `status` | Status | Processed means the draft journal lines were written (general journal lines, or item journal lines for an inventory adjustment) but nothing has posted yet. Posted means they posted, and the posted fields below are filled in. _(ro)_ |
| `documentNumber` | Document No. | The document number the draft journal lines were written under. A journal batch with a posting number series renumbers at posting time, so compare postedDocumentNumber for what actually reached the ledger. _(ro)_ |
| `postedDocumentNumber` | Posted Document No. | The final document number the posted entries carry (general ledger entries, or item ledger entries for an inventory adjustment), read from the posted entry itself. Blank until the document posts. _(ro)_ |
| `postedPostingDate` | Posted Posting Date | The posting date the posted entries carry. Blank until the document posts. _(ro)_ |
| `glTransactionNumber` | G/L Transaction No. | The general ledger transaction number that groups every entry this posting produced. Filter generalLedgerEntries on it to read the resulting entries. Zero until the document posts, and always zero for an inventory adjustment - item journal posting produces item ledger entries, not a G/L transaction. _(ro)_ |
| `processedAt` | Processed At | When the document was processed out of staging into draft journal lines. _(ro)_ |
| `processedBy` | Processed By | The Business Central user the processing ran as: the service account for an API-driven process, the job queue user for automatic processing, or the person who pressed Process in the client. _(ro)_ |
| `postingDate` | Posting Date | The posting date requested for the document. _(ro)_ |
| `documentDate` | Document Date | The document's own date, which can differ from the posting date. _(ro)_ |
| `externalDocumentNumber` | External Document No. | The external document number carried onto the journal lines and the posted entries. _(ro)_ |
| `amount` | Amount | The document amount as staged. _(ro)_ |
| `totalAmount` | Total Amount | The total of the document's lines - the applications for a ledger document, the distributions for an expense. Should equal amount. _(ro)_ |
| `description` | Description | The document description carried onto the journal lines. _(ro)_ |
| `reimbursementType` | Reimbursement Type | For an expense report, how it was settled with the employee: Reimbursable, Company Paid or Card Paid. Blank on every other document type. _(ro)_ |
| `accountType` | Account Type | The party side the document posted against: Customer, Vendor or Employee. Blank for an expense or a bank/G/L entry. _(ro)_ |
| `accountNumber` | Account No. | The customer, vendor or employee the document posted against. _(ro)_ |
| `balancingAccountType` | Bal. Account Type | The balancing side: Bank Account, G/L Account, Vendor or Employee. _(ro)_ |
| `balancingAccountNumber` | Bal. Account No. | The bank, G/L, vendor or employee account the document balanced against. _(ro)_ |
| `currencyCode` | currencyCode | The document currency, returned as the ISO code. The operating currency is returned as its ISO code rather than blank. _(cur)_ |
| `journalTemplateName` | Journal Template Name | The journal template the draft lines were written to - a general journal template, or an item journal template for an inventory adjustment. _(ro)_ |
| `journalBatchName` | Journal Batch Name | The journal batch the draft lines were written to. Where to look for the draft when status is still Processed. _(ro)_ |
| `lastModifiedDateTime` | SystemModifiedAt | When the row last changed - it changes once, when posting stamps the posted fields on it. _(ro)_ |