E-Rechnung und Lazarus/fpc

[KoBraSoft]

Hallo,
ich möchte mich zum Stand der E-Rechnung in Lazarus/Pascal erkundigen.
Zur Zeit bekommen viele meiner Kunden Schreiben von Ihren Steuerberatern. Ein Kunde hat mir sein Schreiben gezeigt. Darin hieß es, oben fett geschrieben, sinngemäß, dass ab 1.1.25 die E-Rechnung Pflicht ist. Dann kam kleingedruckter Text, darunter wieder Groß und Fett Ihr Steuerberater hätte die Lösung (irgend ein Dienstleistungsvertrag). Dann eine ganze Seite, wie toll diese Lösung sei.
Dem Kunden wurde auch noch mündlich mit geteilt, dass er wenn er das nicht macht, er keine Vorsteuer abziehen mehr kann. Dieser Kunde hat gewerbliche Kunden.

Für mich stellen sich nun einige Fragen (nach denen ich bereit intensiv gegoogelt habe, aber teils keine überzeugenden Antworten gefunden habe):

1. Was ist eine E-Rechnung?

Unbestritten ist, dass eine eingescannte Papierrechnung (Bitmap) keine E-Rechnung ist, auch nicht wenn sie in ein pdf eingebettet ist.
Unbestritten ist auch, dass ein valide ZugFeRD Rechnung eine E-Rechnung ist.
Zur Frage, ob andere Formate (UN-EDIfact, xml, (text)pdf, xls, odf, csv, txt, ...) gültig und vorsteuerabzugsfähig sind habe ich keine vernünftigen bzw widersprüchliche Informationen gefunden. Weis jemand mehr?

2. Was hat ein Unternehmen bis wann zu tun?

Unbestritten ist das Unternehmen im B2B Bereich ab 1.1.25 E-Rechnungen empfangen können müssen. Das steht im Wachstumschancengesetz (Ein dämlicher Name.)
Unbestritten ist das Unternehmen im B2B Bereich erst später E-Rechnungen versenden können müssen. (Es gibt wohl Ausnahmen z.B. bei öffentlichen Auftraggebern.)
Was aber Unternehmen im B2B Bereich praktisch tun müssen, damit sie E-Rechnungen empfangen können, habe ich noch nicht herausgefunden. Genügt es wenn sie Emails empfangen können (oder gar per Post versandte Datenträger wie Disketten annehmen)? Müssen die Unternehmen alle Formate annehmen und verarbeiten können? Einige? Welche?

3. Welches E-Rechnungsformat setzt sich am Ende durch?

UN-Edifact, Zugferd, XRechnung oder ein anderes? Erinnert mich an VHS, Betamax und Video2000, damals hatte sich das schlechteste System durchgesetzt

4. Wird an der Erstellung von E-Rechnungen / Zugferd Rechnungen mit Lazarus schon gearbeitet?

Ich weis, dass Joh dran ist, aber ob er mit Lazarus alleine (pures Pascal) arbeitet oder mit externen Tools weis ich nicht.

Ich bin sicher, dass mich das Thema E-Rechnung noch beschäftigen wird. Zumal ich selber Rechnungen an gewerbliche Kunden empfangen und schreiben muss.

[Warf]

Ich hab kurz mal in die E-Rechnungsverordnung reingeschaut, die ist eigentlich relativ klar: https://www.gesetze-im-internet.de/erec ... 00017.html

§ 4 Anforderungen an das Rechnungsdatenmodell und an die Übermittlung
(1) Für die Ausstellung von elektronischen Rechnungen haben Rechnungssteller und Rechnungssender grundsätzlich den Datenaustauschstandard XRechnung vom 29. September 2017 (BAnz AT 10.10.2017 B1) in der jeweils aktuellen Fassung zu verwenden. Es kann auch ein anderer Datenaustauschstandard verwendet werden, wenn er den Anforderungen der europäischen Norm für die elektronische Rechnungsstellung entspricht.

Die Referenzierte Europäische Norm ist die EN 16931, die man bei der DIN Ausnahmsweise sogar mal gratis bekommt: https://www.dinmedia.de/de/norm/din-en- ... /327729047

Sowie was an Daten rein muss steht in Paragraph 5:

§ 5 Inhalt der elektronischen Rechnung
(1) Die elektronische Rechnung hat neben den umsatzsteuerrechtlichen Rechnungsbestandteilen mindestens folgende Angaben zu enthalten:
1. eine Leitweg-Identifikationsnummer,
2. die Bankverbindungsdaten,
3. die Zahlungsbedingungen und
4. die De-Mail-Adresse oder eine E-Mail-Adresse des Rechnungsstellers.
(2) Die elektronische Rechnung hat zusätzlich zu den Angaben nach Absatz 1 folgende Angaben zu enthalten, wenn diese dem Rechnungssteller bereits bei Beauftragung übermittelt wurden:
1. die Lieferantennummer,
2. eine Bestellnummer.
(3) Die Vorgaben nach den Absätzen 1 und 2 gelten nicht für Rechnungen, die in Verfahren der Organleihe nach § 159 Absatz 1 Nummer 5 des Gesetzes gegen Wettbewerbsbeschränkungen auszustellen sind.
Nichtamtliches Inhaltsverzeichnis

Zur Frage was sich durchsetzt, ich würde mal auf XRechnung tippen, da das so oder so genutzt werden muss für Öffentliche stellen. Außerdem so wie ich das verstanden habe ist die E-Rechnungskompatible Version von ZUGFeRD ein XRechung Profil, und damit auch interoperabel mit XRechnung.

[gladio]

Die E-Rechnung und Rechnungen per PDF oder sonstwie sind sind unterschiedliche Sachen.
E-Rechnung = Rechnung als Datensatz zum elektronischen Versand von Maschine zu Maschine.

Der Austausch von Rechnungen auf Papier, PDF, ... ist weiterhing zulässig, ebenso der Handschlag.

[Warf]

Nein, nach Wachstumschancengesetz was am 1. Januar 2025 in kraft tritt gilt: https://www.recht.bund.de/bgbl/1/2024/108/VO.html

(2) Führt der Unternehmer eine Lieferung oder eine sonstige Leistung nach § 1 Absatz 1 Nummer 1 aus,
ist er berechtigt, eine Rechnung auszustellen. In den folgenden Fällen ist er zur Ausstellung einer Rechnung
innerhalb von sechs Monaten nach Ausführung der Leistung verpflichtet, wenn der Umsatz nicht nach § 4
Nummer 8 bis 29 steuerfrei ist:
1. für eine Leistung an einen anderen Unternehmer für dessen Unternehmen; die Rechnung ist als
elektronische Rechnung nach Absatz 1 Satz 3 und 6 auszustellen, wenn der leistende Unternehmer und
der Leistungsempfänger im Inland oder in einem der in § 1 Absatz 3 bezeichneten Gebiete ansässig sind

Es gibt also die ganz klare Pflicht im B2B Fall eine E-Rechnung zu stellen

[gladio]

Ich habe mal zwei mir zugängliche Anwendungen bemüht, die e-Rechnungen erzeugen und verarbeiten.
easybill und Datev bieten ZUGFeRD und XRechnung an.
Datev ist ja sozusagen "Marktführer" (ich mag es nicht besonders), also würde ich mich auf diese beiden konzentrieren.

Hier ist eine Kurzbeschreibung aus Datev:
https://apps.datev.de/help-center/documents/9262724
und hier noch was vom BMI
https://www.e-rechnung-bund.de/e-rechnu ... erechnung/

Eine Information, dass ab 1.1.2025 zwischen Unternehmen ausschliesslich e-Rechnungen zu verwenden sind und der Rest verboten ist, kann ich momentan nicht finden
aber das wird wohl irgendwann so kommen.

[KoBraSoft]

Zugferd hat für mich ein Riesen Problem:
Mann kann in den visuellen Bereich der pdf andere Beträge eintragen als in die eingebettete xml (X-Rechnung).
Wenn sich also eine Kunde eine derart fingierte Rechnung ansieht, sieht er zB als Rechnungsbetrag 10 Euro. In der eingebetteten X-Rechnung könnten als Rechnungssumme 10000 Euro stehen. Wenn der Kunde die scheinbar geprüfte Rechnung seinem Zahlungsdienstleister übergibt wird dieser 10000 Euro überweisen.

[Warf]

Eine Information, dass ab 1.1.2025 zwischen Unternehmen ausschliesslich e-Rechnungen zu verwenden sind und der Rest verboten ist, kann ich momentan nicht finden
aber das wird wohl irgendwann so kommen.

Seid ihr denn keine guten Bürger und lest das Bundesgesetzblatt mit allen neuen Gesetzen sobald dieses Veröffentlicht wird

Aber das BMF hat dazu ne Stallungname veröffentlicht: https://www.bundesfinanzministerium.de/ ... esetz.html

Einführung der verpflichtenden Verwendung von elektronischen Rechnungen für Umsätze zwischen inländischen Unternehmen ab dem 1. Januar 202

[MmVisual]

Als erstes mal ist dieses Gesetz nicht unterschrieben, und somit nicht gültig, und so lange es nicht mit vollem Vor- und Zuname unterschrieben ist, bleibt es ungültig. Und dann hat der Bundesadler 7 Schwingen je Seite und nicht 6.
Im Internet kursieren alle möglichen Bundesadler Varianten vom Bundesadler, eigentlich gibt es nur ein einziges korrektes Symbol, doch offensichtlich wissen die Behörden selbst nicht einmal was das einzig richtige Wappen für offizielle Dokumente ist.
... ich wollte jetzt nicht zu politisch werden, das Thema Rechnung ist ohnehin grenzwertig für dieses Forum.

[Warf]

Das ist das Bundesgesetzblatt auf der Webseite des BMJ, nach Artikel 82 Grundgesetz die Finale instanz die zum Inkraftreten eines Gesetzes notwendig ist. Formaler wird es nicht. Was darin veröffentlicht wird ist (mit entsprechender Vorlaufzeit) geltendes Recht.

Also außer du willst auch noch unsere Verfassung in Frage stellen, würde ich dem Offiziellen Legislativorgan der Bundesregierung an dieser Stelle vertrauen

[KoBraSoft]

das Thema Rechnung ist ohnehin grenzwertig für dieses Forum.

Ich habe diese Thema bewusst in "Sonstiges" gestellt. Für mich (und viele andere) hat es aber direkt mit Lazarus zu tun. Ich muss heraus finden, was ich konkret in die Programme, die ich für meine Kunden geschrieben habe, einbauen muss oder eben nicht.
Und es ist nicht mehr viel Zeit.

OT
Ich bin sicher, dass ab 1.1.25 bei weitem nicht alle "Rechnungen für Umsätze zwischen inländischen Unternehmen" E-Rechnungen sein werden. Wie sich das Finanzamt dann verhält (Vorsteuerabzug) kann ich nicht einschätzen.

[kirchfritz]

Ich muss heraus finden, was ich konkret in die Programme, die ich für meine Kunden geschrieben habe, einbauen muss oder eben nicht.

Also für E-Rechnungen musst Du entweder eine XRechnung (Rechnungsdaten im XML-Format validiert durch das XRechnungs-Schema) oder ebenhalt eine ZUGFeRD-Rechnung (Rechnungsdaten im XML-Format, validiert durch das ZUGFerD-Schema und eingebettet in eine PDF-Datei) erstellen. Und wo siehst Du jetzt ein Problem? Mit Lazarus ein XML erstellen, sollte bei bekanntem XSD-Schema keine Hürde für Lazarus-Programmierer sein. Gleiches gilt für das ZUGFeRD-XML. Schwieriger wirds dann ebenhalt bei der Erstellung des PDFs. Hier wären aus meiner Sicht Code-Schnipsel notwendig um zu zeigen, wie ein ZUGFeRD XML in eine PDF-Datei eingebettet werden kann.

[kralle]

Gerade gesehen: https://www.heise.de/news/iX-Workshop-I ... g.beitrag

Gruß Heiko

[Joh]

Sooo...
bei mir ist jetzt der nächste Knoten geplatzt.

Ich kann ein valides PDF/A-1b -Dokument per Lazreport erstellen.
Doof nur, das das Beispiel im Laz-Wiki falsch ist; noch doofer, das ich das nicht korrigieren kann:

getWikiText called for a good result, this is incorrect

Wenn das Wiki das meint; ich bin raus.

PS: wen's interessiert: Options müssen vor StartDocument deklariert werden.

Letztlich ist (wie meistens) die Lösung ganz einfach:
- in der TlrPdfExportFilter.OnBeginDoc muß bei den Options poMetadataEntry eingetragen werden,
- in der TlrPdfExportFilter.OnEndDoc muß vor dem Schreiben des Streams FPDFDocument.AddPDFA1sRGBOutputIntent aufgerufen werden.

Aber ich werde den Teufel tun, das irgendwem als Ticket versuchen zu erklären, wenn ich nichtmal in der Lage bin, im Wiki eine Kleinigkeit zu ändern.


edit: Ticket ergänzt

[Socke]

Ich kann ein valides PDF/A-1b -Dokument per Lazreport erstellen.
Doof nur, das das Beispiel im Laz-Wiki falsch ist; noch doofer, das ich das nicht korrigieren kann:

getWikiText called for a good result, this is incorrect

Wenn das Wiki das meint; ich bin raus.

Wo muss denn was geändert werden. Vielleicht funktioniert es ja bei jemand anderem?

[Joh]

Auf der Seite https://wiki.freepascal.org/fcl-pdf ist das erste Beispiel falsch; hier der ist-Zustand:

Code: Alles auswählen

Document := TPDFDocument.Create(nil);
Document.FontDirectory := 'C:\Windows\Fonts';
Document.StartDocument;
FontID := Document.AddFont('arial.ttf', 'Arial');
FontBoldID := Document.AddFont('arialbd.ttf', 'Arial Bold');
 
Document.Options := Document.Options + [poPageOriginAtTop, poNoEmbeddedFonts];  // wird nicht mehr ausgeführt
Section := Document.Sections.AddSection;

Eine Änderung der Optionen führt hier leider zu keinerlei Änderung der PDF-Datei, weil u.a. die für PDF/A wichtige Optionen poMetadataEntry in Document.StartDocument ausgewertet wird.

hier der korrigierte Aufruf der Optionen vor Document.StartDocument:

Code: Alles auswählen

Document := TPDFDocument.Create(nil);
Document.FontDirectory := 'C:\Windows\Fonts';
Document.Options := Document.Options + [poPageOriginAtTop, poNoEmbeddedFonts];  // muß vor Document.StartDocument stehen
Document.StartDocument;
FontID := Document.AddFont('arial.ttf', 'Arial');
FontBoldID := Document.AddFont('arialbd.ttf', 'Arial Bold');
 
Section := Document.Sections.AddSection;

Und als Änderungskommentar wollte ich schreiben: Options must be placed before StartDocument

Mein persönlicher Kommentar: OK, wahrscheinlich liegt der Fehler bei nachträglichen Änderungen in der fpPDF bzgl. der Optionsauswertung in StartDocument, aber das ist Spekulation und es ist einfacher, das Beispiel im wiki anzupassen als Designfehler im fpPDF-Code.

PS: persönlich würde ich das Font-Directory direkt vor die Font-Initialisierung schreiben, aber das würde weitere Tests hinter sich herziehen und ist nicht relevant.