Multiple bank accounts

[jo47011]

Hi, first of all a big thanks for that great package 👍

One of my customer has multiple bank accounts where his customer can send the money to. As of my understanding of the code this is currently not possible. We would need to change the code like this (draft only):

class TradeSettlement(Element):
    ...
    payment_means = MultiField(PaymentMeans, required=False, profile=EXTENDED)

Or something like this. Does this makes sense? If you agree I could try to dig into it to get it working and open a PR.

Or do I miss something and assigning multiple seller bank accounts is possible out of the box?

[mconstabel]

Hi,

from me also thanks for this helpful package :)

I also tried this and it worked only with

doc.trade.settlement.payment_means.type_code = "58"
doc.trade.settlement.payment_means.information.add("foo")
doc.trade.settlement.payment_means.payee_account.iban   = "DE1000"

But SpecifiedTradeSettlementPaymentMeans should be a list according to EN 16931?

So it should work as

payment_means = PaymentMeans()
payment_means.type_code = "58"
doc.trade.settlement.payment_means.add(payment_means)

?

[raphaelm]

Happy to accept a PR!

[jo47011]

Done: see https://github.com/pretix/python-drafthorse/pull/67

[jo47011]

Happy to accept a PR!

Hi @raphaelm, I created a PR end of January (see https://github.com/pretix/python-drafthorse/pull/67). Would you be so kind and provide me some feedback. I would need to have the functionality in the main package. Thanks a lot in advance 😄

[raphaelm]

Sorry, I somehow lost track of this. This is only allowed in the EXTENDED profile, are you sure your customer understands the implications of this? Recipients might just reject the invoice as noncompliant to EN16931

[jo47011]

Can someone pls give me a short feedback why there is no progress w/ this issue. I provided a PR nine months ago and never got any feedback at all. Is my solution approach wrong, is it missing tests, or what else? Would like to get this merged/fixed.

Thank you very much 👍

[raphaelm]

The main "problem" is that I have very little time to maintain this library.

The other "problem" is that this PR will break the API for everyone currently using the library, while at the same time providing functionality that creates invoices not compliant ti EN16931 and I'll somehow need to decide what is more important for most users of the library.

[jo47011]

Hi, thank you for your response 😄 I understand but if my approach is not EN16931 compliant how do other users w/ customers w/ multiple banks handle it? I know you may not know the answer ad-hoc. But maybe you can tell me how I could investigate or make it EN16931 compliant. Thank you so much for this package and your feedback 👍

[raphaelm]

Hi, thank you for your response 😄 I understand but if my approach is not EN16931 compliant how do other users w/ customers w/ multiple banks handle it? I know you may not know the answer ad-hoc. But maybe you can tell me how I could investigate or make it EN16931 compliant. Thank you so much for this package and your feedback 👍

🤷 I'll merge it anyways now, since this library tracks ZUGFeRD and not EN16931 it makes the most sense

[kuhntob]

Thanks for merging the change, and PaymentMeans is defined as "0 .. unbounded" in all EN16931 and EXTENDED:

After that's correct, I guess the issue can be closed.