AdditionalReferencedDocument - AttachmentBinaryObject

[DasElias]

Hi,

two questions regarding the AdditionalReferencedDocument tag.

• When I attach an XML file (mimeCode gets mapped to application/xml), I get a Mustang validation error which says essentially that application/xml is not a valid mimeCode. I have tried the XRechnung and the Extended Profile and the issue exists in both. For the extended profile, the standard clearly does not include application/xml as valid MIME type. Is there any workaround how an XML file can be attached; and why is the mapping to application/xml even there, if this seems not to be valid?
• Is there any reason why one can't attach a AttachmentBinaryObject when calling TradeLineItem.AddAdditionalReferencedDocument even though this seems to be supported by the ZUGFeRD specification?

Kind regards, Elias

[stephanstapel]

• XML is allowed because of the comment in: https://projekte.kosit.org/xrechnung/xrechnung/-/issues/59 Happy to remove it though
• For whatever reason, binary data cannot be attached to AdditionalReferencedDocuments on item level. According to the FacturX 1/ ZUGFeRD 2.2 specification:

[DasElias]

Thanks a lot for the quick response. I am not sure about the difference between SpecifiedLineTradeSettlement > AdditionalReferencedDocument vs. SpecifiedLineTradeAgreement > AdditionalReferencedDocument, but it seems that with the latter it is indeed possible to attach binary data on item level. Initially, I was referring to SpecifiedLineTradeAgreement > AdditionalReferencedDocument, hence my confusion since binary data can be attached via this property.

[stephanstapel]

Interesting. I have no idea why ZUGFeRD 2.2 looks so different. The latest version I can find on gefeg.com (https://portal3.gefeg.com/invoice/tthome/index/617afdc4-623f-44e0-a05b-5b878840e508?page=1&useSelectedItemPosition=true):

ApplicableHeaderTradeAgreement:

TradeLineItem:

which would be in line with the current implementation

[DasElias]

If we are both talking about this link, then, yes and no.

It should be noted that the node AdditionalReferencedDocument appears not only twice, but three times. The first two occurrences are the ones that you have already mentioned, which reflect the current implementation. However, there is the third occurence in SpecifiedLineTradeAgreement which seems to allow to reflect binary attachments on document line level.

If I were to submit a pull request to map the third node as well, would you have any idea how the library API implementation could be named to avoid confusion with the method that already exists? In my opinion, it would make sense to overload the method item.AddAdditionalReferencedDocument as follows:

• void AddAdditionalReferencedDocument(string id, DateTime? date = null, ReferenceTypeCodes code = ReferenceTypeCodes.Unknown) (current implementation)
• void AddAdditionalReferencedDocument(string id, AdditionalReferencedDocumentTypeCode typeCode, DateTime? issueDateTime = null, string name = null, ReferenceTypeCodes referenceTypeCode = ReferenceTypeCodes.Unknown, byte[] attachmentBinaryObject = null, string filename = null) (new overload, same parameters as method on InvoiceDescriptor level)

[stephanstapel]

Can you please check my commit https://github.com/stephanstapel/ZUGFeRD-csharp/commit/1e032bb2866b9b8bdb7850c60170ab7a64a34738? I guess this should write the correct values.

I have no idea how to implement the third occurrence of AdditionalReferencedDocuments and would leave this for later.

Also I have added the overloaded function as suggested. Please let me know if it works for your use case!

[stephanstapel]

@DasElias can you confirm that the solution is now as desired?