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

[kdf]

Hallo,
ich habe hier eine Anwendung, mit der auch Rechnungen geschrieben werden, die mit Delphi 6 geschrieben wurde. Aufgrund der Verwendung zahlreicher Fremdkomponenten ist eine Portierung so gut wie unmöglich. Es handelt sich nicht um eine Buchhaltungssoftware. Es handelt sich also nur um ausgehende Rechnungen.

Jetzt stellt sich ab 2025 ja das Problem mit der E-Rechnung. Wie ich das umsetzen kann, sehe ich momentan noch nicht. Die Integration in den Delphi6 Client scheint ja nicht möglich zu sein. Die Rechnungen werden mit Fastreport geschrieben, befinden sich in einer Firebird 2.5 DB, könnten dort direkt eingesammelt werde. Denkbar wäre z.B. ein Export in CSV. Für die weitere Verarbeitung wäre ein Konverter denkbar, der dann eine Rechnung im erforderlichen Format erzeugt.

Meine Frage ist zunächst, ob es derartige Tools überhaupt gibt?

Gruß
K.-D.

[Papaschlumpf73]

Lies dir mal die Beiträge hier im Forum durch. Von Sven Harazim (sh17) gibt es Lösungen, die auch auf GitHub verfügbar sind.

[KlausV]

Hallo kdf,
ich nutze die Software von Aloaha http://www.zugferdpro.com/.
Da das Projekt unter C# entwickelt wurde, funktioniert nur das einbinden der DLL in Delphi.
Dabei funktioniert early / late binding.
Ich habe aktuell ein kleines Beispielprojekt unter D7 aufgesetzt, wo ich meine erzeugte PDF Datei die XML erzeugte Datei hinzufüge.
Das hat sehr gut funktioniert und lief auch bei einigen Validatoren ohne Fehler durch.

Die Software kostet zwar etwas, aber man kann sich einen Testkey geben lassen und zuerst mal etwas probieren. Mit dem GF habe ich telefonisch einiges schon geklärt, sehr nett und umgänglich. Die Software wird permanent weiterentwickelt.

[sh17]

Krass, plus Runtimelizenz pro Endnutzer

[KlausV]

Zitat von sh17:

Krass, plus Runtimelizenz pro Endnutzer

ja, leider, aber bei uns sind es eh nur 2 Arbeitsplätz die Rechnungen schreiben und wenn ich den Aufwand gegenrechne um von D7 nach D10 zu kommen rechnet es sich schon, zumal ich alles komplett neu für D10 lizenzieren müsste und manche Tool Komponenten gibt es schon gar nicht mehr.

[AuronTLG]

Zitat von kdf:

Hallo,
ich habe hier eine Anwendung, mit der auch Rechnungen geschrieben werden, die mit Delphi 6 geschrieben wurde. Aufgrund der Verwendung zahlreicher Fremdkomponenten ist eine Portierung so gut wie unmöglich. Es handelt sich nicht um eine Buchhaltungssoftware. Es handelt sich also nur um ausgehende Rechnungen.

Jetzt stellt sich ab 2025 ja das Problem mit der E-Rechnung. Wie ich das umsetzen kann, sehe ich momentan noch nicht. Die Integration in den Delphi6 Client scheint ja nicht möglich zu sein. Die Rechnungen werden mit Fastreport geschrieben, befinden sich in einer Firebird 2.5 DB, könnten dort direkt eingesammelt werde. Denkbar wäre z.B. ein Export in CSV. Für die weitere Verarbeitung wäre ein Konverter denkbar, der dann eine Rechnung im erforderlichen Format erzeugt.

Meine Frage ist zunächst, ob es derartige Tools überhaupt gibt?

Gruß
K.-D.

Ich habe eine individuelle Umsetzung zum Erstellen und Auslesen von XRechnungen hier auch in einem alten Programm am laufen, was noch über Delphi 7 kompiliert wird. XRechnungen schreiben und lesen ist doch einfach nur XML-Handling und sonst nichts.
Wenns ZUGfERD sein soll, muss man die XML dann halt noch in eine PDF einbetten oder rausholen, was bei mir hier im Delphi 7 noch über ein altes WPViewPDF läuft und ebenfalls problemlos funktioniert. Den verantwortlichen Quellcode kann ich sogar quasi 1:1 zwischen Delphi 7 und Delphi 12.1 hin und her kopieren, so wenig hat sich an den notwendigen Funktionalitäten geändert.
Vielleicht habe ich ja etwas missverstanden, aber was genau soll denn das unüberwindbare Problem bei Delphi 7 sein? Die XML-Komponenten gab es im Delphi 6 soweit ich das sehe auch schon.

[kdf]

Zitat von AuronTLG:

Ich habe eine individuelle Umsetzung zum Erstellen und Auslesen von XRechnungen hier auch in einem alten Programm am laufen, was noch über Delphi 7 kompiliert wird. XRechnungen schreiben und lesen ist doch einfach nur XML-Handling und sonst nichts.
Wenns ZUGfERD sein soll, muss man die XML dann halt noch in eine PDF einbetten oder rausholen, was bei mir hier im Delphi 7 noch über ein altes WPViewPDF läuft und ebenfalls problemlos funktioniert. Den verantwortlichen Quellcode kann ich sogar quasi 1:1 zwischen Delphi 7 und Delphi 12.1 hin und her kopieren, so wenig hat sich an den notwendigen Funktionalitäten geändert.
Vielleicht habe ich ja etwas missverstanden, aber was genau soll denn das unüberwindbare Problem bei Delphi 7 sein? Die XML-Komponenten gab es im Delphi 6 soweit ich das sehe auch schon.

Ich habe mich mit XML nie beschäftigt. Aber so hört sich das ja doch lösbar an.

[Redeemer]

Zitat von sh17:

Krass, plus Runtimelizenz pro Endnutzer

Ich glaub, du hast was falsch gemacht, als du das einfach auf Github geladen hast!

[sh17]

Zitat von Redeemer:

Zitat von sh17:

Krass, plus Runtimelizenz pro Endnutzer

Ich glaub, du hast was falsch gemacht, als du das einfach auf Github geladen hast!

Ach nö, alles gut. Ich mag Open Source. Vielleicht kann ich auf die Art auch was dazu beisteuern. Wenn es jemandem etwas nutzt, dann bin ich zufrieden.

[haentschman]

Moin...

Frage:
Kann man in der XRechnung mehrere Bankverbindungen erfassen?

Recherchen sagen überall NO. Habe ich was übersehen?

...auch in intf.Invoice nur ein Eintrag...keine 1..n

Delphi-Quellcode:

//TODO weitere Zahlungswege, als Liste
//TODO Auch 0 prüfen
PaymentMeansCode : TInvoicePaymentMeansCode;
PaymentID : String; //Verwendungszweck der Ueberweisung/Lastschrift
PaymentFinancialAccount : String; //sowohl Payee (Überweisung 58) als auch Payer (Lastschrift 59)
PaymentFinancialAccountName : String; //sowohl Payee (Überweisung 58) als auch Payer (Lastschrift 59)
PaymentFinancialInstitutionBranch : String; //BIC sowohl Payee (Überweisung 58) als auch Payer (Lastschrift 59)
PaymentMandateID : String; //Lastschrift (59) Mandatsreferenz BT-89