[ahmedm10]

Ticket

https://miceportal.atlassian.net/browse/MP-53292

Story

Auftragsbuch writes every ZUGFeRD document as a commercial invoice: the gem hardcodes the document type (BT-3) to 380. Cancellations and refunds are credit notes (381) and corrections are corrected invoices (384), so a recipient's software books them the wrong way. A credit note or correction should also say which invoice it refers to (BG-3, the preceding invoice reference), which the gem cannot write at all.

The third change is for the seller identifier. Invoices that must not carry our VAT ID (non-taxable commission invoices, category O) still need a seller identifier, and the right field for a commercial register entry such as HRB München 169661 is the legal registration identifier (BT-30). The gem always writes a scheme ID there and defaults to "0002", the French SIRENE register, which would mislabel a German register entry. BT-30 now works without a scheme.

How to review

One commit, three small changes:

• lib/secretariat/invoice.rb
  • type_code (BT-3): written as given, 380 when not set.
  • preceding_invoice_id (BT-25) and preceding_invoice_issue_date (BT-26): written as InvoiceReferencedDocument after the totals block, where the CII schema expects it. Version 2 only, like attachments.
• lib/secretariat/trade_party.rb: legal_organization: { id: "...", scheme_id: nil } writes no schemeID.
• test/invoice_test.rb: six tests
  • the type code defaults to 380
  • a 381 credit note with the preceding invoice and its date, also checked against the official Factur-X rules
  • the preceding invoice without a date
  • no preceding invoice by default
  • BT-30 without a scheme
  • BT-30 still defaults to "0002"

Design Choices

• Existing callers are unaffected. Without the new fields the XML is exactly what it was: TypeCode 380, no InvoiceReferencedDocument. A legal_organization without a scheme_id key still gets "0002".
• One behaviour change in BT-30: a caller passing scheme_id: nil explicitly used to get "0002" and now gets no scheme. An explicit nil reads as "no scheme", and the attribute is optional in EN 16931 (BT-30-1).
• No list of allowed type codes in the gem. The gem doesn't restrict other codes either (payment means, tax categories). The official rules check the code list.
• Credit note amounts are the caller's job. With 381, the type already says "credit", so the amounts must be positive. Auftragsbuch takes care of that when it switches to the new type codes.
• Branched from upstream (halfbyte) main, as for MP-54008 Fix 1-cent VAT rounding in line totals and VAT base #7, so the same commit can go upstream: the TypeCode was an open TODO there. The library files apply cleanly on our main; the test file only needs its tests placed next to ours.

Links

• Previous fork PRs: MP-54008 Sync with upstream v3.9.0 #6 (sync with upstream v3.9.0), MP-54008 Fix 1-cent VAT rounding in line totals and VAT base #7 (1-cent VAT rounding)
• Parent ticket: MP-53289 (outbound e-invoice conformance)
• Upstream PR: Make the document type configurable, add the preceding invoice reference, allow BT-30 without a scheme halfbyte/ruby-secretariat#63

Checklist

• I self-reviewed the PR
• I got approval from the design team
• I checked the acceptance criteria
• I added the PR description