The problem is not that ZUGFeRD data are created in programms and pass through multiple steps of complex work flows. The real problem is that ZUGFeRD data are invisible. That makes it difficult to ensure that they are correct. No document should have any difference between the visible data and the invisible data. But how can you check that?
PDFUnit reads values from the ZUGFeRD data and compares them with the data of a PDF page or a page region:
@Test public void validateZUGFeRD_CustomerNameInvoiceIdIBAN() throws Exception { String filename = "zugferd10/ZUGFeRD_1p0_BASIC_Einfach.pdf"; XMLNode nodeBuyerName = new XMLNode("ram:BuyerTradeParty/ram:Name"); XMLNode nodeInvoiceId = new XMLNode("rsm:HeaderExchangedDocument/ram:ID"); PageRegion regionPostalTradeAddress = createRegionPostalAddress(); PageRegion regionInvoiceId = createRegionInvoiceId(); AssertThat.document(filename) .restrictedTo(FIRST_PAGE) .restrictedTo(regionPostalTradeAddress) .hasText() .containingZugferdData(nodeBuyerName) ; AssertThat.document(filename) .restrictedTo(FIRST_PAGE) .restrictedTo(regionInvoiceId) .hasText() .containingZugferdData(nodeInvoiceId) ; }
Sometimes the XML data and the visible data are not compatible with each other. One example is the value of 'invoice total' in the document 'ZUGFeRD_1p0_BASIC_Einfach.pdf'. The PDF page contains the value with a German decimal comma and the ZUGFeRD data contain it with an English decimal point. In such a case more sophisticated test methods may help, such as those described in chapter 3.39: “ZUGFeRD”.