FAQ

Which Arguments/Parameters are Needed for Which Use Case

The same rules apply both for the Commandline Tool and the Dienst (Service):

You have two options to pass the invoice data to the software. If you already have the invoice data as structured data in the internal format, you can pass the data with the parameter invoice or the commandline option --invoice as JSON. The other option is to generate the invoice data from a spreadsheet. In that case you have to pass the spreadsheet data with the parameter spreadsheet (commandline option --spreadsheet) and a YAML or JSON mapping with the option mapping (commandline option --mapping).

Then, you must decide whether you want to create a pure XML invoice format or the hybrid Factur-X/ZUGFeRD format. For Factur-X/ZUGFeRD you always need a PDF because it is a PDF with the machine-readable invoice data embedded; for pure XML formats you only need a PDF if you want to embed an optional PDF version of the invoice into the XML document.

If you have to provide a pdf, you have to options to do so: If you already have a PDF version of the invoice, you can just pass it to the application with the parameter pdf respectively the commandline option --pdf. The other option is to generate the PDF from a spreadsheet file with LibreOffice. In that case, you have to pass the spreadsheet file as a parameter spreadsheet or the commandline option --spreadsheet.

For Factur-X/ZUGFeRD, you cannot specify a PDF id or PDF description because it is implied. For pure XML formats you can specify them with the parameter pdf-id or the commandline option --pdf-id and the parameter pdf-description or the commandline option --pdf-description.

Finally, it is possible to attach more files for every supported format. For each of these attachments you must add the file with the parameter attachment or the commandline option --attachment. You should also pass the attachmend id and description with attachment-id/--attachment-id and attachment-description/--attachment-description.

In case, the software does not guess the correct MIME type of the attachment, you should also specify it with the parameter attachment-mimetype or the command line option --attachment-mimetype.

Why are no Numbers Used in the JSON Schema?

Geldbeträge müssen Zahlen >= 0 mit höchstens zwei Dezimalstellen sein. Dafür sollte das folgende JSON-Schema funktionieren:

{
    "type": "number",
    "multipleOf": 0.01
}

Das ist in der Dokumentation für JSON Schema so beschrieben. Leider funktioniert das mit der JavaScript-Implementierung nicht, siehe https://github.com/ajv-validator/ajv/issues/652.

Diese Beschränkungen von Avj lassen sich mit Tricks umgehen. Wir wollen allerdings vermeiden, dass Nutzerinnen und Nutzer mit Ajv naiv gegen das Schema validieren, ohne diese Tricks anzuwenden. Deshalb scheint es einfacher zu sein, zu fordern, dass alle Zahlen von der generierenden Software als Strings formatiert werden müssen.

Bei Prozentsätzen tritt das gleiche Problem auf, nur dass diese bis zu vier Dezimalstellen haben können.

Für andere numerische Typen, wie Mengen, könnten Zahlen verwendet werden. Aus Konsistenzgründen benutzen wir jedoch Strings im ganzen Schema.

What Does the Warning 'ODS number format may be incorrect' Mean?

Siehe dazu das SheetJS-GitHub-Ticket #1569. Diese Warnung kann wahrscheinlich ignoriert werden, solange keine Probleme mit Zahlenformaten auftauchen.

Where Can I Get Information About Business Terms?

Fehlermeldungen von Validatoren erwähnen oft Business-Terms in Fehlermeldungen. Zu welchen Elementen diese jeweils gehören, lässt sich unserer Liste von Business-Terms entnehmen.

How Can I Suppress Auxiliary Sheets in the PDF Output?

Dazu muss sichergestellt werden, dass nur das Tab mit den druckbaren Rechnungsdaten einen Druckbereich definiert hat. Das lässt sich mit dem Menüpunkt Format -> Druckbereiche -> Bearbeiten prüfen. Für alle anderen Tabs müssen alle drei Optionen auf Nichts gesetzt werden.

Can I encode "Skonto" in an Electronic Invoice?

Skonto is a cash discount that is commonly given in German speaking countries. If the invoice is paid with a certain number of days, an automatic allowance is granted.

The standard EN16931 does nt provide anything to encode this. But the German XRechnung standard defines a way to transmit this information. This is best explained by an example:

#SKONTO#TAGE=10#PROZENT=3.00#
#SKONTO#TAGE=10#PROZENT=3.00#BASISBETRAG=1303.69#

The first token SKONTO is mandatory. It is followed by the number of days (TAGE) and the allowance percentage (PROZENT) with exactly two decimal digits.

If the discount is applied to only a part of the grand total, that part has to be specified as a base amount (BASISBETRAG), again with two decimal digits.

It seems to be sufficient that the field /cac:PaymentTerms/cbc:Note contains a line that matches this pattern so that you can mix this with human-readable information. Please file an issue, if this is wrong information.

Other sources mention that you can specify a penalty for late payment in the same manner as for "Skonto" but replace the #SKONTO# with #VERZUG# (the German word for late payment). However, the official Schematron rules for the German XRechnung do not suggest such a convention.