XRechnung - soll ab 2025 Pflicht werden

    PDF mit integriertem XML werden wir vorerst nicht unterstützen, Du kannst aber pro Kundengruppe und darüberhinaus pro Adresse festlegen welches Format versendet werden soll, PDF oder ein XML-Format. Momentan haben wir XRechnung als XML-Format vorbereitet, es spricht aber auch nichts dagegen die eher im Zugferd-Projekt verwendete Syntax "UN/CEFACT" als Format hier anzulegen.

    Quote from Alex

    PDF mit integriertem XML werden wir vorerst nicht unterstützen, Du kannst aber pro Kundengruppe und darüberhinaus pro Adresse festlegen welches Format versendet werden soll, PDF oder ein XML-Format. Momentan haben wir XRechnung als XML-Format vorbereitet, es spricht aber auch nichts dagegen die eher im Zugferd-Projekt verwendete Syntax "UN/CEFACT" als Format hier anzulegen.

    Da wir im Laufe des nächsten Jahres (vermutlich Ende 2025) auf OpenXE umsteigen möchten und wir schon von vielen Kunden gehört haben dass sie sich das Format Zugferd wünschen wäre dies sehr hilfreich, vermutlich auch für viele andere Nutzer.


    Ich gehe davon aus, dass der Großteil der Kunden weiterhin auf eine manuelle Bearbeitung der Eingangsrechnungen setzen wird. Sprich die Rechnung sollte weiterhin direkt beim öffnen oder Ausdrucken klar ersichtlich sein wie bisher.


    Vielleicht ist es möglich auch Zugferd in OpenXE zu generieren.


    Danke im Voraus.

    Ich habe mir erlaubt dein Template zu erweitern.

    In der .xml für die Bankdaten

    - accountholder (Kontoinhaber)

    - BIC hinzugefügt


    Code
        <cac:PaymentMeans> <!-- Kontoverbindung Start-->
        <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
        <cac:PayeeFinancialAccount>
            <cbc:ID>DEXXXXXXXXXXXXXXXXXXXX</cbc:ID> <!-- HIER MANUELL IBAN EINTRAGEN -->
            <cbc:Name>Vorname Nachname</cbc:Name> <!-- HIER MANUELL Kontoinhaber EINTRAGEN -->
        <cac:FinancialInstitutionBranch>
            <cbc:ID>XXXXXXXXXXX</cbc:ID><!-- HIER MANUELL BIC EINTRAGEN -->
        </cac:FinancialInstitutionBranch>
        </cac:PayeeFinancialAccount>
    </cac:PaymentMeans> <!-- Kontoverbindung ENDE-->
    Quote from Alex

    Das Thema hatten wir schonmal bei den Verbindlichkeiten. Da ist es so gelöst das mehrere Wege gerechnet werden für die Summe. Evtl. würde es helfen wenn man im XML verschieden berechnete Summen zur Auswahl hätte?


    Mit Bruttopreisen kenne ich mich nicht aus, ich meine irgendwo mal elesen zu haben dass XRechnung nur mit Nettopreisen funktioniert.

    Hi,

    ich bin neu hier und komme gerade erfolgreich aus Version 18.xx.... Vielen Dank für die Viele Arbeit.


    Der Grund liegt auf der Hand: die X-Rechnung.

    Daher nun auch direkt der erste erfolgreiche Fehlschlag. Hier allerdings nicht mit dem Thema Steuern, sondern mit dem Thema Rabatt. Offensichtlich interessiert das Thema der Rabatte nicht und ist daher in der Rechnung nicht enthalten.


    Rechnerisch wird in OpenXE aktuell der Netto Listenpreis rabattiert. Dabei kommt etwas krummes raus mit 4 Stellen nach dem Komma. Dies wird dann beispielhaft mit 10 Stück multipliziert und und die dritte Stelle wander eins nach vorn. Damit hat der genannte erechnungsvalidator.service-bw.de ein Problem. Ändere ich die Werte, Geht die Rechnung durch.


    Möglicherweise denken wir alle viel zu genau und der Schlüssel ist einfach zwischendurch zu runden und einfach nur mit zwei Nachkommastellen weiter zu machen. Dies wäre dann natürlich global sinnvoll, damit alle Rechnungen gleich berechnet werden. Ich denke die Auswahl verschiedener berechneter Summen stiftet Unruhe.


    Es bleibt zu testen, ob zwischendurch runden oder einfach abhacken die angenehmere Lösung für Validierungsprogramme ist. Gibt es denn auch noch andere Seiten Validieren? Die hier (https://www.epoconsulting.com/…g-sap/xrechnung-validator) verhält sich im genannten Fall auf jeden Fall gleich zu der aus BW

    Das ist ja jetzt auch schon fest hinterlegt. Denke ich mal ;).

    Der Fehler entsteht dadurch, dass der Stückpreis (<cbc:PriceAmount currencyID="EUR">15.94</cbc:PriceAmount>) nur zwei Nachkommastellen hat, die Summe der 10 Stück in OpenXE aber mit aber mit dem vierstelligen Nachkommawert errechnet wird und in der Rechnung eingetragen wird (<cbc:LineExtensionAmount currencyID="EUR">159.43</cbc:LineExtensionAmount>).

    Wenn in der Prüfung nun 15,94*10 gerechnet wird, kommt da unweigerlich 159,40 raus und folglich 3 cent weniger als in der XML eingetragen.

    Es wird weniger der richtige Weg sein als der nachvollziehbare Weg.

    (( ob ich die 15,9432 vorher abrunde oder aufrunde ist nicht das Problem des Finanzbeamten. Das müssen wir zwischen Unternehmer und Unternehmer klären. Der Finanzbeamte will aber in seinem Dokument schlüssig nachvollziehbare Zahlen haben.))


    nachdem ich nun bei schreiben nachgedacht und alles wieder gelöscht habe liegt dieser Fehler darunter begraben, dass bis jetzt niemals ein rabattierter Einzelpreisausgegeben wurde... daher ist dieser noch vierstellig nach dem Komma. Es darf aber nur mit dem ausgegebenen Wert mit zwei Nachkommastellen weitergerechnet werden. (Global angepasst würde dies zu einem anderen Ergebnis führen. Die XML geht dann durch den TÜV und auf der PDF ist es weiterhin nicht zu 100% nachvollziehbar, wie gerechnet wurde.)


    Auf dieser Basis würde ich vermuten, dass das Berechnungsproblem im Umsatzsteuerbereich behoben werden kann. Dies gab es bis jetzt nicht, da alle Artikel 19% drauf bekamen... Die XRechnung scheint es zu ermöglichen unterschiedliche Steuersätze für unterschiedliche Artikel zu haben.

    Auf Basis der Erfahrung bei den Artikel-Rabatten tippe ich darauf, dass die zeilenweise Berechnung inkl. Rundung auf zwei Nachkommastellen und das dann folgende Summieren der Einzelwerte zu validierbaren Ergebnissen führt.


    ... die zwei Nachkommastellen in einer Rechnung sind natürlich auch nachvollziehbar korrekt. Alles andere würde Fragen aufwerfen.

    • New
    Quote from getthemax

    Ich habe das ganze mal für Kleinunternehmer umgesetzt, bin aber auch nicht wirklich sicher ob das so richtig ist, daher würde ich mich freuen, wenn der ein oder andere sich das einmal anschauen könnte.

    Die Rechnung kann zumindest erfolgreich Validiert werden.

    für "Kleinunternehmen" macht das ganze gar kein sinn da hier keine Umsatzsteuer anfällt und die dementsprechend auch gar nicht unter diese Regelung fallen

    • New

    Es gibt Unternehmen die lieber eine E-Rechnung haben wollen, daher bin ich der Meinung wenn es möglich ist, dann kann man das auch umsetzten, anstatt einfach zu sagen, das ich nicht dazu verpflichtet bin.


    Das ganze gilt auch für Kleinunternehmer ab 2028, ok das ist noch etwas hin

    • New

    Entweder stelle ich mich zu blöd an, oder ich verstehe es nicht.

    Wo lege ich denn fest, ob der Kunde eine XRechnung erhalten will oder klassisch die PDF Version. Und greift das auch für den Abo-Lauf?


    Edit: Gefunden. Man muss dem Benutzer das XML Recht geben, sonst taucht das Feld nicht auf.

    • New

    Nachdem ich jetzt die Option habe dem Kunden ein XML Template zuzuweisen, wollte ich das doch mal ausprobieren (falls tatsächlich einer auf die Idee kommen sollte und eine richtige Rechnung haben will).


    Dabei ist mir aufgefallen: Es gibt keinen Reiter "Vorschau" mehr. Da habe ich immer geschaut, ob der Inhalte passt.
    Die Funktion "PDF öffnen" liefert mir nur eine leere weiße Seite. Bug oder "works as designed"?


    Und was mir noch aufgefallen ist: In der letzten Version des Template sind ja einige Stellen, die man manuell befüllen soll. Mit Daten die OpenXE ja eigentlich hat. Lassen die sich noch automatisieren?


    Und wofür sind die noch auskommentierten Bereiche?

    • New

    Und noch was:

    Damit die Positionen in der PDF Version vernünftig lesbar sind, enhalten sie zum Teil Zeilenumbrüche. Das sieht in der XRechnung jetzt merkwürdig aus:


    Lässt sich da noch was machen?


    Ansonsten habe ich es geschafft mit dem XMLTemplate eine laut Validator gültige XRechnung zu erzeugen. TOP und Danke dafür.


    Man muss ja irgendwo die Ust-ID. bzw. die Steuernummer unterbringen. Vermutet habe ich da mal das Feld cbc:CompanyID, aber dann taucht der Inhalt in den Visualisierungstools an zwei Stellen auf:


    Was muss ich anpassen, damit die Nummer nur unter Steuer-ID steht, wo sie ja auch hingehört?

    • New

    Vorschau gibt es für XML nur insofern als dass man sich die XML-Datei herunterladen kann und dann z.B. mit Quba ansehen. Dazu klickst Du auf das XML-Symbol neben dem Speichernknopf:



    Den Menüeintrag (PDF öffnen) passe ich noch an, danke für den Hinweis.

    • New
    Quote from kroerig

    Und was mir noch aufgefallen ist: In der letzten Version des Template sind ja einige Stellen, die man manuell befüllen soll. Mit Daten die OpenXE ja eigentlich hat. Lassen die sich noch automatisieren

    Sicherlich lässt sich das noch erweitern, Fokus war jetzt in erster Linie die Funktion grundsätzlich zu ermöglichen. Erweiterungen kommen entweder mit der Zeit bei Bedarf oder ggf. Entwicklungsauftrag.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login