Update an e-reporting payment
PATCH/api/v1/e_reportings/payments/:id
Updates an existing payment. Authorization is based on the OAuth application's tenant access.
Request
Responses
- 200
- 401
- 404
- 422
The e-reporting payment was updated with the supplied attributes.
The request did not include a valid OAuth 2.0 bearer token.
No e-reporting payment exists with this ID, or it belongs to a workspace the authenticated OAuth client cannot access.
The payment payload failed validation. The response body carries code: "validation_failed" and reports the failing attributes and error messages as full messages under details.base. Among them a tax_subtotals[].currency_code that names no ISO 4217 currency - the currency sits on the tax breakdown rather than on the payment, so a subtotal entry is the only place a payment states one. Currency codes are matched case-sensitively against the two code lists Scribee vendors (the UN/CEFACT ISO3AlphaCurrencyCode enumeration unioned with the Peppol BIS ISO4217 list), so eur is refused rather than upcased. That is deliberately stricter than the PPF's own flux 10 rule F10-PMT-DEVISE-G1.10, which asserts the three-letter shape alone and states in its own message that referential existence is not controlled. A payment naming a down-payment invoice of the workspace - by its exact invoice_number, and its issue date when invoice_date is stated - is refused as well once that down payment was taken back out of the B2C transaction data (flux 10.3) by a final invoice declared outside B2C (flux 1 or 10.1): its payments are then no longer declared in e-reporting, until that final invoice is cancelled or rejected.