Skip to content

Append non-grant advances to PaymentsOnAccount#19

Open
methodofaction wants to merge 3 commits into
mainfrom
fix-payments-on-account-append
Open

Append non-grant advances to PaymentsOnAccount#19
methodofaction wants to merge 3 commits into
mainfrom
fix-payments-on-account-append

Conversation

@methodofaction
Copy link
Copy Markdown
Contributor

Summary

setAdvances built each PaymentOnAccount struct but never appended it to the slice, so the <PaymentsOnAccount> block was always omitted from the XML even when non-grant advances existed on the invoice. Add the missing append.

Extracted from #16 (issue #1 of that PR's three bundled fixes).

Test plan

  • go test . passes with the new invoice-with-advance fixture
  • go test -tags xsdvalidate . passes (XML is XSD-valid against Facturae v3.2.2)
  • Reverting the one-line append makes the fixture test fail (missing <PaymentsOnAccount> block)

🤖 Generated with Claude Code

methodofaction and others added 2 commits April 24, 2026 13:05
setAdvances constructed a PaymentOnAccount struct for each non-grant
advance but never appended it to the regular slice, so the
PaymentsOnAccount block was always omitted from the XML even when
advances existed. Add the missing append.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Golden-file test that exercises a non-grant advance so the
PaymentsOnAccount block is emitted. Without the append fix in
setAdvances, the generated XML omits the block and this test fails.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes Facturae XML generation for invoices that include non-grant advances by ensuring <PaymentsOnAccount> is emitted when appropriate, and adds a regression fixture pair to cover the scenario end-to-end.

Changes:

  • Append non-grant PaymentOnAccount entries in InvoiceTotals.setAdvances so <PaymentsOnAccount> is included in generated XML.
  • Add a new GOBL input fixture (invoice-with-advance.json) exercising advances + due dates.
  • Add the corresponding expected XML output fixture (out/invoice-with-advance.xml) containing <PaymentsOnAccount>.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.

File Description
invoice_totals.go Fixes omission of non-grant advances from the PaymentsOnAccount slice, enabling correct XML output.
test/data/invoice-with-advance.json New test fixture input that includes an advance payment and explicit payment terms.
test/data/out/invoice-with-advance.xml New expected XML output verifying <PaymentsOnAccount> appears and totals reflect the advance.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread invoice_totals.go
@methodofaction methodofaction requested a review from pmenendz April 24, 2026 11:20
Facturae's XSD requires PaymentOnAccountDate (no minOccurs=0). When a
non-grant advance has no date set, the previous code left the zero
cal.Date value, which would marshal as 0001-01-01 and fail XSD
validation. Default PaymentOnAccountDate to the invoice's IssueDate
and override with the advance's date when present — an advance has
necessarily been paid by the time the invoice is issued, so this is a
safe upper bound.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@methodofaction
Copy link
Copy Markdown
Contributor Author

copilot complained about the date being set to years zero if an advance date did not exist. I'm not sure if this guard is necessary as we may require it upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants