I'm looping a function, which calls ZUGFeRDImporter.extract() every time it get's looped.
After calling ZUGFeRDImporter.extract() I move the processed PDF file automated, but it wasn't possible, because ZUGFeRDImporter.extract() opens a BufferedInputStream for calling ZUGFeRDImporter.extractLowLevel(InputStream pdfStream), but never closes it.
So for the filesystem the PDF is forever locked. I fixed it for my project by adding a simple bis.close() to ZUGFeRDImporter.extract() after calling extractLowLevel().
Is this a bug or is there a reason it is not closed in the original lib?

The link to the documenation in the README.md section Running should point to https://github.com/ZUGFeRD/mustangproject/blob/master/doc/ZugferdDev.en.pdf.

Also there is a bracket too much at the end of the line.

I also think the text should be More information in the mustang documentation. as information has not plural.

test cases are already documented in the comments of the function :-)

Hello,

For my projects, I don't need to actually build an app from the library.
The command line looks good, but sadly it can't be reliably automated.

I would love to be able to specify the parameters directly when calling the tar file.
For instance, when combining a PDF and an XML to generate a FacturX file:

java -jar mustang-1.5.4.jar -c myInvoice.pdf myInvoice.xml myInvoice-facturx.pdf 2 basic

Do you think it would be possible?

The PDFs generated from your testcases are not PDF/A compliant.

The 3-Heights PDF validator says, that the XMP Metadata are corrupt. Multiple PDF Viewers confirm this. As you can see the metadata is not properly written to the PDF.

File    testout-MustangGnuaccountingBeispielRE-20151008_504newEdge.pdf
Compliance  pdfa-3u
Result  Document does not conform to PDF/A.
Details 

Validating file "testout-MustangGnuaccountingBeispielRE-20151008_504newEdge.pdf" for conformance level pdfa-3u

pdfaExtension:schemas/*[0] :: Missing required field 'valueType' in value type 'Schema'.

The document does not conform to the requested standard.

The document's meta data is either missing or inconsistent or corrupt.

Done.

currently version 1 is the default and version2 has to be enabled by default (I think it's sth like setZUGFeRDVersion()). In future, v2 should be default and v1 needs to be enabled by default.
How you can help:
This is a trivial change since I think it's the change of the value of is a single member variable.
Send me a pull request. And by all means, change existing unit tests to factur-x and write unit tests for ZF2.

Could a logging framework be integrated? In some places, errors are caught. As return value, there is then true or false and one does not recognize the actual error:

org.mustangproject.ZUGFeRD.ZUGFeRDExporter.getA1ParserValidationResult (PreflightParser)

When I submitted Mustang112rc1realsample.pdf it was tested against the new version of the ZUGFeRD-validator which is, AFAIK, to supersede the Storck checker and it failed with two warnings and three errors.

Warning A was:
Line 2
Warning 3010
XPath /rsm:CrossIndustryDocument/@{http://www.w3.org/2001/XMLSchema-instance}schemaLocation
Element CrossIndustryDocument
Text Hinweis. Das Element oder Attribut gehört nicht zum gewählten Profil. Bei
Verwendung kann nicht garantiert werden, dass der Rechnungsempfänger die
Daten verarbeiten kann (bilaterale Vereinbarung).

Warning B was:
Line N/A
Warning 3007
XPath N/A
Element N/A
Text Es konnten keine Angaben wie z.B. Geschäftsführer, Handelsregistereintrag
oder ähnliches gefunden werden. (SubjectCode=REG). Bitte prüfen Sie, ob Sie diese Daten ggf. im Freitext angegeben haben oder diese Angaben für Ihre
Rechnungsstellung nicht relevant sind.

Error C was:
Line 123
Error 3005
XPath /rsm:CrossIndustryDocument/rsm:SpecifiedSupplyChainTradeTransaction/ram:
IncludedSupplyChainTradeLineItem
Element N/A
Text Rechenfehler: TradeAgreement -> NetPrice.ChargeAmount =
grossPrice.ChargeAmount + Sum(grossPrice.Charges) - Sum(
grossPrice.Allowances)" + "(160 != 171,2)

Error D was:
Line 155
Error 3005
XPath /rsm:CrossIndustryDocument/rsm:SpecifiedSupplyChainTradeTransaction/ram:
IncludedSupplyChainTradeLineItem
Element N/A
Text Rechenfehler: TradeAgreement -> NetPrice.ChargeAmount =
grossPrice.ChargeAmount + Sum(grossPrice.Charges) - Sum(
grossPrice.Allowances)" + "(0,79 != 0,94)

Error E was:
Line 187
Error 3005
XPath /rsm:CrossIndustryDocument/rsm:SpecifiedSupplyChainTradeTransaction/ram:
IncludedSupplyChainTradeLineItem
Element N/A
Text Rechenfehler: TradeAgreement -> NetPrice.ChargeAmount =
grossPrice.ChargeAmount + Sum(grossPrice.Charges) - Sum(
grossPrice.Allowances)" + "(0,1 != 0,12)

If pushed in github, the project should be compileable. Currently, some classes in the directory model that are referenced in org.mustangproject.ZUGFERD.ZUGFeRDExporter are missing.

import org.mustangproject.ZUGFeRD.model.AmountType;
import org.mustangproject.ZUGFeRD.model.CodeType;
import org.mustangproject.ZUGFeRD.model.CountryIDType;
import org.mustangproject.ZUGFeRD.model.CreditorFinancialAccountType;
import org.mustangproject.ZUGFeRD.model.CreditorFinancialInstitutionType;
import org.mustangproject.ZUGFeRD.model.CrossIndustryDocumentType;
import org.mustangproject.ZUGFeRD.model.DateTimeType;
import org.mustangproject.ZUGFeRD.model.DocumentCodeType;
import org.mustangproject.ZUGFeRD.model.DocumentContextParameterType;
import org.mustangproject.ZUGFeRD.model.DocumentLineDocumentType;
import org.mustangproject.ZUGFeRD.model.ExchangedDocumentContextType;
import org.mustangproject.ZUGFeRD.model.ExchangedDocumentType;
import org.mustangproject.ZUGFeRD.model.IDType;
import org.mustangproject.ZUGFeRD.model.IndicatorType;
import org.mustangproject.ZUGFeRD.model.LogisticsServiceChargeType;
import org.mustangproject.ZUGFeRD.model.NoteType;
import org.mustangproject.ZUGFeRD.model.ObjectFactory;
import org.mustangproject.ZUGFeRD.model.PaymentMeansCodeType;
import org.mustangproject.ZUGFeRD.model.PercentType;
import org.mustangproject.ZUGFeRD.model.QuantityType;
import org.mustangproject.ZUGFeRD.model.SupplyChainEventType;
import org.mustangproject.ZUGFeRD.model.SupplyChainTradeAgreementType;
import org.mustangproject.ZUGFeRD.model.SupplyChainTradeDeliveryType;
import org.mustangproject.ZUGFeRD.model.SupplyChainTradeLineItemType;
import org.mustangproject.ZUGFeRD.model.SupplyChainTradeSettlementType;
import org.mustangproject.ZUGFeRD.model.SupplyChainTradeTransactionType;
import org.mustangproject.ZUGFeRD.model.TaxCategoryCodeType;
import org.mustangproject.ZUGFeRD.model.TaxRegistrationType;
import org.mustangproject.ZUGFeRD.model.TaxTypeCodeType;
import org.mustangproject.ZUGFeRD.model.TextType;
import org.mustangproject.ZUGFeRD.model.TradeAddressType;
import org.mustangproject.ZUGFeRD.model.TradeAllowanceChargeType;
import org.mustangproject.ZUGFeRD.model.TradePartyType;
import org.mustangproject.ZUGFeRD.model.TradePaymentTermsType;
import org.mustangproject.ZUGFeRD.model.TradePriceType;
import org.mustangproject.ZUGFeRD.model.TradeProductType;
import org.mustangproject.ZUGFeRD.model.TradeSettlementMonetarySummationType;
import org.mustangproject.ZUGFeRD.model.TradeSettlementPaymentMeansType;
import org.mustangproject.ZUGFeRD.model.TradeTaxType;

Exception in thread "AWT-EventQueue-0" java.lang.NoSuchMethodError: org.apache.pdfbox.pdmodel.common.filespecification.PDEmbeddedFile.getByteArray()[B
at org.mustangproject.ZUGFeRD.ZUGFeRDImporter.extractLowLevel(ZUGFeRDImporter.java:107)
at org.mustangproject.ZUGFeRD.ZUGFeRDImporter.extract(ZUGFeRDImporter.java:64)

This happens in 1.4.0 as well as in 1.5.1.

ZUGFeRD/ZUV#11 in reality is a Mustangproject error

Hi!

Mustang 1.5.3 and your very own PDF file (from your website) "MustangGnuaccountingBeispielRE-20170509_505blanko.pdf"

java -jar mustang-1.5.3.jar -e 
Source PDF (default: invoice.pdf):MustangGnuaccountingBeispielRE-20170509_505blanko.pdf
ZUGFeRD XML (default: ZUGFeRD-invoice.xml):out2.xml
Jul 23, 2018 9:00:33 AM org.apache.pdfbox.pdmodel.graphics.color.PDDeviceRGB suggestKCMS
INFORMATION: To get higher rendering speed on java 8 oder 9,
Jul 23, 2018 9:00:33 AM org.apache.pdfbox.pdmodel.graphics.color.PDDeviceRGB suggestKCMS
INFORMATION:   use the option -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider
Jul 23, 2018 9:00:33 AM org.apache.pdfbox.pdmodel.graphics.color.PDDeviceRGB suggestKCMS
INFORMATION:   or call System.setProperty("sun.java2d.cmm",    "sun.java2d.cmm.kcms.KcmsServiceProvider")
Exception in thread "main" java.lang.NullPointerException
	at java.util.Objects.requireNonNull(Objects.java:203)
at java.nio.file.Files.write(Files.java:3290)
at org.mustangproject.toecount.Toecount.main(Toecount.java:371)

It works with the PDF file zugferd_invoice.pdf which I linked in #60

When I try to attach custom xml with the new factory based approach no XML file is attached to my PDF.

@yankee42 I guess the following code should have worked for that purpose?

	try {
			ZUGFeRDExporter zea1=new ZUGFeRDExporterFromA1Factory().setProducer("My Application").setCreator("Test").loadFromPDFA1("./Source.pdf");
			String ownZUGFeRDXML = "<some><xml attrib='value'/></some>";
			zea1.setZUGFeRDXMLData(ownZUGFeRDXML.getBytes());
			zea1.export("Target.pdf");
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

As published on http://www.ferd-net.de/aktuelles/meldungen/kommentierung-zugferd-2.0.html
The issue is that as far as I understood neither the schema nor schematron files are already available for the public

Currently one has to provide classes with partially difficult interfaces in order to export the XML for a ZUGFeRD file. This could also be done with setters, so that one can create a invoice with something like

ZUGFeRDProduct zp=new ZUGFeRDProduct();
zp.setText("Something").setUnit("C61").setCurrency("EUR").setPrice(123);
ZUGFeRDItem zit=new ZUGFeRDItem();
zit.setQuantity(5).setProduct(zp);
ZUGFeRDInvoice zin=new ZUGFeRDInvoice();
zi.addItem(zit);

if PDFattachZugferdFile had not been executed

I created a test file containing a few words in Microsoft Word, and I generated a PDF/A1 file (using the relevant option when outputing the PDF). This file is validated successfully as PDF/A1 using online validators.

However, when I use the combine option (with the sample file ZUGFeRD2-invoice.xml)

java -jar mustang-1.5.5-SNAPSHOT.jar -c --source "test.pdf" --source-xml "ZUGFeRD2-invoice.xml" --out "out.pdf" --zugferd-version 2 --zugferd-profile m

I get (with any profile, actually):

java.lang.NullPointerException
        at org.mustangproject.ZUGFeRD.ZUGFeRDTransactionModelConverter$Totals.<init>(ZUGFeRDTransactionModelConverter.java:1042)
        at org.mustangproject.ZUGFeRD.ZUGFeRDTransactionModelConverter.<init>(ZUGFeRDTransactionModelConverter.java:90)
        at org.mustangproject.ZUGFeRD.ZUGFeRD1PullProvider.createZugferdXMLForTransaction(ZUGFeRD1PullProvider.java:61)
        at org.mustangproject.ZUGFeRD.ZUGFeRD1PullProvider.generateXML(ZUGFeRD1PullProvider.java:89)
        at org.mustangproject.ZUGFeRD.ZUGFeRDExporter.PDFattachZugferdFile(ZUGFeRDExporter.java:328)
        at org.mustangproject.ZUGFeRD.ZUGFeRDExporter.setZUGFeRDXMLData(ZUGFeRDExporter.java:453)
        at org.mustangproject.toecount.Toecount.performCombine(Toecount.java:511)
        at org.mustangproject.toecount.Toecount.main(Toecount.java:298)

Note that it does work if I use ZUGFeRD v1.

This sample file can be found here: https://we.tl/t-59RVwfXbmf

I tried to convert a PDF/A-1a file to PDF/A-3a using mustang. According to http://www.mustangproject.org/use.html#pdfa3, this conversion can be done using the command line.

As a result, I created a new PDF file. This PDF is not valid according to verapdf, because "The value of pdfaid:part shall be the part number of ISO 19005 to which the file conforms.".

The result of exiftool shows, that the part is sill set to 1 instead of 3.

So, is it possible to set the correct part number within the conversion process?

if the attached XML is attached to the attached PDF the checker.ferdmc.com reports a errorneous xmp packet in the resulting document

reported by Gait Boxman

The ZUGFeRD XML structure might break if the customer name or the positions e.g. contain ', ", < or > . We need to do some escaping or change the way the XML is generated.

if not specifically disabled, exported PDF files should be closed automatically

Setting up a continuous integration server could reduce the risk of merging changes that do not build or that build only one some developers machines.

For OpenSource there are many free services, such as Travis-CI or CircleCI. They integrate with github, so that the build status can be displayed for each PR etc. Setup is incredibly easy.

What do you think?

Validating the MustangGnuaccountingBeispielRE-20171118_506.pdf ZF2 examples returns

• [CII-SR-002] - TestIndicator should not be present
• [CII-SR-013] - Name should not be present and a couple of
• [CII-DT-031] - currencyID should not be present
  report.zip

https://www.pdf-online.com/osa/validate.aspx reports invalid PDF A/3 on the current development version (1.4.1 snapshot)

Result | Document does not conform to PDF/A.
-- | --
Details | Validating file "testout-MustangGnuaccountingBeispielRE-20170509_505new.pdf" for conformance level pdfa-3uXMP packet header missing.XMP packet trailer missing.The document does not conform to the requested standard.The document's meta data is either missing or inconsistent or corrupt.Done.

The class ZUGFeRDExporter has a number of methods which only have a meaning at a certain point in time. For example:

ZUGFeRDExporter zugFeRDExporter = new ZUGFeRDExporter();
zugFeRDExporter.PDFmakeA3compliant(/* .. */);
zugFeRDExporter.setConformanceLevel("A"); // Meaningless - import already happened
zugFeRDExporter.ignoreA1Errors(); // Meaningless - import already happened

Calling some methods early will cause errors:

ZUGFeRDExporter zugFeRDExporter = new ZUGFeRDExporter();
zugFeRDExporter.export("myFile"); // NullPointerException
zugFeRDExporter.PDFattachZugferdFile(/* ... */); // NullPointerException

In my opinion this makes the API less intuitive. Also it makes this class quite huge, because it is doing several unrelated tasks (such as loading and what comes after that).

I'd propose to fully initialize the document in the constructor and perform any loading tasks in factory methods or a separate factory class. I created a draft for that her. This would change the API as follows:

1. Simply loading a file:

   // OLD:
   ZUGFeRDExporter zugFeRDExporter = new ZUGFeRDExporter();
   zugFeRDExporter.loadPDFA3("myFile.pdf");
   
   // NEW:
   ZUGFeRDExporter zugFeRDExporter =
       ZUGFeRDExporter.createFromPDFA3("myFile.pdf");

2. Load a PDF/A1 file with default options:

   // OLD:
   ZUGFeRDExporter zugFeRDExporter = new ZUGFeRDExporter();
   zugFeRDExporter.PDFmakeA3compliant("myFile.pdf", "a", "b", true)
   
   // NEW:
   ZUGFeRDExporter zugFeRDExporter =
       new ZUGFeRDExporterFactory().createFromPDFA1("myFile.pdf", "a", "b", true);

3. Loading a PDF/A1 file with extra options

   // OLD:
   ZUGFeRDExporter zugFeRDExporter = new ZUGFeRDExporter();
   zugFeRDExporter.setConformanceLevel("A");
   zugFeRDExporter.ignoreA1Errors();
   zugFeRDExporter.PDFmakeA3compliant("myFile.pdf", "a", "b", true)
   
   // NEW:
   ZUGFeRDExporter zugFeRDExporter =
       new ZUGFeRDExporterFactory()
           .setConformanceLevel("A")
           .ignoreA1Errors()
           .createFromPDFA1("myFile.pdf", "a", "b", true);

This would make it impossible to call methods that don't make sense at a certain moment in time (as demonstrated in the beginning). In my opinion that would make the API more intuitive.

Would this be desired? In this case I'd work a little more on my draft an create a pull request. What would I need to be aware of? Must the API be backward compatible (keeping old methods marked as deprecated)?

Is it possible to offer the Mustang library without the included dependencies in the repository. The dependencies should be defined in the included pom.xml.
I am using the library in my environment and there are problems with jaxb. The integration of the library is done with Gradle. In case of version conflicts it resolves gradle. Currently this doesn't work, because all dependencies have been packed into Mustang.jar.

I set up a new java project as described here:
http://www.mustangproject.org/use.html

<repositories>
<repository>
    <id>mustang-mvn-repo</id>
    <url>https://raw.github.com/ZUGFeRD/mustangproject/mvn-repo/</url>
</repository>
</repositories>
<dependencies>
<dependency>
    <groupId>org.mustangproject.ZUGFeRD</groupId>
    <artifactId>mustang</artifactId>
    <version>1.5.2</version>
</dependency>
<dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1.1</version>
</dependency>
<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-impl</artifactId>
    <version>2.2.5</version>
</dependency>
</dependencies>

It does not work, the jar is not found.
[WARNING] The POM for org.mustangproject.ZUGFeRD:mustang:jar:1.5.2 is missing, no dependency information available
When I downgrade to 1.5.1 it works:

 <dependency>
    <groupId>org.mustangproject.ZUGFeRD</groupId>
    <artifactId>mustang</artifactId>
    <version>1.5.1</version>
</dependency>

Since this package uses the shade plugin, classes from org.apache.pdfbox and org.apache.fontbox are copied into the jar in the package phase. This is great for creating a standalone executable jar to execute from the commandline as it includes everything needed in the specific version.

When using the package as a library in a project that also depends on pdfbox or fontbox, the copied classes may conflict with the versions defined as dependencies of the project. For example the version specified in mustangproject is 2.0.5 but the project using mustangproject needs 2.0.8, leading to conflicts.

In my case, version 2.0.8 of pdfbox fixes an issue with embedding subsets of fonts in PDF/A files. Normally when specifying a different version in the project using mustangproject I would add pdfbox to the dependencies and maven would load my version instead of the version mustangproject depends on. Unfortunately this is not possible since mustangproject already provides version 2.0.5 copied to the jar.

Feedback from an external party that the reason why the Storck checker on http://checker.ferdmc.com/ is not able to extract the XML from the PDF is that the way the XML file was embedded violated Abb. 119 of the Zugferd-Standard.

I'm currently waiting for a response to my (german) reply on 27.06. :
Um nochmal auf die XML-Einbettung/PDF-A-Gültigkeit zurückzukommen:
MustangGnuaccountingBeispielRE-20150613_503.pdf hat immer noch den PDF
status "XML extrahierbar" und den XML-Status ungültig. Ich habe mit
iText RUPS mal reingeschaut und dort finde ich im
/Catalog ein
/AF mit
/Filespec und darunter
/AFRelationship()
/UF
/EF()
/UF()
Stream()
/Subtype()
/Type()
/Length()
/F() (verweist auch auf den Stream)
/Desc()
/Type
/F()
/Names()
/EmbeddedFiles()
/Names()
ZUGFeRD-invoice.xml()
Verweis auf die File specification dictionary()

()=in Abb. 119 angegeben
(*)=mit Ihnen besprochen

http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx erkennt die Datei
auch durchaus als valide PDF-A-Datei an, insofern die Frage: Wo genau
entspricht die Datei nicht dem PDF-A-Standard und/oder Ihrer Abb. 119?

it's currently disabled because it throws errors which should be corrected

Since the ZF2 extended profile has finally been published, one could check if it can be used again and is still valid
How you could help:
AFAIK the original code has just been commented out to be en16931 compatible for factur-x. Send me a PR with that code again active.

In order to be able to switch to the german translation of the mustangproject.org website we need it to run e.g. in Wordpress

Gnuaccounting can export to ZUGFeRD and OpenTrans (http://www.opentrans.de/). I'd be willing to relicense the according code (Gnuaccounting is under the GPL) under the APL so that the Gnuaccounting OpenTrans export code can be used in Mustangproject.

in order to embed custom xml it should be possible to specify the ZUGFeRD profile, not only on code level but also in the combine option of toecount

apparently there were changes after the public preview, e.g. the file name now seems to be zugferd-invoice again.

How you can help:

• Check the specs if the filename is specified at all (since it's anyway in the metadata it's possible that it's arbitrary in which case we could leave it with factur-x)
• Check if there were any other last minute changes
• REMOVE the backward-compatibility layer (factur-x invoices currently also contain a ZF1 zugferd-invoice.xml, this is now no longer possible)
• ZF2 should become standard in Mustangproject so we need a little method to enable factur-x instead (i.e. change the filename).

The CLI tool returns with an exit code of 0 when there are fatal errors, like

• PDF input file is not PDF-A
• invalid arguments (ex. "--zugferd-profile gfgdf")

This makes it difficult to catch fatal errors from a calling application. We have to catch output from STDERR, which may also contain warnings which we may choose to ignore. Parsing STDERR is an unreliable way to check for errors.

The CLI tool should return witn a nonzero exit code if there are fatal errors.

The latest release 1.5 is missing from the maven repository mvn-repo.

Is the answer in #1 still current regarding a merge with konik.io? Are there any plans otherwise to publish the packages maven central or jcenter?

The extraction of a ZUGFeRD-Document bring a Nullpointer-Error
Error at line 86 form ZUGFeRDImporter Class.

java.lang.NullPointerException: null
at org.mustangproject.ZUGFeRD.ZUGFeRDImporter.extractLowLevel(ZUGFeRDImporter.java:86) ~[mustang-1.5.1.jar:?]
at org.mustangproject.ZUGFeRD.ZUGFeRDImporter.extract(ZUGFeRDImporter.java:63) ~[mustang-1.5.1.jar:?]
at de.css.global.zugferd.ZugFerdTools.initialisiereZUGFeRDImporter(ZugFerdTools.java:134) ~[classes/:?]
at de.css.global.zugferd.ZugFerdTools.(ZugFerdTools.java:95) ~[classes/:?]
at de.css.fibu.beleg.RechnungImporter.erzeugeFibuBelege(RechnungImporter.java:106) [classes/:?]
at de.css.fibu.beleg.FibuBelegRechnungLogic$1.doWork(FibuBelegRechnungLogic.java:213) [classes/:?]
at de.integris.kit.ctl.ControlableThread.run(ControlableThread.java:426) [ikit.jar:?]
2018-07-13T09:31:54,249 [e-Rechnungsimport] ERROR RechnungImporter ~ Catching

When writing and reading files, the resources are not `closed. When read-in, it ensures that the file can no longer be accessed after processing:

org.mustangproject.ZUGFeRD.ZUGFeRDExporter.PDFmakeA3compliant(String, String, String, boolean)
org.mustangproject.ZUGFeRD.ZUGFeRDImporter.extract(String)
org.mustangproject.ZUGFeRD.ZUGFeRDExporterFromA1Factory.loadFromPDFA1(String)
org.mustangproject.ZUGFeRD.ZUGFeRDExporterFromA1Factory.loadFromPDFA1(byte[])

Something to talk about on Java 1.7 / 8. Then you could use try with ressources?

for custom xml and embedding on a pdf/a3 with already embedded zugferd and potentially unit tests for toecount

We currently only support creator and producer and mustangproject puts creator in creatorTool which is probably wrong.

xmp:CreatorTool is set in xsb.setCreatorTool(creator) and means "The name of the first known tool used to create the
resource".
http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf
p. 27.

Creator respectively Producer refer according to
http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf
p. 844
to
Creator: (Optional) If the document was converted to PDF from another
format, the
name of the application (for example, Adobe FrameMaker®
) that created the
original document from which it was converted.

respectively
Producer: (Optional) If the document was converted to PDF from another
format, the
name of the application (for example, Acrobat Distiller) that converted
it to
PDF.

Hi,

when I want to convert PDF/A-1 to PDF/A-3 with mustang I get the following exception:

java.io.IOException: File must be attached (usually with PDFattachZugferdFile) before perfoming this operation
at org.mustangproject.ZUGFeRD.ZUGFeRDExporter.export(ZUGFeRDExporter.java:337)
at org.mustangproject.toecount.Toecount.main(Toecount.java:391)
Written to invoice.a3.pdf

The resultfile isn't written. The input I use is PDF/A-1 compatible as checked with VeraPdf.

Thank you for looking into it.

Hi, I tried to get the project working, but I have several issues:

1. There are only 10 Classes in the model, but about 47 referenced in ZUGFeRDTransactionModelConverter.java
2. Dependency com.sanityinc.jargs could not be resolved.

Any Ideas?

For ZF2 we need a new official sample file, this time in english
How you can help:
Download the blanko 506 .odt file as documented, open in libreoffice, translate to english, adjust the dates and export to PDF.
copy the source code for the file generated in the tests (the factur-x file with 506 in it's name) to a new test, update the invoice date to today, translate the positions and by all means put more then half a litre of air into those balloons. Pull request, run the tests and attach the generated sample file to this ticket :-)

Please make mustang available in Maven Central, so other maven/gradle projects can easily depend on it.

Andreas Starke had already published a way how ZUGFeRD "extensions"/additional data can accomodate special needs of industry branches (http://4s4u.de/additional_data/), e.g. if you need to specify the mileage in a logistics your invoice can say "one washing machne, one dry cleaner" and the additional data can say that the delivery truck transported the washing machine 500km but the dry cleaner only 25 because it was picked up elsewhere. There is a python library and a command line tool to embed/extract this files, the idea is that the mustangproject library and command line tool can do that too and ZUV can validate this additional data.

How you can help:
The library can already add/extract but we need tests for that and we options for the command line tool to be able to do that as well, probably both interactively prompting for the filename and scripted.

ZUV e.g. starts with a "--action validate" parameter, we should also start mustangproject with something like "--action=embed-xml", "--action=embed-additional-data", "--action=extract-xml", "--action=extract-additional-data",

e.g. <ns3:CrossIndustryDocument instead of <ram:CrossIndustryDocument

after a -a run (and potentially also after a ZUGFeRD export?) VeraPDF complains about the following three incidents of two errors:

Status
--
Specification: ISO 19005-3:2012, Clause: 6.1.8, Test number: 1 |  
Font names, names of colourants in Separation and DeviceN colour spaces, and structure type names, after expansion of character sequences escaped with a NUMBER SIGN (23h), if any, shall be valid UTF-8 character sequences. | Failed
2 occurrences 
  |  
Specification: ISO 19005-3:2012, Clause: 6.6.2.3, Test number: 3 |  
The Schema type is an XMP structure containing the definition of an extension schema. The field namespace URI is "http://www.aiim.org/pdfa/ns/schema#". The required field namespace prefix is pdfaSchema. The Schema type includes the following fields: pdfaSchema:schema (Text), pdfaSchema:namespaceURI (URI), pdfaSchema:prefix (Text), pdfaSchema:property (Seq Property), pdfaSchema:valueType (Seq ValueType). | Failed
1 occurrences