XRechnungImporter incorrectly can't parse UBL Invoice

[Sarenor]

The XRechnungImporter extends ZUGFeRDImporter, which uses

    public boolean canParse() {
        String meta = this.getMeta();
        return meta != null && meta.length() > 0 && (meta.contains("SpecifiedExchangedDocumentContext") || meta.contains("ExchangedDocumentContext"));
    }

as it's canParse method. As far as I can tell UBL documents don't contain either of those, so the XRechnungImporter now rejects potentially theoretically correct UBL documents.

[Sarenor]

Should I add a check for CustomizationID to this in a PR as a fix?

[Sarenor]

getVersion() has a similar problem.

[Sarenor]

XRechnungImporter should probably also override getVersion(), too.

Ahhh. I think I understand now. I think I need to use the ZUGFeRDInvoiceImporter for UBL files, is that correct?

But I have to use the extractInvoice() Method of the ZUGFeRDInvoiceImporter because the ZUGFeRDImporter methods can't extract the UBL info. Could you elaborate how this is intended to work?

[jstaerk]

Could you elaborate how this is intended to work?

XRechnungimporter and ZUGFeRDImporter are shorthand versions to quickly get some of the most important attributes. The real class to get everything is ZUGFeRDinvoiceImporter. XR and ZFimporter are supposed to work identical, whereas for the XR importer I would expect that it accepts XML input and for ZF I would expect that it support PDF input, but I believe both support, both which is fine. ZFimporter is the predecessor of the invoiceimporter and, since only few attributes were targeted, was based on Xpath. As regards UBL vs CII: only the invoiceimporter currently supports UBL (and maybe not even complete one would have to check).

As mentioned in #435 my suggestion is to re-base the ZF (and XR) importer on the invoiceimporter so that the parsing has only to be written once in three versions (UBL, CII2016b=FX and CII2013b=ZF1) and not once for the complete story and again in XPath in three versions.