[FEATURE] elektronische Rechnung als XML nach Richtlinie 2014/55/EU

[stm9x9]

Das ist zwar noch Zukunfstmusik, aber damit wir es auf dem Schirm haben:

Das geplante Wachstumschancengesetz verpflichtet Rechtsanwälte, ab dem 1.1.25 gegenüber inländischen Unternehmern elektronische Rechnungen zu stellen und zu verarbeiten (vgl. Gesetzentwurf vom 30.8.23 unter iww.de/s8772 ). Die elektronische Rechnung soll der europäischen Norm für die elektronische Rechnungsstellung nach Richtlinie 2014/55/EU entsprechen. Diese Norm ist auch die Grundlage des Formats XRechnung, das bereits seit November 2022 gegenüber öffentlichen Auftraggebern verwendet werden muss. Die Richtlinie sieht die Übermittlung der Rechnungsdaten in dem rein maschinenlesbaren Format XML vor. Nicht zulässig sind Rechnungen im Textformat als PDF oder E-Mail

Quelle: https://www.iww.de/rvgprof/praxisfaelle/elektronischer-rechtsverkehr-wachstumschancengesetz-elektronische-rechnung-soll-fuer-rechtsanwaelte-ab-2025-pflicht-werden-f156217

---------------- @j-dimension 2024-08-15 -----------------------

Muss:

• [x] Zugferd Java API integrieren: 0,75h
• [ ] Mapping Datenmodelle: j-lawyer Rechnung zu Zugferd-Rechnung: 1,25h
• [ ] bei Generieren eines PDFs zu einem Rechnungsdokument: Rechnung als Zugferd-Objektmodell erstellen: 1,25
• [ ] bei Generieren eines PDFs zu einem Rechnungsdokument: Zugferd-Objektmodell in XML konvertieren und in PDF einbetten 0,5h
• [ ] XRechnung-XML generieren (Rechnungslegung an öffentliche Auftraggeber)
• [ ] Schalter für "als elektronische Rechnung: ja/nein" - nicht überall wird das benötigt werden - bspw. bei Rechnungslegung ins Ausland - optional (evtl. schadet es nicht, die XML-Daten immer einzubetten)

Die Daten des Verkäufers sind aktuell entweder fest in der Rechnungsvorlage oder werden bspw. aus dem Kanzleiprofil übernommen. Das ist dann nicht mehr praktikabel - sie müssten entweder vom angemeldeten Nutzer, oder besser über eine Auswahl definiert werden können (bspw. stellt Sekretariat Rechnungen mal für RAin1 oder RA2). Bedingt:

• [x] Datenmodellerweiterung in Nutzerverwaltung um Kontodaten, Anschrift, Unternehmensname, Steuerinformationen, ... (fast alles, was auch an einer Adresse steht): 1,75h
• [x] zusätzliche Services zum Verändern dieser Daten: 1h
• [x] Oberfläche zum Pflegen der Daten: 2,5h
• [x] bei Belegerstellung den Rechnungssender auswählbar machen: 1,25h
• [ ] Test und Dokumentation: 2h

optional:

• [ ] Generieren der LibreOffice / MS Office-Rechnung und Erstellen des PDFs können zeitlich auseinanderliegen, und es gab inzwischen evtl. Änderungen an der Rechnung. Evtl. ist der Workflow so anzupassen, dass das PDF immer direkt mit generiert werden MUSS, um die Konsistenz zu wahren: 2,25h
• [ ] bei Erhalt einer Rechnung: auf eingebette XML-Daten prüfen, Darstellung mit separatem Icon in der Dokumenteliste der Akte, Import als Beleg ermöglichen: 3,25h

ohne optionale Punkte: 12,25h komplett: 17,75h

ungeplant:

• [ ] zusätzliche Daten am User per Platzhalter bereitstellen
• [ ] neue Platzhalter dokumentieren, Vorlage aktualisieren
• [x] bei Änderung der Nutzerdaten muss Nutzer im Cache des Clients aktualisiert werden
• [ ] Viewer für XML-Rechnungen
• [ ] Import von XML-Rechnungen als Beleg(?)
• [x] REST API erweitern (zusätzliche Attribute am User)
• [ ] Rechnungssender in Auswertungen (verschiedene) aufnehmen
• [ ] Girocode nicht mehr mit Daten aus Kanzleiprofil, sondern aus den Daten des rechnungslegenden Nutzers
• [ ] unterschiedliche Zahlungsarten unterstützen
• [ ] Lastschriftmandat - Erweiterung der Adressverwaltung

[j-dimension]

https://konik.io/docs/index.html

[RobertT01]

• noch ein paar weitere Info
• https://www.frankfurt-main.ihk.de/recht/uebersicht-alle-rechtsthemen/steuerrecht/umsatzsteuer-national/e-rechnungspflicht-ab-2025-6055774
• e-rechnung ist nicht relevant gegenüber Verbrauchern
• mal sehn was mit der Abrechnung gegenüber der RS wird, man könnte es so machen wie gegenüber der Allianz, Abrechnung an den Mdt adressiert und der RS geschickt
• sollte wir hier ein finanziertes Projekt drausmachen? der Kostenaufwand schein bei der veranschlagten Zeit überschaubar

[j-dimension]

https://github.com/ZUGFeRD

[j-dimension]

Breaking Change ohne Rückwärtskompatibilität: da sehr viele neue Platzhalter für den angemeldeten Nutzer entstehen, soll ein einheitlicher Präfix gefunden werden. Daher wird es einige Platzhalter geben (bspw. Anwaltskürzel, Autor), die ab 2.7 nicht mehr unterstützt werden.

--> Doku und Release Notes

[j-dimension]

Nutzerverwaltung mit den Daten, die nun an jedem Nutzer hinterlegt werden können. So sind verschiedene Rechnungssender mit eigenen Bankverbindungen etc. möglich.

[stm9x9]

ist damit abbildbar, daß Rechnungen nicht unbedingt vom jeweiligen Anwalt(snutzer) geschrieben werden, sondern zb von einer Refa (für mehrere Anwälte)?

Oder andersrum gefragt: kommt es wirklich vor, daß man je Rechnungssender verschiedene Daten hat? Es geht doch alles an die Kanzlei? Allenfalls wenn in einer Bürogemeinschaft eine jl-Instanz verwendet wird, fiele mir als Anwendungsfall ein.