Customer Credit Memos Realtime-enabled

Issue a credit memo to a customer through the general journal, same document and processing model as Customer Payments, but it posts as a Credit Memo against the customer ledger. Use the applications collection, customerCreditMemos({id})/customerPaymentApplications, to settle the invoices it credits, or leave them open. One of the Journal Wrappers.

Bound actions

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

• validate: runs the posting checks without processing; surfaces any problem into status / errorMessage.
• process: turns the staged credit memo into journal lines (unposted draft, or posted, per the Setup policy).
• post: processes the credit memo and posts it, whatever the Setup policy says. Use it when SmartConnect decides that this one credit memo goes to the ledger now, rather than an administrator putting the whole endpoint on Auto Post. Only the lines this credit memo 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 credit memo to Open and clears its error, handing it back to the background job. A credit memo 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 credit memo gets moving. It refuses a credit memo that is pending approval, exactly as the Business Central action does.

process and post return no body. The staged credit memo 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 credit memo 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 credit memo. A rejected call returns the error and leaves the credit memo 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 credit memo 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 credit memo 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 credit memo 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 credit memo clears its error. Any successful write to a credit memo 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 credit memo 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 credit memo 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.