Rule reference

ATW-CREDIT-NOTE-UNSUPPORTED Credit notes are not yet supported by this library

Credit notes are not yet supported by this library. The invoice type code (BT-3) "381" denotes a credit note, which EN 16931 and XRechnung both allow — but in UBL a credit note is a separate CreditNote document (root ubl:CreditNote, namespace ...:xsd:CreditNote-2, with cac:CreditNoteLine and cbc:CreditedQuantity), not an ubl:Invoice carrying a different code. This build generates the Invoice document only, so generateXRechnungUBL would have to emit a document the EN 16931 schematron rejects. It throws UnsupportedDocumentTypeError instead. This is a limitation of the library, not a finding against your data.

This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.

Business term
BT-3
Severity
fatal

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

TeachingError
{
  "rule": "ATW-CREDIT-NOTE-UNSUPPORTED",
  "field": "BT-3",
  "severity": "fatal",
  "message": "Credit notes are not yet supported by this library. The invoice type code (BT-3) \"381\" denotes a credit note, which EN 16931 and XRechnung both allow — but in UBL a credit note is a separate CreditNote document (root ubl:CreditNote, namespace ...:xsd:CreditNote-2, with cac:CreditNoteLine and cbc:CreditedQuantity), not an ubl:Invoice carrying a different code. This build generates the Invoice document only, so generateXRechnungUBL would have to emit a document the EN 16931 schematron rejects. It throws UnsupportedDocumentTypeError instead. This is a limitation of the library, not a finding against your data.",
  "fix": "Use \"384\" (corrected invoice) with precedingInvoices carrying the number of the invoice you are correcting (BT-25) if your process allows a correction rather than a credit note; otherwise produce the credit note with another tool until the CreditNote generator ships. For an ordinary invoice, set invoiceTypeCode to \"380\".",
  "example": "\"invoiceTypeCode\": \"380\"",
  "xpath": "/ubl:Invoice/cbc:InvoiceTypeCode",
  "docsUrl": "https://github.com/attestwire/en16931#not-implemented-yet"
}

xpath locates the element in the generated UBL document, which is where a KoSIT or Peppol validator will report the same problem.

A passing value

the shape this field expects
"invoiceTypeCode": "380"

The fix

Use "384" (corrected invoice) with precedingInvoices carrying the number of the invoice you are correcting (BT-25) if your process allows a correction rather than a credit note; otherwise produce the credit note with another tool until the CreditNote generator ships. For an ordinary invoice, set invoiceTypeCode to "380".

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.