Sales Pack - XInvoice

[Bernhard]

Hi Yuri,

I was busy for a while and just saw yesterday how much you have implemented. Great job!

[yuri]

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?

[dodom2]

We often accept multiple payments per invoice. Its pretty common in the states.

[yuri]

The question is not about payments but payment means. E.g. credit card, cash, etc.

[hom]

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 58

Assignment	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 59

Assignment	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

Assignment	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

*Note to BT-87
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:

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

These should then also be used as preallocation for the BT-81 code 30 and 58.


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.

[yuri]

> 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

[yuri]

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.

[hom]

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.

[yuri]

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.

[yuri]

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.

[hom]

ok, that sounds great.

[hom]

Hi Yuri,

do you think that payment information for electronic invoicing and a description field (BT-22) will be implemented in near future?

[yuri]

I don't know yet. It's risky to hurry with implementation

[hom]

Hi Yuri,

I share your view that stability should come before rapid implementation. My question was more about whether implementation can be expected before the end of the year? Because this is the only way to meet the obligation to use e- invoicing, which comes into force at the beginning of next year.

[yuri]

I think I'll write a tutorial how to add use custom fields in e-invoices.

After some research and analysis I came to a conclusion that the payment terms design we have discussed above will not suit well if we add the Payments feature to Sales Pack in the future.

[Nina]

HI!

As we should already be sending out the first e-invoices... :/
I wanted to take care of the settings in ESPO today.


Maybe I don't have a good overview yet, but I still get the following error messages and can't find where I can currently make the entries.


Invalid invoice.

Failed rule ID: BR-CO-25

In case the Amount due for payment (BT-115) is positive, either the Payment due date (BT-9) or the Payment terms (BT-20) shall be present.


When we started using the sales pack, we actually created fields for ‘Payment due date’. But it doesn't know how to use them now.

Unfortunately, this is the first time I've dealt with e-invoicing. Unfortunately, I haven't found anything in the documentation at the moment.

Or has this not yet been implemented?
I can't quite make heads or tails of the thread here ;D

Maybe you can give me a hint where I can find the settings

[yuri]

Hi Nina,

We have a built-in Due Date field in the Invoice entity type. You need to use it instead of the custom field. You may need to add it to the Detail layout.

[Nina]

Thank you Yuri!

You can't see the wood for the trees...
... it was very obvious.

[hom]

Hello Yuri,

if a global solution for payment processing is not possible, instructions for creating and customizing custom fields would be very helpful.
Many thanks in advance.