Repository navigation
Support the electronic address of seller and buyer (BT-34, BT-49) - #64
Merged
halfbyte merged 2 commits intoOct 21, 2026
Merged
Conversation
2 of 4 tasks
Adds TradeParty#electronic_address and #electronic_address_scheme_id (EN 16931 BT-34 / BT-49) as URIUniversalCommunication. Written only with a scheme (BR-62, BR-63) and left out of the ShipToTradeParty, where the profile does not use it.
ahmedm10
force-pushed
the
MP-53295-electronic-address-upstream
branch
from
October 19, 2026 17:14
ab44284 to
496e369
Compare
ahmedm10
marked this pull request as ready for review
October 19, 2026 17:14
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
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.
Problem
A trade party can't carry an electronic address (BT-34 for the seller, BT-49 for the buyer). These are the
URIUniversalCommunicationelement of the party itself, which says where electronic documents for that party go. The only email the gem can write today belongs to the contact (DefinedTradeContact), which says whom to call. Peppol routing and XRechnung expect the party's address, and for a plain ZUGFeRD invoice it tells the recipient where to send replies.Change
TradeParty#electronic_addressand#electronic_address_scheme_idwrite<ram:URIUniversalCommunication><ram:URIID schemeID="…">…</ram:URIID></ram:URIUniversalCommunication>after the postal address, where the CII schema places it. Version 2 only.EMfor an email address or9930for a German VAT number from the EAS code list. This followsglobal_id, which is also left out without its scheme.ShipToTradeParty. The invoice writes the buyer a second time as the ship-to party, and the Factur-X EN 16931 schematron reportsURIUniversalCommunicationthere as "not used in the given context". It follows the existingexclude_taxflag, which already keeps the buyerIDout of the ship-to party.Existing callers get the same XML as before.
Tests
Three new tests in
test/invoice_test.rb: seller and buyer address, each written once, also validated against the schematron (based onmake_eu_invoice); no element without a scheme; no element by default. The full suite passes.