Was braucht es denn zur Erstellung von ZUGFERD Rechnungen?

Question

Hallo zusammen,

ich habe mal mutig auf den f-leistungsdatum Branch gewechselt.
Dort ist ja die Erstellung von ZUGFERD Rechnungen aktiviert.
Nachdem ich das bei den Bankkonten aktiviert habe und eine Rechnung drucken möchte, bekome ich eine LaTex Fehlermeldung:

Ich denke, der spannende Part ist dieser:

** pdfx: No file kivitendo-print-20200702175753-lsBeEe.xmpdata . Metadata will
be incomplete!

>..............

>! pdfTeX error (ext5): cannot open file for embedding.
\reserved@a ...DeviceRGB} file{\pdfx@rgb@profile }
\edef \OBJ@RGB {\the \pdfl...
l.1293 }
%
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on kivitendo-print-20200702175753-lsBeEe.log.

Wenn ich in der Mandantenkonfiguration die ZUGFERD-Erstellung abschalte, wird die Rechnung sauber gedruckt (mit 16% Mwst !!!).

Meine Kivitendoinstallation läuft auf Debian 9.12

Fehlen da irgendwelche Pakete oder Verzeichnisberechtigungen?

Grüße
Andreas

Answer 1

Hallo Andreas,

TeX-Live 2019

Vorher funktioniert die Einbettung der XML-Daten in ein PDF/A nicht.
In Deinem Fall benötigst Du dann Debian in der Version 11 (testing)

Wenn ich in der Mandantenkonfiguration die ZUGFERD-Erstellung
abschalte, wird die Rechnung sauber gedruckt (mit 16% Mwst !!!).

Das war ja auch (kaum) anders zu erwarten ;-)

Comments

Also es reicht debian10 Buster :)
das mit den texlive versionen ist etwas irritierend
bei debian heißen die sowas wie texlive-full 2018.20190227.
Auf jedenfall funktionierts bei mir. Musste nur ein paar Kleinigkeiten an den latexvorlagen anpassen.
Grüße

Werner kivitendodienstleister

---

Hi Werner,
texlive-2018 hatte ich nicht ausprobiert, von daher reicht das wahrscheinlich schon.

Ich hab nur texlive-2017 getestet und die nächste ubuntu Version hatte dann texlive-2019

Answer 2

Hallo Andreas,

welchen Kontorahmen verwendest Du? Ich habe SKR03. Ich versuche ebenfalls den Branch f-leistungsdatum zum Laufen zu bekommen. Beim DB Update konjunkturpaket_2020_SKR03.sql laufe ich auf einen SQL Fehler:
....
The error message was: ERROR: null value in column "tax_id" violates not-null constraint
DETAIL: Failing row contains (35519, 35511, null, 3, 81, 01.07.2020).
CONTEXT: SQL statement "INSERT INTO taxkeys (chart_id, tax_id, taxkey_id, pos_ustva, startdate)
VALUES ( (select id from chart where accno = '8735'), (select id from tax where rate = 0.16 and taxkey = 3 and chart_id = (select id from chart where accno = '1775')), 3, 81, '2020-07-01')"
PL/pgSQL function inline_code_block line 86 at SQL statement

Viele Grüße
Klaus

Comments

Hallo Klaus,

bei mir lief das alles sauber durch.
Ich benutze SKR03 mit IST-Versteuerung und Aufwandsmethode, falls das relevant zur Fehlersuche ist.

Die Frage, die bei dir sicherlich interessant ist, von welcher Version machst du das Upgrade? Bei mir war es 3.5.5.

Wenn du von älteren Versionen auf den Entwicklungsbranch wechselst, kann ich dir nur Empfehlen dir (bezahlte!) Unterstützung von Werner, Geoffrey oder Jan zu holen. Sonst wird das vermutlich schwierig.

Ich habe auch etwas Geld in den Entwicklungstopf für die Mehrwertsteuerumstellung geworfen, deshalb hatte ich auch keine Angst beim Upgrade, ich hätte gewusst, wen ich anrufen kann. ;-)

Sorry, das ich dir keine konkrete Hilfe geben konnte.

Grüße
Andreas

---

Hallo Andreas,

vielen Dank für Deinen Hinweis. Gut zu wissen, dass Du eine ähnliche Umgebung hast und es bei Dir funktioniert. Die Datenbank kommt von einem 3.5.3 System. Den Upgrade auf 3.5.5 hatte ich auf der Testinstanz schon einmal getestet. Aber für diesen Test wieder mit der 3.5.3er Version der Daten begonnen. Ich werde es mal in zwei Schritten versuchen und berichten.

Danke auch für Deinen zweiten Hinweis. Kivitendo ist die Buchhaltung meiner Frau. Sie betreibt alleine als Startup einen kleinen Laden für Wein und ich bin ihre IT. Ich will nicht auf die Tränendrüse drücken, aber die 4 Wochen Zwangsschliessung haben sie hart getroffen. Die Ladenmiete und andere Ausgaben liefen weiter. Die COVID-19 Soforthilfe gab es für sie nicht. Jetzt noch die Mehrwertsteueranpassung mit minimalem Vorlauf macht es noch schwieriger. Wir werden schauen was geht und etwas in den Topf werfen.

Viele Grüße
Klaus

---

Hallo Andreas,

ich habe jetzt den Upgrade in zwei Stufen gemacht: 3.5.3 -> 3.5.5 und dann 3.5.5 nach 3.5.6-unstable f-leistungsdatum Branch. Leider bekomme ich beim Upgrade der Datenbank in konjunkturpaket_2020_SKR03.sql wieder den gleichen Fehler:

The error message was: ERROR: null value in column "tax_id" violates not-null constraint
DETAIL: Failing row contains (35519, 35511, null, 3, 81, 01.07.2020).
CONTEXT: SQL statement "INSERT INTO taxkeys (chart_id, tax_id, taxkey_id, pos_ustva, startdate)
VALUES ( (select id from chart where accno = '8735'), (select id from tax where rate = 0.16 and taxkey = 3 and chart_id = (select id from chart where accno = '1775')), 3, 81, '2020-07-01')"
PL/pgSQL function inline_code_block line 86 at SQL statement
All changes in that file have been reverted.

Hast Du nur den f-leistungsdatum Branch genommen oder vorher etwas anderes eingespielt?

Viele Grüße
Klaus

---

Ich versuche die Fehlermeldung zu verstehen. Ich bin sicherlich nicht sattelfest in SQL.
Ich lese hier:
(select id from tax where rate = 0.16 and taxkey = 3 and chart_id = (select id from chart where accno = '1775'))
ergibt den null Wert.

Zum Vergleich die Steuertabelle:
3 Umsatzsteuer 19,00 % 1776 Umsatzsteuer 19 % 8735 Gewährte Skonti 16%/19% USt.
5 Umsatzsteuer 16,00 % 1775 Umsatzsteuer 16%

Bei mir gibt es keine Steuer mit Id=3 und rate=0.16. Id=3 hat rate=0.19. Das Ergebniss null ist richtig.

Jetzt bin ich mit meinem Latein am Ende. Vielleicht gibt es mehrere Versionen der Steuertabelle und meine ist veraltet.

Viele Grüße
Klaus

---

Mit der Hilfe von Jan ist das Problem gelöst. Die "alten" 16% Steuern in der Steuertabelle hatten bei mir andere Ids. Statt 3 und 9 hatten Sie bei mir die 5 und 7. Nach der Änderung hat der DB Update geklappt und die reduzierten Steuersätze sind aktiv. :)
Vielen Dank an Jan!