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

[KlausV]

Zitat:

Zitat von sh17 (Beitrag 1538796)

XRechnung betrifft ja in der Regel nur öffentliche Auftraggeber, die möchten da auch keine PDF drum herum haben.
Wenn du also alles abdecken möchtest, musst Du dich für das ZUGFeRD (CII)-Format mit dem Profil XRechnung entscheiden.

Sorry, dass ich mich falsch ausgedrückt habe.
Behörden bekommnen nur die XML, das ist klar, meistens muss dies eh über peppol versendet werden. Ich würde aber gerne nur eine Variante der XML Datei erzeugen wollen, die für beide "Welten" gültig ist. Sprich delphi erzeugt die xml und wenn Kunde B2B, wird zusätzlich noch das XML mit dem PDF verheiratet.
Bedeutet das, dass ich mit ZUGFerd 2.2.0 Profil XRechnung beide Welten erschlagen kann?

[sh17]

wer XRechnung haben möchte, bekommt nur die XML. Welche Lib man verwendet, hängt davon ab, wie viel man selbst machen
möchte. Die XRechnung-Lib nimmt einem etwas overhead ab und sie kann auch das UBL-Format schreiben.

[sh17]

Zitat:

Zitat von KlausV (Beitrag 1538803)

Bedeutet das, dass ich mit ZUGFerd 2.2.0 Profil XRechnung beide Welten erschlagen kann?

ja, das ist richtig.

[BlueStarHH]

Zitat:

Zitat von sh17 (Beitrag 1538812)

wer XRechnung haben möchte, bekommt nur die XML. Welche Lib man verwendet, hängt davon ab, wie viel man selbst machen
möchte. Die XRechnung-Lib nimmt einem etwas overhead ab und sie kann auch das UBL-Format schreiben.

Sorry für die dumme Frage: Ich verstehe den Unterschied zwischen den Libs noch nicht ganz: Wenn ich mit der XRechnung-Lib XRechnung und ZUGFeRD erstellen kann und sie mir overhead abnimmt, wozu gibt es dann die ZUGFeRD-Lib? Wann verwendet man die ZUGFeRD-Lib?

[Redeemer]

Eine aktuelle XML in einer Zugferd-PDF ist dasselbe wie XRechnung. Kein Unterschied. Ist exakt dasselbe.
Siehe hier:
https://www.delphipraxis.net/1537263-post64.html

[BlueStarHH]

Ich verwende jetzt die TInvoice von Sven (sh17). Einge Felder sind mir noch nicht ganz klar:

Es werden z.B. 2 Kartons mit je 10 Flaschen verkauft. 1 Karton kostet 9,99 EUR. Summe also 2 x 9,99 = 19,98 EUR

Ist die TInvoiceLine so richtig gefült?

Quantity=2
UnitCode=Kartons
PriceAmount=9.99
BaseQuantity=10
BaseQuantityUnitCode=Flaschen

Es ist mir klar, dass es keine Kartons oder Flaschen als UnitCode gibt. Das nur damit man das Beispiel besser nachvollziehen kann.

[sh17]

ja das wäre so richtig

[BlueStarHH]

Danke!

Frage zu UnitCode/BaseQuantityUnitCode: Was mache ich, wenn es dort eine Mengeneinheit nicht gibt. Konkret braucht ein Kunde Kartons, Eimer und Sets.

Frage zur Zahlungsart TInvoicePaymentMeansCode: Was mache ich, wenn es dort die Zahlungsart nicht gibt? Mögliche Zahlungsarten wären bei uns auch: PayPal, eBay, Amazon Pay.

[BlueStarHH]

Zitat:

Zitat von BlueStarHH (Beitrag 1539095)

Frage zur Zahlungsart TInvoicePaymentMeansCode: Was mache ich, wenn es dort die Zahlungsart nicht gibt? Mögliche Zahlungsarten wären bei uns auch: PayPal, eBay, Amazon Pay.

Jetzt habe ich die Antwort darauf schon selbst gefunden:

Code:

2.2.4 Electronic Wallet e.g. PayPal, AfterPay or other vendors.

Many vendors now provide online payment gateways that enable a user to view a web UI and enter card or online payment account information. The following example highlight how this information MAY be conveyed to the end user:

<cac:PaymentMeans>
  <cbc:ID>Online Payment Gateway</cbc:ID>
  <cbc:PaymentMeansCode listID="UN/ECE 4461">ZZZ</cbc:PaymentMeansCode>
<cbc:InstructionNote>https://mypaymentgateway.example.com/resource</cbc:InstructionNote>
</cac:PaymentMeans>

Some payment gateways MAY require additional information beyond a URI. In this circumstance, the FinancialAccount ABIE can be used to provide this information.

Quelle: https://docs.oasis-open.org/ubl/UBL-...l#_Toc26865417

<cbc:InstructionNote> müsste dann in TInvoice eingebaut werden?

[sh17]

ja, wahrscheinlich, schaue ich mir diese Woche mit an

Bei der Mengeneinheit müsste man mal in die Unit schauen, ob die gesuchte unter den auskommentierten Mengeneinheiten ist und ggf. nachrüsten. Ansonsten weiß ich auch nicht, was man dann macht.

[sh17]

Da immer mal wieder die Frage kommt, "Funktioniert die XRechnung-Lib und ZUGFeRD-Lib mit Delphi xy?".

Entwickelt wurden sie mit aktuellen Delphiversionen auch unter Nutzung aktueller Techniken (Generics, Encoding, Record Helper, UTF8-Codedateien, Namespaces, usw.)

Wenn sich ein oder mehrere Interessenten zusammenschließen wollen, unterbreite ich gern ein Angebot für den Zeitaufwand, um das ganze bis Delphi 6 zurück
kompatibel zu machen. Oder jemand liefert einen gängigen Pullrequest auf Github. Dann würde ich mich der Sache annehmen. Ansonsten nicht.

[Kostas]

Ich habe zwei Projekte die bei Delphi5 stehen geblieben sind. Die kann ich auch nicht hochziehen da die eingesetzten Fremdkomponenten nicht mehr existieren wie z.B. das Menü TBX.

Für die Umsetzung der XRechnung bzw. ZUGFerD plane ich eine eigene Anwendung zu erzeugen mit dem aktuellen Delphi. Diese Anwendung wird dann von der alten Anwendung mit irgendwelchen Parametern aufgerufen die dann die Rechnung in das gewünschte Format exportiert. Bei neuen Anwendungen würde ich die Komponenten natürlich direkt in die Anwendung integrieren. Die alten Delphi Version zu unterstützen macht verdammt viel Arbeit. Man sollte darüber nachdenken ob es wirklich notwendig ist.

[BlueStarHH]

Zitat:

Zitat von Kostas (Beitrag 1539234)

Die alten Delphi Version zu unterstützen macht verdammt viel Arbeit. Man sollte darüber nachdenken ob es wirklich notwendig ist.

Würde ich auch nicht machen. Entweder versuchen vom alten Delphi weg zu kommen (auch wenn das Jahre dauert. Bei uns wars über ein Jahr Aufwand) oder das hier:

Zitat:

Zitat von Kostas (Beitrag 1539234)

Für die Umsetzung der XRechnung bzw. ZUGFerD plane ich eine eigene Anwendung zu erzeugen mit dem aktuellen Delphi. Diese Anwendung wird dann von der alten Anwendung mit irgendwelchen Parametern aufgerufen die dann die Rechnung in das gewünschte Format exportiert.

Stellt euch mal vor, was passiert, wenn eure mit Delphi 5/6/... erstellte Anwendung auf einer der nächsten Windows-Versionen nicht mehr läuft, weil z.B. 32bit wegfällt. Mit jeder weiteren Delphi 5/6-Codezeile wird der Umstieg auf eine aktuelle Verion schwieriger.

Auch wenn ich mir mit dieser Aussage keine Freunde machen werde: Ich würde keinen Code auf alte Delphi-Versionen zurückportieren. Selbst nicht wenns mit Aufschlag bezahlt werden würde. Weil es Zeit braucht, die anderweitig besser eingesetzt werden kann und weil es den Code nur unnötig aufbläht, komplizierter macht und man die schönen neuen Dinge der neuen Delphi-Versionen nicht nutzen kann.

[himitsu]

Zitat:

Zitat von BlueStarHH (Beitrag 1539236)

Würde ich auch nicht machen. Entweder versuchen vom alten Delphi weg zu kommen (auch wenn das Jahre dauert.

Es wird auch noch immer schlimmer, je länger man wartet.


Aus Sicht der Komponentenentwickler kann ich es auch gut verstehen, dass jemand nicht "standardmäßig" auf neue Features verzichten will,
oder ständig alles doppelt/mehrfach zu entwickeln, mit IFDEF+ELSE für alte Delphis, inkl. dem Unterhalt von alten Delphi-Installationen, und ständig alles mehrfach überall testen zu müssen.

Was zumindestens noch "einfacher" ginge, wäre "optionale" Funktionen dann einfach komplett bei alten Delphis auszuschließen (IFDEF ohne ELSE) und sich den abwärtskompatiblen Fallback zu sparen.

[Kostas]

meine Projekte sind individuelle für den Kunden erzeugte Anwendungen. Seit vielen Jahre spreche ich das Thema beim Kunden an. Das Sache ist, es gäbe genügend neue Themen die eine Neuentwicklung rechtfertigen würden, doch die Zeit nicht einmal das Geld ist es die beim Kunden fehlt sich damit zu beschäftigen. Deshalb wird es Jahr für Jahr verschoben.

[himitsu]

In fast einem Jahr fängt dann Windows 10 an auszusterben (keine Updates mehr)
und dann wird es mit alten Delphis auch so schon immer schwerer.

Besonders schön, wenn der Kunde dann BilligLizenzen von Windows nutzen will, welche es für Win10 auch schon gibt,
wo aber nur noch Programme aus dem AppStore installiert werden dürfen ... nicht mehr billig eine EXE kopieren oder eine ZIP oder ein eigenes Setup.
Ja, man kann auch "nicht öffentlich" Programme im Microsoft-AppStore veröffentlichen, wo nur der/die eigenen Kunde(n) via Link und eventuell Passwort rein kommen.

[sh17]

Zitat:

Zitat von Kostas (Beitrag 1539238)

meine Projekte sind individuelle für den Kunden erzeugte Anwendungen. Seit vielen Jahre spreche ich das Thema beim Kunden an. Das Sache ist, es gäbe genügend neue Themen die eine Neuentwicklung rechtfertigen würden, doch die Zeit nicht einmal das Geld ist es die beim Kunden fehlt sich damit zu beschäftigen. Deshalb wird es Jahr für Jahr verschoben.

Eigentlich ist der ganze E-Rechnungskram schon ein willkommener Umsatzmotor. Jetzt kommen all die Kunden, die jahrelang keine Updates gekauft haben :)

[Kostas]

ich habe nur noch zwei Kunden mit D5 Projekte. Aber das verdammte TBX Menü zu ersetzen bedeutet ALLE Formulare anzupassen. Das ist verdammt viel Arbeit da es ca. 600 Formulare in den zwei Projekten sind. Dann muss ReportPrinter (Code-Basierte Reporter von Nevrona-Design) durch FastReport ersetzt werden. Die anderen Kleinkram Komponenten sind nicht so dramatisch. Deshalb warten wir ja auch den Start für ein Redesign doch dafür fehlt die Zeit von Kundeseite aus.

[jaenicke]

Zitat:

Zitat von Kostas (Beitrag 1539234)

Für die Umsetzung der XRechnung bzw. ZUGFerD plane ich eine eigene Anwendung zu erzeugen mit dem aktuellen Delphi. Diese Anwendung wird dann von der alten Anwendung mit irgendwelchen Parametern aufgerufen die dann die Rechnung in das gewünschte Format exportiert.

Dafür kann ich dir mein AppCentral Projekt empfehlen:
https://github.com/jaenicke/appcentral
Damit musst du das nur in Interfaces verpacken und kannst das leicht als DLL einbinden.

Zitat:

Zitat von Kostas (Beitrag 1539244)

Aber das verdammte TBX Menü zu ersetzen bedeutet ALLE Formulare anzupassen. Das ist verdammt viel Arbeit da es ca. 600 Formulare in den zwei Projekten sind.

Das sollte doch auch automatisch mit einem kleinen Tool gehen...
So habe ich auch von TMainMenu in sehr kurzer Zeit auf TActionMainMenuBar umgestellt...

[Redeemer]

Zitat:

Zitat von sh17 (Beitrag 1539207)

Da immer mal wieder die Frage kommt, "Funktioniert die XRechnung-Lib und ZUGFeRD-Lib mit Delphi xy?".

Entwickelt wurden sie mit aktuellen Delphiversionen auch unter Nutzung aktueller Techniken (Generics, Encoding, Record Helper, UTF8-Codedateien, Namespaces, usw.)

Wenn sich ein oder mehrere Interessenten zusammenschließen wollen, unterbreite ich gern ein Angebot für den Zeitaufwand, um das ganze bis Delphi 6 zurück
kompatibel zu machen. Oder jemand liefert einen gängigen Pullrequest auf Github. Dann würde ich mich der Sache annehmen. Ansonsten nicht.

Ich habe mit geringem Aufwand einen Port für D2010 gemacht, Sourcecoder ist auf D7 runter, ist also auch die Generics losgeworden. Wer das braucht, kann ja bei uns nachfragen. Wird wohl auch nichts kosten.

[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:

Zitat von sh17 (Beitrag 1540049)

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:

Zitat von kdf (Beitrag 1540045)

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:

Zitat von AuronTLG (Beitrag 1540057)

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:

Zitat von sh17 (Beitrag 1540049)

Krass, plus Runtimelizenz pro Endnutzer

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

[sh17]

Zitat:

Zitat von Redeemer (Beitrag 1540112)

Zitat:

Zitat von sh17 (Beitrag 1540049)

Krass, plus Runtimelizenz pro Endnutzer

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

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...8-)

Frage:
Kann man in der XRechnung mehrere Bankverbindungen erfassen?

Recherchen sagen überall NO. :wink: 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

[sh17]

Würden auch mehrere funktionieren. Muss es nur noch umsetzen.

[BlueStarHH]

Zitat:

Zitat von haentschman (Beitrag 1540360)

Moin...8-)Kann man in der XRechnung mehrere Bankverbindungen erfassen?

Zitat:

In der XRechnung darf nur eine Bankverbindung übermittelt werden, auf der bisherigen Papierrechnung sind jedoch oft zwei oder drei vermerkt. Welche der drei ist nun die, die mit der XRechnung übertragen werden soll?

Quelle: https://www.afi-solutions.com/blog/a...-alles-ist-gut

Stimmt das? Wurde das Format der XRechnung evtl. inzwischen gändert, so dass doch mehere Bankverbindungen möglich sind? Kann das mal jemand checken? Ich bin gerade unterwegs.

[sh17]

Also sowohl UBL

https://docs.peppol.eu/poacc/billing...-PaymentMeans/

als auch CII

https://portal3.gefeg.com/invoice/em...b-5b878840e508

erlauben mehrere Einträge

[Redeemer]

Wir nehmen eine zufällige. Machen wir auch schon beim EPC-Code ("Girocode").

Für den Kunden gibt es ja ohnehin keinen Nutzen, wenn da mehrere sind.

[haentschman]

Danke für die Info...8-)

Wir (ich) haben beschlossen, ein Mapping über die Kundennummern zu machen. (Großkunden da, Kleinkunden hier) Da können wir manches besser steuern. :wink:

Zitat:

Wir nehmen eine zufällige

...war auch im Gespräch.

[haentschman]

Moin...8-)

Neue Frage:
Wie beeinflusse ich die Nachkommastellen in den Positionen für die Menge?

Aktuell:
immer X.0000 - 4 Nachkommastellen!

SOLL:
entsprechend der Einheit verschiedene Nachkommastellen
Beispiele:
HUR (Stunde) 1,30 = 2 NKS
H87 (Stück) 23.56 = 0 NKS oder 2 NKS ... bin ich mir noch nicht sicher :wink:
1l (Pauschal) 1 = 0 NKS

:wink:

[sh17]

Die kann man nicht beeinflussen.

[haentschman]

Danke...:wink:

...aber :? In anderen E-Rechungen sehe ich in Quba 0 oder 2 stellige Nachkommastellen. :gruebel: Ist das vom Format festgelegt?

[BlueStarHH]

Zitat:

Zitat von haentschman (Beitrag 1540561)

Danke...:wink:

...aber :? In anderen E-Rechungen sehe ich in Quba 0 oder 2 stellige Nachkommastellen. :gruebel: Ist das vom Format festgelegt?

Dann schau mal in den XML-Code bei diesen Rechnungen? Gibt es da einen Tag oder Attribut für die Nachkommastellen? Oder sind die Zahlen einfach mit weniger Nachkommastellen angegeben?

[BlueStarHH]

Zitat:

Zitat von haentschman (Beitrag 1540568)

Was ist "XMLK-Code"? :gruebel:

Ups, Tippfehler. Sollte XML heißen.