XRechnung - soll ab 2025 Pflicht werden

    Hmmm wenn man im Template die Rundung beim Preis entfernt dann läuft die Rechnung durch:


    <cbc:PriceAmount currencyID="{$rechnung.kopf.waehrung}">{$position.umsatz_netto_einzeln|string_format:"%.2f"}</cbc:PriceAmount>


    ->


    <cbc:PriceAmount currencyID="{$rechnung.kopf.waehrung}">{$position.umsatz_netto_einzeln}</cbc:PriceAmount>


    Kannst Du das bitte mal durchtesten? Wenn sich das bestätigt passe ich das Template an.

    Nun, wo ich näher nachlese, hätte ich für meine Kunden gern noch den Preis je Position näher aufgeschlüsselt... hab das hier als Beispiel auf https://docs.peppol.eu/poacc/billing/3.0/bis/ unter "§9.2. Calculation on line level" gefunden. Je länger man gräbt, desto mehr findet man auch -_-.


    Code
    <cac:Price>
    <cbc:PriceAmount currencyID="EUR">410</cbc:PriceAmount>
    <cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
    <cac:AllowanceCharge>
        <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
        <cbc:Amount currencyID="EUR">40</cbc:Amount>
        <cbc:BaseAmount currencyID="EUR">450</cbc:BaseAmount>
    </cac:AllowanceCharge>
</cac:Price>


    Die Info des Listenpreises wäre damit dann auch übergeben.

    Ich tue mich nur schwer damit herauszufinden, wie ich an die Werte komme, die da rein müssen ;)

    Hallo, wir beschäftigen uns auch gerade mit dem Thema E-Rechnung und schauen gerade, wie wir von Xentral 20.3 wegkommen.


    Wenn ich eine Rechnung mit einer Stückliste (und mehreren Stücklistenpositionen mit 0€) habe, dann wird in der PDF-Version nur die Stückliste selber gedruckt.



    In der XML-Rechnung stehen dann aber alle drin. Jetzt kenn ich nur den Good-old-Xentral-Weg, das alles im class.briefpapier in renderItems() zu machen. Wie müsste man das im XML-Pfad machen? Ich sehe in pages/rechnung.php in RechnungSmarty() die for-Schleife über die Positionen. Dort einfach entsprechend filtern? Oder in dem Smarty-Template?


    PS: in rechnung.php:1348 meckert er rum, dass in round($erloes, 2) $erloes ein String ist. Ich kann da auch gerne einen Pull-Request über github machen

    Hi Alex,

    bei cbc:id ist vermutlich die USt-Id des Rechnungsempfängers gemeint, oder?
    Kann man die Felder wie z.B. Absender und Empfänger E-Mail Adresse und USt-Id nicht mit einer Variable aus den Stammdaten füllen?

    z.B.: $rechnung.kopf.ustid

    Code
    <cbc:EndpointID schemeID="EM">info@musterfirma.de</cbc:EndpointID> <!-- HIER MANUELL MAILADRESSE EINTRAGEN -->
<cbc:Telephone>0123567890</cbc:Telephone> <!-- HIER MANUELL TELEFONNUMMER EINTRAGEN -->
<cbc:ElectronicMail>info@musterfirma.de</cbc:ElectronicMail> <!-- HIER MANUELL MAILADRESSE EINTRAGEN -->
<cbc:ID>DE12345678</cbc:ID> <!-- HIER MANUELL IBAN EINTRAGEN -->


    Aktiviert man xml-rechnung verschwindet rechts oben das PDF Symbol und der Vorschau Reiter für die PDF. Ist das ein Bug oder ein Feature? :)

    Richtig, cbcID ist deine Umsatzsteurident


    Das dein PDF Hinweis angeht, das stimmt. aktuell wird nicht beides angezeigt.

    Um an die PDF zu kommen musst du aktuell die Rechnung nochmal öffnen und den Haken bei XML Rechnung entfernen und Speichern.


    Dann hast du die Rechnung als PDF, aber auch die Gespeicherte XML im Anhang beim Versand.


    Grüße

    Tobias Kannst Du mir bitte mal eine Liste machen welche Felder der Xrechnung Du gerne aus welchen Feldern in OpenXE haben möchtest? Ich denke ggf. müsste man da auch noch neue Felder anlegen...


    Wegen PDF vs. XML: Laut Gesetzgeber ist bei Verwendung von E-Rechnung das XML bindend, man kommt also so oder so nicht umhin das mit einerm Reader bzw. anderer Software aufzumachen. OpenXE ist auch überhaupt nicht in der Lage die PDF-Rechnung und die E-Rechung 100% identisch zu erzeugen da es 2 komplett getrennte Programmteile sind. Für die E-Rechnung gelten strengere Vorgaben, die auf der PDF verletzt werden können. (z.B. Rundung mit der Steuer etc.)


    Deswegen gilt hier: entweder PDF/Papier oder XML, beides geht nicht.

    Ja. Die PDF Vorschau habe ich aus ähnlichen Gründen sehr oft genutzt. Jetzt lege ich mir die PDF auch zur Übersicht parallel mit dem Hinweis ab, dass es ja eine XML gab.


    Inhaltlich müsste korrekter Weise nun eine Vorschau generiert werden die aus dem Inhalt der XML erstellt wird. Das würde bedeuten, dass quasi ein kompletter E-Rechnungs-Reader implementiert wird, der zur Vorschau zu Rate gezogen wird. Nur dann könnte man als Mensch wieder versuchen die Arbeit der Maschine sinnvoll zu kontrollieren. Aber das wird schwer... wenn man eine Rechnung zum Beispiel bei ELSTER rein wirft, ist das auch nicht viel übersichtlicher als eine XML :D. Das Ziel ist es ja nur das ganze etwas weniger sperrig lesbar zu machen.


    So sehr ich mir auch eine Lösung wünsche fehlt mir wahrscheinlich der Weitblick um mir eine sinnvolle Lösung auszudenken -_-

    Gibt es bezüglich Zugferd neue Entwicklungen?

    Ist das überhaupt noch ein Thema?

    Das scheint mir eine anwendungsfreundlichere Übergangslösung zu sein, bevor man komplett digital wird, da man es normal als PDF öffnen und digital auslesen kann, wobei es wohl die schwerere Implementierung erfordert.


    Das soll die bisherige Leistung jedoch nicht schmälern. Es ist schon richtig gut, dass wir XRechnungen erzeugen können.

Participate now!

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

Register Yourself Login