Resending and the issue date

Resending a failed invoice and its issue date

The invoice UUID is derived from the issue date among its seven fields (IBR-002-OM, above), and a B2C invoice's QR code carries the issue date, the time and that UUID. An invoice sent again with a new date would be a different invoice under the same number, reported to the Tax Authority a second time.

GoRoute protects you from that. For an Omani invoice, POST /api/v1/transactions/{transaction_id}/resend never rebuilds or re-dates anything: the stored document — the one first sent — is queued again under the same transaction and message id, to the same receiver, exactly as POST /api/v1/transactions/{transaction_id}/retry does. update_timestamps left out (or false) keeps the date whatever else the body says; "update_timestamps": true is refused with 422 OMAN_RESEND_CANNOT_REDATE and nothing is sent. An invoice from an Omani seller that went out as Peppol BIS 3.0 rather than PINT OM cannot be reported, so it is not resent at all: 422 OMAN_RESEND_NOT_PINT_OM, whatever the body; send a new invoice under a new number instead.

To change an invoice you have issued, send a credit note for it and a new invoice under a new number.

A resend of an Omani invoice therefore never re-dates or rebuilds it. Where nothing about the invoice must change, POST /api/v1/transactions/{transaction_id}/retry is the simpler call: it takes no body and queues the same transaction and message id, provided the send is failed or retrying and the document is still in storage. The full resend reference is under Tracking.