Sales Pack - XInvoice
Collapse
X
-
I read that in Germany it's a requirement to have one payment mean per Invoice. But it's not in all countries that way.
There's is a parameter to limit max number of items in a Link-Multiple field. An admin can set it to 1.Leave a comment:
-
It's better to implement according the original standard. It will be up to user whether to add multiple payment options. If we implement one, it will be impossible to migrate in the future to many without issues.Leave a comment:
-
I don't think it is intended to specify multiple payment methods in an e-invoice. As far as I have checked the available templates and programs, there is always only one payment method to be used. As far as I have seen, there are not even different accounts for a bank transfer. Only one payment method is used with the corresponding information.
If anyone has any other information on this, please write.Leave a comment:
-
Thanks for input.
As the standard allows multiple Payment Means and it's a common practice to offer multiple payment means in an Invoice, we'd rather allow multiple means too.
It could be done with many-to-many relationship. Payment Mean would be a separate entity.Leave a comment:
-
> Please also include the "Description" field from the invoice module in the E-Invoice as an "Invoic note" (BT-22). The field already exists, it is just not yet included in the E-Invoice schema.
It's tricky as one may use Description for internal purposes and not willing the text to be exposed to a customer -
Hi Yuri,
thanks again for the great work. You asked about suggestions. Here we go.
I suggest a new section "Payment information" under Invoice. It should contain the following payment methods:
Code (BT-81) English text (BT-82) German text (BT-82) Information is to be transferred for 30 Credit transfer Überweisung BG-17 58 SEPA credit transfer SEPA Überweisung BG-17 59 SEPA direct debit SEPA Lastschrift BG-19 48 Bank card Bankkarte BG-18 54 Credit card Kreditkarte BG-18 55 Debit card Debitkarte BG-18
BG-17: Informations for (BT-81) code 30 and 58Assignment Name (EN) Name (DE) Fieldtype Enforcing BT-85 Payment account name Kontoinhaber Free text field No BT-84 Payment account identifier Kontonummer/IBAN Free text field Yes BT-86 Payment service provider identifier BIC Free text field Yes (Code 30)
No (Code 58)BT-83 Remittance information Verwendungszweck Free text field No BT-20 Payment terms Zahlungsbedingungen Free text field No
BG-19: nformations for (BT-81)code 59Assignment Name (EN) Name (DE) Feldtyp Enforcing BT-89 Mandate reference identifier Mandatsreferenznummer Free text field Yes BT-90 Bank assigned creditor identifier Gläubiger ID Free text field Yes BT-91 Debited account identifier Kontonummer/IBAN Free text field Yes
BG-18: nformations for (BT-81) code 48, 54 and 55*Note to BT-87Assignment Name (EN) Name (DE) Feldtyp Enforcing BT-87* Payment card primary account number Kartennummer Free text field No BT-88 Payment card holder name Name des Karteninhabers Free text field No
In accordance with the security standards applicable to credit cards, an invoice may not contain the full card number. However, it must show the last 4 to 6 digits of the card. Suggestion "****1234" (show the last four digits).
Suggestion:
Add under Administration > Sales Pack > Settings > Electronic Invoicing a new section with account information. It should contain the fields:These should then also be used as preallocation for the BT-81 code 30 and 58.BT-85 Payment account name Kontoinhaber Free text field BT-84 Payment account identifier Kontonummer/IBAN Free text field BT-86 Payment service provider identifier BIC Free text field
Other task:
Please also include the "Description" field from the invoice module in the E-Invoice as an "Invoic note" (BT-22). The field already exists, it is just not yet included in the E-Invoice schema.
Thanks for the great development. Feel free to ask, if anything is unclear.Leave a comment:
-
We often accept multiple payments per invoice. Its pretty common in the states.Leave a comment:
-
If anybody have thoughts and ideas regarding payment means, how we could better implement it, please share.
As I understand, in Germany an invoice can have only one payment mean. Would we need multiple ones? As the standard allows multiple payment means per invoice. Maybe in some countries it's a common practice to have multiple payment means?
Leave a comment:
-
I don't have an example.
Bind implementation https://docs.espocrm.com/development/di/#binding
Interface:
Code:Espo\Modules\Sales\Tools\Invoice\EInvoice\Preparator
The default implementation:
Code:Espo\Modules\Sales\Tools\Invoice\EInvoice\DefaultPreparator
This should be trivial for programmers who have experience in OOP.
This is not an official guideline. No guarantee that the implementation will not change in the future.Last edited by yuri; 09-13-2024, 10:11 AM. -
Hi Yuri,
I was busy for a while and just saw yesterday how much you have implemented. Great job!
Leave a comment:
-
Hello Yuri,
do you have an example or instructions on how and where the preparator interface can be addressed?Leave a comment:
-
Added a preparator interface. Developers can add additional items to an E-Invoice from custom fields and related entities.Leave a comment:
Leave a comment: