SpecifiedTradePaymentTerms should be [0..n], but is [0..1]

[sude22]

Hello,
and first of all thank you for the great work on this project.

When importing an invoice, I noticed that there is a property "PaymentTerms". It is filled with the content from "SpecifiedTradePaymentTerms".
However, in my invoice there are two"SpecifiedTradePaymentTerms" sections.

Shouldn't the "PaymentTerms" property then be a list?

Example:
<ram:SpecifiedTradePaymentTerms>
<ram:Description>Zahlbar bis 07.01.2024 ohne Abzug</ram:Description>
<ram:DueDateDateTime>
<udt:DateTimeString format="102">20240107</udt:DateTimeString>
</ram:DueDateDateTime>
</ram:SpecifiedTradePaymentTerms>
<ram:SpecifiedTradePaymentTerms>
<ram:Description>Zahlbar bis 15.12.2023 3,00% Skt= 1039,84</ram:Description>
<ram:DueDateDateTime>
<udt:DateTimeString format="102">20231215</udt:DateTimeString>
</ram:DueDateDateTime>
<ram:ApplicableTradePaymentDiscountTerms>
<ram:BasisAmount currencyID="EUR">1072.00</ram:BasisAmount>
<ram:CalculationPercent>3.00</ram:CalculationPercent>
</ram:ApplicableTradePaymentDiscountTerms>
</ram:SpecifiedTradePaymentTerms>

BTW: It would be excellent if the fields in "ApplicableTradePaymentDiscountTerms" could also be imported, as then automatic processing of the discount values would be possible.

[stephanstapel]

Thanks for your initiative!
I'd be more than happy if you could issue a pull request. Please remember to implement both reader and write and add test cases

[jochenkirstaetter]

Hi @stephanstapel

Kindly assign this one to me.
I'm going to implement the [0..n] cardinality. I might need this for my current assignment where multiple payment terms are required.

Cheers, JoKi

[stephanstapel]

@jochenkirstaetter: thanks! Please remember backwards compatibility and please add test cases.

[jochenkirstaetter]

@stephanstapel Of course, thanks for the reminder.

[jochenkirstaetter]

@stephanstapel

Interestingly, the InvoiceProvider in the test project already provides multiple payment terms, although as a single one due to the existing cardinality.

desc.SetTradePaymentTerms("Zahlbar innerhalb 30 Tagen netto bis 04.04.2018, 3% Skonto innerhalb 10 Tagen bis 15.03.2018");

I'm going to use this example as base for my implementation.

[stephanstapel]

@stephanstapel

Interestingly, the InvoiceProvider in the test project already provides multiple payment terms, although as a single one due to the existing cardinality.

desc.SetTradePaymentTerms("Zahlbar innerhalb 30 Tagen netto bis 04.04.2018, 3% Skonto innerhalb 10 Tagen bis 15.03.2018");

I'm going to use this example as base for my implementation.

I guess I stole the example from ZUGFeRD 1.0 sample data :)

[jochenkirstaetter]

Hm, interesting.

The specification of Version XRechnung 2.2.0 | Fassung vom 27.01.2022 specifies the Payment Terms as a single, optional element.

Sounds a bit like a challenge to apply the right profile handling to it.

Game on...

@sude22 - could you please provide me a link or source of the specs in your original post? Thanks a bunch.

PS: Conversion to a List has been done already, I'm currently in the validation phase. Hence, stumbling over those specification details of each version and profile.

[stephanstapel]

Just found this in ZUGFeRD 2.2 specification:

cardinality is a bit weird. This would meet your screenshot about XRechnung/ EN16931/ Comfort.

[jochenkirstaetter]

Thanks @stephanstapel ,
that would mean, that multi cardinality seems to be bound to Extended only.

OK, this is mainly bothering the writing process, as the reading is always a loop. I guess, I'll add conditional writing based on the Profile. That should resolve the issue.

Cheers, JoKi