XRechnung-Visualisierung mit Kosit XSLT

[omp]

Hallo, ich möchte XRechnungen menschenlesbar darstellen.
Die vermutlich sauberste Lösung dürfte die Integration von
https://github.com/itplr-kosit/xrechnung-visualization/
in das Delphi-Programm sein.
Die Rechnungen (XML-Dateien) werden dabei mit XSL transformiert.

Grundsätzlich funktioniert so etwas in Delphi, beispielsweise:

Code:

procedure TForm18.Button1Click(Sender: TObject);
var
  xmlDoc, xslStyle: IXMLDOMDocument2;
  html: string;
begin
  xmlDoc := CoDOMDocument.Create;
  xmlDoc.Load(MyFileName);
  xmlDoc.setProperty('AllowXsltScript', true);
  xmlDoc.SetProperty('SelectionLanguage', 'XPath');
  xslStyle := CoDOMDocument.Create;
  xslStyle.Load(MyFileName2);
  html := xmlDoc.TransformNode(xslStyle);
  TFile.WriteAllText(OutFile, html);
end;

Die XML-Schnittstelle hat aber Probleme mit den import- und include-Funktionen im XSLT.
Ein Ansatz war jetzt, die verschiedenen .xsl-Dateien aus dem Kosit-Repo in eine Datei zusammenzufassen. Das ist aber ziemlich schwer bis unmöglich, wenn man mit XSLT keine Erfahrung hat.

Hat sich schon jemand damit beschäftigt oder sogar eine Lösung parat.

Gruß und besten Dank, Harald

[AuronTLG]

Ich schlage mich gerade mit einem eng verwandten Problem herum, da gerade die ZUGfERD 2.3 rausgekommen ist, der auch eine XSLT-Datei zum Visualisieren von XRechnungen (natürlich die ZUGfERD-äquivalente Variante) als HTML beiliegt.

Verschiedene Methoden führen immer zum selben Fehler. ('"document-uri" ist keine gültige XSLT- oder XPath-Funktion').
Da ich mir nicht vorstellen kann, dass die fehlerhafte XSLT-Dateien rausgeben, muss das Problem eigentlich bei Delphi liegen.

Ich habe jetzt nicht gerade viel Erfahrung mit XSLT-Transformationen in Delphi. Ging das für gewöhnlich oder ist das auch eine der lange nicht gepflegten Delphi-Funktionen, bei denen man ein Huhn opfern und heidnische Götter anrufen muss, dass sie hoffentlich noch funktionieren?

[omp]

Delphi nutzt dafür die Windows-API, Probleme vermute ich also eher bei Microsoft.
IXMLDocument und IXMLDOMDocument2 kommen, soweit ich das verstanden habe, nicht mit relativen Pfaden und import/insert-Anweisungen klar.

Ich habe das erst einmal zurückgestellt, weil es mich zu lange aufgehalten hatte. Ich hoffe noch, dass jemand den entscheidenen Hinweis für uns hat.

Gruß, Harald

[jan303]

Hallo,
ich bin auch gerade an dem Thema dran. Meines Erachtens nach liegt das Problem mit der XSLT-Transformation über die Kosit-Lösung daran, dass das XSLT in Version 2.0 vorliegt. Die XML-Implementierung im Delphi, die die Funktion TransferNode unterstützt, nutzt als DOMVendor MSXML und dieser kann nur XSLT 1.0.
Es gibt dabei mehrere Probleme:
- die XSLT-Dateien von Kosit (zum Beispiel cii-xr.xsl) importieren weitere xsl. Das konnte ich beheben, in dem ich das alles in eine Datei zusammengeführt habe.
- diverse Funktionen in den Kosit Dateien werden nicht in XSLT 1.0 unterstützt: replace, match, doc-available, ...

Es wird wohl nur durch ein äquivalentes Umschreiben der XSLT-Dateien in Ver. 1.0 oder über eine Delphi-Library, die Ver.2.0 beherrscht, gehen.

Für Rechnungen, die im CII-Format vorliegen, konnte ich aber aus den Schemadateien eine Delphi-Unit generieren. Allerdings nicht über die im RAD-Studio integrierte Funktion (damit war teilweise kein Zugriff auf Nodes möglich), sondern hiermit: https://github.com/MvRens/x2xmldatabinding
Für UBL hat das aber auch nicht funktioniert.

Jan