Vendor Invoices Realtime-enabled

Post a direct vendor invoice, a debit against the vendor entered straight through the general journal (Gen. Journal Document Type Invoice), for payables that do not originate from a purchase document. Same document and processing model as Vendor Payments; the applications collection, vendorInvoices({id})/vendorPaymentApplications, is optional. One of the Journal Wrappers.

Settling it later

A later vendor payment settles this invoice by either application key: appliesToInvoiceNumber, using the postedDocumentNumber from Processed Documents, or appliesToInvoiceIntegrationId, using the same integrationId SmartConnect posted the invoice with. The invoice never appears in the posted purchase invoice tables, because it posts through the general journal, but your key resolves all the same, so there is no need to read a Business Central document number back after posting. A payment staged before the invoice posts waits as Awaiting Invoice and applies itself when the invoice does.

Bound actions

Invoke with POST /vendorInvoices(<id>)/Microsoft.NAV.<action>:

• validate: runs the posting checks without processing; surfaces any problem into status / errorMessage.
• process: turns the staged invoice into journal lines (unposted draft, or posted, per the Setup policy).
• post: processes the invoice and posts it, whatever the Setup policy says. Use it when SmartConnect decides that this one invoice goes to the ledger now, rather than an administrator putting the whole endpoint on Auto Post. Only the lines this invoice just wrote are posted, so other drafts sitting in the same journal batch are left alone, and the approval gate applies exactly as it does to process.
• reopen: returns a failed invoice to Open and clears its error, handing it back to the background job. A invoice that hits status = Error is not collected again on its own, so on an Auto endpoint - where by definition nothing calls process - this is how a corrected invoice gets moving. It refuses a invoice that is pending approval, exactly as the Business Central action does.

process and post return no body. The staged invoice deletes itself the moment its journal lines exist, so there is nothing to echo, and the outcome lives on the Processed Documents row the same call wrote. Fetch it by the integrationId you sent the invoice with - processedDocuments?$filter=integrationId eq '<your id>' - and read postedDocumentNumber, postedPostingDate, glTransactionNumber and status; after post they are already filled in. validate writes nothing and points back at the staged invoice. A rejected call returns the error and leaves the invoice in staging, with errorMessage describing the problem, ready to correct and retry. See Journal Wrappers.

What a PATCH may do

Two rules apply to every write, on the header and on its lines and applications alike.

A invoice under approval cannot be changed. Once status is Pending Approval or Approved, a PATCH, a line append or a delete is rejected. What the approver signed off on is what posts. Call reopen first if the invoice genuinely has to change; that is an explicit act rather than a silent revocation, and it leaves no orphaned approval entry behind.

Deleting is also a setup choice. A DELETE of a staged invoice is refused when the endpoint's Allow Manual Delete switch is off on the eOne Integration Setup page. It is on by default, so nothing changes until an administrator turns it off to mark the whole document family integration-owned. The approval rule above holds regardless of the switch.

Correcting a failed invoice clears its error. Any successful write to a invoice whose status is Error returns it to Open and empties errorMessage, so it becomes visible to the background job again - a line or application write counts, because the failure is usually in a line. The full text of every failed attempt is kept separately and is not lost when the live message is cleared. Awaiting Invoice is left alone: that one heals itself when the invoice posts.

Reading the outcome from the payload

Four read-only roll-ups come back with every read and every write, so SmartConnect can judge the invoice from the response instead of the English text in errorMessage: appliedAmount (the sum of the application lines), numberOfApplications, applicationsResolved (lines already pointing at a posted document) and applicationsAwaitingInvoice (lines still waiting for one to post).

An originating invoice usually carries no application lines at all, so numberOfApplications and appliedAmount both come back 0 and the header amount posts on its own. That is the accepted state, not a shortfall. Once you do add application lines, appliedAmount has to stay at or below amount: any difference is left on the account unapplied, and only a total above amount is rejected.

appliedAmount is this family's equivalent of the totalAmount on Expenses and Bank / G/L Entries. Both are the sum of the child lines; only a ledger document also carries a header amount to check them against. See Journal Wrappers.

Remittance details

recipientBankAccount, creditorNumber, paymentReference and bankPaymentType are accepted here exactly as they are on Vendor Payments, so an invoice that applies against an on-account prepayment carries the remittance a payment file or check needs without SmartConnect having to restate it on a second document. They ride the vendor line that settles the applied documents, so send them with the application lines; an invoice posted as a bare header settles nothing and posts without them. See Journal Wrappers.