Problem
Found during the live inFakt sandbox E2E run (2026-07-03, merged verification branch for #1310/#1320/#1307).
InfaktInvoicingAdapter.issueCorrection builds its payload with kind: 'corrective', corrected_invoice_number, corrected_invoice_date, correction_reason(_symbol) and POSTs it to invoices.json (libs/integrations/infakt/src/infrastructure/adapters/infakt-invoicing.adapter.ts, correction payload block).
The inFakt sandbox silently ignores all of these fields and creates an ordinary VAT invoice:
- OL side: the
InvoiceRecord says documentType: corrected, the UI shows a KOR.
- inFakt side (GET /invoices/{uuid}.json for the created document):
kind: "vat", corrected_invoice_number: null, correction_reason: null. KSeF then clears it as a regular invoice, not a correction.
Fiscally this is wrong: the "correction" is a second standalone VAT invoice; the original is never corrected in inFakt/KSeF terms.
Likely fix
inFakt exposes a dedicated corrective-invoice endpoint (see e.g. their v3 async corrective_invoice_create flow) - the adapter must use it instead of plain POST /invoices.json, or at minimum verify the response kind and fail loudly when the provider downgraded the document.
Evidence
- OL record: order
PS-E2E-INF-1, original invoice 17/07/2026 (uuid 22295443-c5ab-402d-a643-815e2efa3320, ksef success), "KOR" 18/07/2026 - kind: vat, no corrected_invoice link, ksef success as a plain invoice.
- Unit tests pass because
FakeInfaktHttpClient echoes the seeded fixture (kind: 'corrective') instead of reproducing the real API behaviour.
Problem
Found during the live inFakt sandbox E2E run (2026-07-03, merged verification branch for #1310/#1320/#1307).
InfaktInvoicingAdapter.issueCorrectionbuilds its payload withkind: 'corrective',corrected_invoice_number,corrected_invoice_date,correction_reason(_symbol)and POSTs it toinvoices.json(libs/integrations/infakt/src/infrastructure/adapters/infakt-invoicing.adapter.ts, correction payload block).The inFakt sandbox silently ignores all of these fields and creates an ordinary VAT invoice:
InvoiceRecordsaysdocumentType: corrected, the UI shows a KOR.kind: "vat",corrected_invoice_number: null,correction_reason: null. KSeF then clears it as a regular invoice, not a correction.Fiscally this is wrong: the "correction" is a second standalone VAT invoice; the original is never corrected in inFakt/KSeF terms.
Likely fix
inFakt exposes a dedicated corrective-invoice endpoint (see e.g. their v3 async
corrective_invoice_createflow) - the adapter must use it instead of plainPOST /invoices.json, or at minimum verify the responsekindand fail loudly when the provider downgraded the document.Evidence
PS-E2E-INF-1, original invoice 17/07/2026 (uuid 22295443-c5ab-402d-a643-815e2efa3320, ksef success), "KOR" 18/07/2026 -kind: vat, no corrected_invoice link, ksef success as a plain invoice.FakeInfaktHttpClientechoes the seeded fixture (kind: 'corrective') instead of reproducing the real API behaviour.