There is 0..* for InvoiceReferencedDocument not only 0..1 about zugferd-csharp

[stephanstapel]

Do you have an xml example on how this looks with multiple reference documents?

[mbreig]

Have a look at https://edna-bundesverband.de/wp-content/uploads/ZUGFeRD-2-Umsetzungsempfehlungen-v.2.0.2.pdf page 33 chapter "2.5.3.12" (sorry this document is in German)
I think for every referenced invoice there might be a "ram:InvoiceReferencedDocument"-node with none or one date (BT-26) and the document reference (BT-25). For BT-25 I would take the unique invoice number.

[stephanstapel]

Alright. But how would it look with multiple reference documents?
Like this:

<ram:InvoiceReferencedDocument>
  <ram:IssuerAssignedID>RECHNUNG000</ram:IssuerAssignedID>
  <ram:FormattedIssueDateTime>
    <qdt:DateTimeString format="102">20190902</qdt:DateTimeString>
  </ram:FormattedIssueDateTime>
</ram:InvoiceReferencedDocument>
<ram:InvoiceReferencedDocument>
  <ram:IssuerAssignedID>RECHNUNG000</ram:IssuerAssignedID>
  <ram:FormattedIssueDateTime>
    <qdt:DateTimeString format="102">20190902</qdt:DateTimeString>
  </ram:FormattedIssueDateTime>
</ram:InvoiceReferencedDocument>

?

[mbreig]

Yes that seemed to be correct for me (except the use of the same dokid and -date in both nodes).

I think it is like the additional documents that are included in the xml-file via the node "AdditionalReferencedDocument".

And so there must be an

AddInvoiceReferencedDocument

like there is an

AddAdditionalReferencedDocument

for the included files.

[stephanstapel]

alright. Unfortunately this will break the API, i.e. it'll be necessary to release a new major version then

[mbreig]

I have checked a sample XRechnung-file with a list of two refrenced invoices (your sample above) in the kosit validator and it did not accept this file (with only one referenced invoice everything is fine).
A short look in the ZUGFeRD-reference shows that there is only one "InvoiceReferencedDocument"-node allowed. XRechnung v2.2 says"0..*". And this is not a misprint because the description of this node says: "Eine Gruppe von Informationselementen, die Informationen über eine oder mehrere vorausgegangene Rechnung(en) enthalten"
I hate it.
Because of the different "interpretation" of the e-invoice specification it make no sence at this time to modify your API.
Sorry for creating this issue.
Regards Marcus

[stephanstapel]

Thanks a lot for your investigation!
Unfortunately this is not the first time that there is 'something' between the docs and the implementation.

How about going for a list, stating in the docs that currently only 0..1 is supported by the validators and adding a occurrency check to the validator which is executed automatically before saving a file?

[mbreig]

I think this idea sounds good.