feat(templates): let a billed party print its own registration - #640
Merged
Merged
Conversation
A supplier could already state a tax registration through InvoiceContactBlock.taxRegistrationLabel / taxRegistrationNumber, and the party being billed could not — but most B2B invoices print the customer's VAT or tax number too, under its address. subline was the only spare field and it is contractually the attention line that sits ABOVE the address, so a registration put there renders in the wrong place. InvoiceRecipient now carries registrationLabel and registrationNumber, mirroring the pair the supplier block already has, with hasRegistration() for the presets that draw the row only when there is a number to draw. Both are plain strings, blank when absent, and the six-argument constructor is kept explicitly, so existing calls compile and link unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The next invoice bundle in the promotion queue prints the billed party's VAT number
under its address, beside a label. The supplier block can already say that —
InvoiceContactBlock.taxRegistrationLabel/taxRegistrationNumber— andInvoiceRecipientcannot.sublinewas the only spare field, and it is contractually the attention line thatsits above the address — a department, a contact, a cost centre. A registration put
there renders in the wrong place, above the address instead of below it.
What
InvoiceRecipientcarriesregistrationLabelandregistrationNumber, mirroring thepair the supplier block already has, plus
hasRegistration()for the presets that drawthe row only when there is a number to draw — a label on its own is a heading over an
absence.
Both are plain strings, blank when absent. The six-argument constructor is kept
explicitly.
Tests
StructuredInvoiceCompatibilityTestgains three cases: the constructor that predatesthe registration leaves both fields blank and reports no registration, a recipient
carries what it is given, and a label with no number still reports none. 14 cases green.
./mvnw -B -ntp clean verify -pl :graph-compose-core,:graph-compose-render-pdf,:graph-compose-render-docx,:graph-compose-render-pptx,:graph-compose-templates,:graph-compose-testing,:graph-compose-qa,:graph-compose-coverage -am