Wie sieht die Zukunft mit XRechnung, ZUGFerD, Peppol und Co. aus ?

[t2000]

Zitat von Frickler:

Zitat von t2000:

Was gäbe es noch für Alternativen? Nach Möglichkeit unabhängig von Windows, da wir eine Menge auf einem Linux-Server machen.

In früheren Artikeln wurde DynaPDF empfohlen. Das ist eine DLL bzw. Shared Library, die man auch aus Delphi ansteuern kann. Unterstützt wird außer Windows auch MacOS, iOS, Android und Linux.

Stimmt, Danke, hatte ich vergessen.
Ne Firma aus der Gegend bei Osnabrück, Quellcode kann auch gekauft werden.
Ohne Quellcode kommt bei uns sonst nichts ins Projekt.

[bernau]

Ich verwenden die PdfiumLib von Andreas Hausladen um PDF anzuzeigen.

https://github.com/ahausladen/PdfiumLib

In der Lib gibt es auch Funktionen um Attachements anzuhängen. Weis nicht, ob das dafür geeignet ist und habe es auch noch nicht getestet. Einfach mal schauen.

[sh17]

Wenn es um die E-Rechnungspflicht geht, dann ist die Einbettung einer XML in die PDF sowieso nicht erforderlich, weil diese Bestimmung vorsieht, dass
das nackte XML die vollständige Rechnung darstellt und eine parallele optische Darstellung nicht vorgesehen ist.

[t2000]

Ja sicher, aber ich kenne meine Kunden
Habe jetzt schon den Hinweis von einem Kunden bekommen, dass die zukünftig nur eine Rechnung versenden wollen, die man auch lesen kann. Finde ich persönlich (als Nutzer) auch sinnvoll.

[himitsu]

Nja, "direkt" lesbar wäre es auch, wenn die XML neben der PDF liegen täte, damit der Kunde dort mit Notepad/Browser reingucken kann.

[sh17]

Wenn das gesetzlich alles abgestimmt ist, sicher. Es sind halt zwei unabhängige Dokumente (wie ehemals Papier und gescannte PDF), wie kann man sicherstellen, dass beide übereinstimmen? Deswegen wird nur ein Dokument rechtsgültig sein.

[BlueStarHH]

Zitat von sh17:

Wenn das gesetzlich alles abgestimmt ist, sicher. Es sind halt zwei unabhängige Dokumente (wie ehemals Papier und gescannte PDF), wie kann man sicherstellen, dass beide übereinstimmen? Deswegen wird nur ein Dokument rechtsgültig sein.

Wenn X-Rechnung (XML) und PDF ausgliefert werden, muss der Empfänger beides auf Unterschiede prüfen. Trotzdem sagen schon jetzt einige Kunden, dass Sie beides haben wollen.

[sh17]

Zitat von omnibrain:

Mit der kommenden E-Rechnungspflicht fragen Kunden jetzt auch wieder nach ZUGFeRD.

XRechnungen sind kein Problem, die erstelle ich mit der XRechnungskomponente von Landrix/sh17.

PDF erstellen wir eh schon immer.
Jetzt fehlt mir nur eine Lösung um aus dem was ich schon habe eine ZUGFeRD-Rechnung zu erstellen. Das heißt das PDF ggf. in das passende PDF/A-Format umwandeln und dann die Rechnungs-XML anhängen. Hat da vielleicht jemand schon eine Lösung? Ich brauche nicht unbedingt eine Komponente, eine aus Delphi nutzbare DLL tuts mir auch und zur Not geht auch ein Kommandozeilenprogramm.

Mittels PDFBox und https://github.com/konik-io/pdfbox-carriage als Vorlage könnte man sich was in JAVA basteln.

Oder auch das hier https://www.mustangproject.org/commandline/

Ich werde das dann zu gegebener Zeit hier https://github.com/LandrixSoftware/ZUGFeRD-for-Delphi mit dazu packen. Im Moment muss
ich noch den Write-Support fertigstellen.

[BlueStarHH]

Zitat von sh17:

Mittels PDFBox und https://github.com/konik-io/pdfbox-carriage als Vorlage könnte man sich was in JAVA basteln.

Wer möchte denn Java mit seinem Delpi-Programm, das sonst wenige oder keine Abhängikeiten hat, ausliefern? Oder welcher Kunde möchte Java haben? Ich beobachte ehr, dass viele Kunden das inzwischen als sicherheitskritisch sehen und keine Java-Runtime mehr installiert haben oder installieren möchten.

[sh17]

XRechnung kommt ebenfalls mit einer Reihe von Java-basierenden Tools, um die Validierung oder Visualisierung von XRechnung zu ermöglichen. Ich sehe keine Problem darin, dies ebenfalls bei ZUGFeRD so zu handhaben, wenn es mir einen Mehrwert liefert. Alle Tools sind OpenSource und können geprüft werden. Von daher, nehmen oder lassen oder selbst machen. Deswegen ist es ja OpenSource, um Abhängigkeiten zu vermeiden. Aber das kann jeder für sich selbst entscheiden.