Creates an adjustment, its lines and its billing schedules and submits them, all in one call and one transaction. If any part of it fails, nothing at all is saved - not a draft, not a header.

Only five things are required: adjustmentType, creditType, reasonCode, adjustmentDate, and something to adjust.

Two ways to say what to adjust:

• lines - the caller already knows the invoiced lines and names them, by invoice number and invoice line number, or by order number and order line number.
• lineSelection - the caller sends the same search criteria the screen searches with, and every line the search returns is adjusted. On the screen a user ticks the rows; through the API there is nobody to tick.

Amounts: send any two of quantity, unitPrice and totalAmount and the third is worked out. The same rule applies to the rebill amount on a Credit and Rebill. fullCredit: "Y" sends none of them and credits what the invoiced line still has left.

Derived values: on an Against Invoice adjustment the customer, the site, the currency and the business unit come from the invoice and are not asked for. On-Account has no invoice behind it, so those four are sent.

Lookup values may be sent either as the meaning a user reads on the screen (Credit Memo) or as the code stored behind it (CM).

Refusals name every problem in one answer and write nothing.

Reading the answer: every response carries statusCode in the body, and that is the status to act on. The service returns it as the HTTP status too, but the gateway in front of these APIs currently answers 200 for refusals and leaves the real code in the body - the same behaviour raised for another endpoint in CS-41997. Read statusCode from the body and you are correct either way.