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

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

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

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

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

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