The failed-posting queue: one open entry per source document and posting purpose whose general-ledger posting threw, so the failure is visible and retryable instead of being lost when the posting transaction rolls back. Repeated failures for the same document and purpose reuse the open entry, bumping the attempt count and refreshing the message rather than creating duplicates; a successful re-post marks the entry Resolved and an operator can Abandon one that is superseded. The period-close workbench counts entries still Pending for the company as a close check, so an unresolved queue blocks or flags a period close.
Fields
| Field | Label | Type | Required | What it does |
|---|
AttemptCount | Attempt Count | Number | | How many times posting has been attempted and failed for this document and purpose, starting at one and incremented each time the same open entry is re-recorded. Retry drivers can use it as a cap so a hopeless document stops being retried. |
BranchId | Branch | Lookup → Branch | | |
CreatedById | Created By | Lookup → UserAccount | Yes | |
CreatedDateTime | Created On | DateAndTime | Yes | |
DocumentNumber | Document Number | Text | | |
ErrorMessage | Error Message | Text | | The failure text from the posting attempt, truncated to fit, and overwritten on each repeat attempt so it always shows the most recent reason rather than the original one. Typical causes are an unresolvable account, an inactive account, a missing control account, a missing party on a control line, or no Open fiscal period for the document date. |
FirstFailedUtc | First Failed Utc | DateAndTime | | When the entry was first opened, in UTC, and left untouched by later attempts — it is how long a document has been failing. The pending queue is ordered oldest-first by this value. |
Id | Id | Guid | Yes | |
LastAttemptUtc | Last Attempt Utc | DateAndTime | | Refreshed in UTC on every repeat failure and also when the entry is resolved or abandoned, so it is the time of the last activity on the entry rather than strictly of the last posting attempt. |
ModifiedById | Modified By | Lookup → UserAccount | Yes | |
Name | Name | Text | Yes | |
OwnerId | Owner | Lookup → UserAccount | Yes | |
PartnerAccountId | Partner Account | Lookup → Account | | The company whose ledger the failed posting belonged to. Both the pending-queue listing and the period-close check filter on it, so an entry recorded without a company is invisible to both. |
Purpose | Purpose | Text | | The document posting purpose the failure happened on — the same vocabulary the journal carries, so a document that posts several journals can have separate failures for each. Together with the source entity and record it forms the identity of the open queue entry. |
RecordTypeId | Record Type | Guid, hidden | | |
ResolutionNote | Resolution Note | Text | | Free text recorded when the entry leaves the Pending state, defaulting to a standard note when a retry posts successfully and holding the operator's reason when the entry is abandoned. |
SourceEntityName | Source Entity Name | Text | | The entity of the document whose posting failed, held as plain text with no foreign key because any entity can post. It is part of the identity used to find and reuse the open entry rather than duplicating it. |
SourceRecordId | Source Record | Guid | | |
Status | Status | Text | | One of Pending, Resolved or Abandoned. Pending is the live queue: a repeat failure for the same document and purpose reuses the Pending entry instead of adding a row, a successful re-post flips it to Resolved, and Abandoned is the manual give-up for an entry that has been superseded. Only Pending entries count towards the period-close check. |
UIProps | UI Props | Text | | |
UpdatedDateTime | Updated On | DateAndTime | Yes | |
Actions
| Action | Label | Type | What it does |
|---|
Clone | Clone | ServerAction (Clone) | Create a copy of this record |
DeleteEntity | Delete | Delete | DeleteEntity |
DeleteRow | Delete | Delete | DeleteRow |
EditEntity | Edit | Edit | EditEntity |
EditRow | Edit | Edit | EditRow |
