Erweiterung um Konvertierung und Visualisierung about validator HOT 5 CLOSED

Ich erfasse momentan noch nicht, was mit createXR gemeint ist. Da brauchen wir noch mehr Input. Grundsätzlich besteht mit der bestehenden Umsetzung schon die Möglichkeit zur Visualisierung. Die XRechnung-Konfiguration nutzt beispielsweise intern HTML im Report (eingebettet in ein entsprechendes Element) um die Rechnung zu visualisieren (das XSLT erzeugt quasi XML, was innen drin wiederum HTML enthält). Es stehen darüberhinaus Funktionen zur Verfügung dieses HTML zu extrahieren:

• per cmdline via Schalter
• per API in dem Result auf DefaultResult gecasted wird und dann eine der extractHtml*-Methoden benutzt wird

from validator.

Danke für die Rückmeldung - da bin ich wohl etwas zu schnell eingestiegen.

Wie möchten die Komponente validator gern als REST-Webservice anbinden.
Im Webservice ist es möglich, die xRechung zu übergeben und einen entsprechenden Prüfbericht zurück zubekommen. In dem Prüfbericht ist auch HTML enthalten, das haben wir bereits gesehen.
Allerdings ist die Konvertierung zum zum einheitlichen Format (z.B. https://github.com/itplr-kosit/xrechnung-visualization/blob/master/src/xsl/cii-xr.xsl) nicht über den Webservice möglich.

Wir haben nach einer Möglichkeit gesucht, dass mit einer Webservice-Anfrage:

1. xRechnung validiert
2. Prüfbericht erstellt
3. Dokument nach urn:ce.eu:en16931:2017:xoev-de:kosit:standard:xrechnung-1 erstellt
4. die Visualisierung durchführt
5. alle Informationen als ein Response zurückliefert

Deshalb war der erste Gedanke, neben dem vorhanden createReport Tag weitere Tags einzubauen.

• createXR soll das Dokument nach urn:ce.eu:en16931:2017:xoev-de:kosit:standard:xrechnung-1 erstellen
• createHTML soll die Visualisierung durchführen

Die ersten Versuche diese Anforderung selbst im Quellcode vorzunehmen, habe ich gestoppt.

• XSD-Dateien müssten angepasst werden
• ggf. neue createXrInput.xsd und createHtmlInput.xsd
• neue CreateXrAction.java und CreateHtmlAction.java
• die neuen Actions einbinden
  Das war zu viel Aufwand, für eine solche kleine Änderung.

Allerdings habe ich einen anderen Weg gefunden. Wenn die "Start-Templates" von z.B. cii-xr.xsl um einen mode="cii-to-xr-invoice-template" erweitert werden, dann kann diese cii-xr.xsl in die xrechnung-report.xsl importiert und im Template "documentData" eingebunden werden.

Import in der xrechnung-report.xsl erweitert um die entsprechenden xsl

    <xsl:import href="./default-report.xsl"/>
    <xsl:import href="./visualization/xsl/ubl-invoice-xr-org.xsl"/>
    <xsl:import href="./visualization/xsl/cii-xr.xsl"/>
    <xsl:import href="./visualization/xsl/xrechnung-html.xsl"/>

Möglichkeit für ein documentData

<xsl:template name="documentData">
        <rep:documentData>
            <xsl:call-template name="conversions">
                <xsl:with-param name="input-document"><xsl:copy-of select="$input-document"/></xsl:with-param>
                <xsl:with-param name="report-document"><xsl:copy-of select="."/></xsl:with-param>
            </xsl:call-template>
        </rep:documentData>
    </xsl:template>

Möglichkeit für ein conversions-Template

    <xsl:template name="conversions">
        <xsl:param name = "input-document" />
        <xsl:param name = "report-document" />
        <!-- 
            Suche nach //scenario/name
            allerdings sollen dabei die Namespaces ignoriert werden
            https://stackoverflow.com/a/4440519/10651549
        -->
        <xsl:variable name="ScenarioName" select="$report-document//*[local-name() = 'scenario']/*[local-name() = 'name']" as="xs:string"/>
        <Converions>
            <xsl:attribute name="scenario"><xsl:value-of select="$ScenarioName" /></xsl:attribute>
            <xsl:choose>
                <xsl:when test="$ScenarioName = 'EN16931 CIUS XRechnung (CII)'">
                    <xsl:variable name="ConversionToDefaultInvoice">
                        <xsl:apply-templates mode="cii-invoice-root" select="$input-document"/>
                    </xsl:variable>
                    <xsl:variable name="ConversionToHtmlInvoice">
                        <xsl:apply-templates mode="xr-to-html-template" select="$ConversionToDefaultInvoice"/>
                    </xsl:variable>
                    <Html>
                        <xsl:copy-of select="$ConversionToHtmlInvoice"/>
                    </Html>
                    <Default>
                        <xsl:copy-of select="$ConversionToDefaultInvoice"/>
                    </Default>
                </xsl:when>
                <xsl:when test="$ScenarioName = 'EN16931 CIUS XRechnung (UBL Invoice)'">
                    <xsl:variable name="ConversionToDefaultInvoice">
                        <xsl:apply-templates mode="ubl-invoice-root" select="$input-document"/>
                    </xsl:variable>
                    <xsl:variable name="ConversionToHtmlInvoice">
                        <xsl:apply-templates mode="xr-to-html-template" select="$ConversionToDefaultInvoice"/>
                    </xsl:variable>
                    <Html>
                        <xsl:copy-of select="$ConversionToHtmlInvoice"/>
                    </Html>
                    <Default>
                        <xsl:copy-of select="$ConversionToDefaultInvoice"/>
                    </Default>
                </xsl:when>
                <xsl:otherwise>
                    <Default status="failed" />
                    <Html status="failed" />
                </xsl:otherwise>
            </xsl:choose>
        </Converions>
    </xsl:template>

Dadurch werden mit einem Request alle Dokumente erstellt und als ein Response zurückgemeldet.

Probleme bisher sind allerdings noch unparsed-text() in der https://github.com/itplr-kosit/xrechnung-visualization/blob/master/src/xsl/xrechnung-html.xsl#L22

Diese führen dann zu

java.lang.NullPointerException: charsetName
        at java.base/java.io.InputStreamReader.<init>(InputStreamReader.java:99)
        at de.kosit.validationtool.impl.RelativeUriResolver.resolve(RelativeUriResolver.java:94)
        at net.sf.saxon.functions.UnparsedTextFunction.readFile(UnparsedTextFunction.java:69)

validator.log

Vielleicht kann man diesen issue #45 auch schließen und das Problem mit der NullPointerException in einem anderen aufnehmen, oder?

from validator.

beim NPE scheint es sich um einen Bug in Saxon zu handeln. Der RelativeUriResolver bekommt keinen charsetName von Saxon geliefert. Ich werd mir das bei Gelegenheit ansehen. Können Sie vielleicht ein Minimal-Beispiel mit dem Fehler zusammenstellen und gern ein neues Issue einstellen?

Es gibt einen rudimentären Daemon-Mode, der ein REST-Interface bereitstellt (siehe Doku). Für alles was darüberhinaus geht, gibt es aktuell keine Unterstützung durch die Kosit. Letztlich eine Frage der Finanzierung. Die KoSIT stellt mit dem validator und der Konfiguration eine Basis- bzw. Beispielimplementierung bereit. Sollte übergreifender Bedarf bestehen, dann bitte direkt an die KoSIT wenden.

from validator.

Das REST-Interface kennen wir bereits und haben dieses auch für einen Prototypen bei uns im Haus genutzt.

An den KoSIT an der Stelle ein großes Dankeschön. Die Bereitstellung des Validators, der Testsuite und der passenden Dokumentation hat uns sehr geholfen, das Thema überhaupt greifen und verstehen zu können. Mit Hilfe des Prüfberichtes und der Visualisierung konnte bisher jedem Buchhalter die Angst vor dem Unbekannten genommen werden. Danke!

Sofern der #46 gelöst werden könnte, könnten wir unsere Wünsche schon mit dem bestehenden validator abbilden. Deshalb schließe ich den issue hier.

from validator.

Unabhängig von organisatorischen Fragen, rate ich davon ab, so verschiedene Concerns wie Validierung, Visualisierung und Konvertierung so eng zu verzahnen, wie hier diskutiert. Ich erinnnere da nur an das Concept "Separation of Concerns".

Der Validator wird alleine deswegen, nie mehr als validieren. Die Prüfberichete sind genau deswegen schon separate Konfigurationen für den Validator, die sich prinzipiell jeder selber anpassen kann.

Die KoSIT veröffentlicht eine Validator Konfiguration XRechnung zum Zwecke der Zusammenfassung aller notwendigen Schritte um eine Standard konforme Validierung mit Bericht vorzunehmen. Mehr nicht. Wir können keine Annahmen über besondere (weitere) lokale Anforderungen bei der Bearbeitung von Rechnungen vornehmen.

Wir werden die Konfiguration nach den Erfordernissen des Standards weiterhin anpassen. U.a. planen wir, dass der Validator demnächst reine XVRL Dokumente erzeugt und Konfigurationen dies als Input für Ihre weitere Prüfbericht-Erstellungen nehmen.

Daher rate ich davon ab, eigene Anpassungen zu sehr von der aktuellen Konfiguration abhängig zu machen.

from validator.