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

[BlueStarHH]

Zitat von BlueStarHH:

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 von Kostas:

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 von Kostas:

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 von BlueStarHH:

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.

[Redeemer]

Zitat von 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.

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.