E-Invoice Buyer RegistrationName always show Seller Company Name vs Account/BuyerName

[philippe.kirschey]

Hi,

I'd like to report a bug in the E-Invoice (XRechnung/UBL) generation of the Sales Pack.

Environment

• EspoCRM: latest version
• Sales Pack: latest version
• Format: XRechnung 3.0 (UBL)

Problem

When generating an E-Invoice, the RegistrationName of the AccountingCustomerParty (Buyer) always contains the Seller's company name instead of the actual customer's name.

Both Seller and Buyer end up with the identical RegistrationName in the generated XML:

<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Beispiel GmbH</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Beispiel GmbH</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>

Steps to reproduce

1. Configure Seller Information in Admin → Sales Pack Settings → Electronic Invoicing (e.g. Company Name = "Beispiel GmbH")
2. Create an Invoice with a linked Account (e.g. "Customer Company Name")
3. The Invoice field buyerName is correctly populated with the customer name
4. Generate E-Invoice (XRechnung UBL)
5. Open the generated XML → AccountingCustomerParty > RegistrationName shows the Seller's name, not the customer's

Expected behavior

The Buyer RegistrationName (BT-44) should be populated from either:

• account.name (the linked Account's name), or
• the Invoice field buyerName

Actual behavior

The DefaultPreparator appears to use the sellerName field (from Seller Information settings) for both Seller and Buyer RegistrationName. The buyerName field on the Invoice entity exists but is ignored during E-Invoice generation.

Impact

This makes the generated E-Invoice invalid for practical use, as the Buyer name is a mandatory field (BT-44) and must identify the actual customer, not the seller.

Thank you for looking into this!

Best
Philippe

[yuri]

Thank you for reporting. Fixed in v4.2.0. It was a regression from the latest minor release.