Wie sieht die Zukunft mit XRechnung, ZUGFerD, Peppol und Co. aus ?

[Rollo62]

Ich weiss nicht, ob dies schonmal irgendwo aufgetaucht ist.
Vielleicht ist diese Seite der EU auch interessant, was aufzeigt wie es in anderen Ländern damit aussieht,
falls damit jemand was zu tun hat.
https://ec.europa.eu/digital-buildin...United+Kingdom

Ich denke mal Online-Shops B2B oder B2C müssten sich den entsprechenden Länderregeln anpassen, so ist das allgemein in den neueren Verordnungen geregelt.
Das ist nämlich wider Erwarten nicht einfach EU-weit oder International festgelegt, es scheint da jeder sein eigenes Süppchen zu kochen, im Umgang mit eInvoicing.

Aber sowie ich weiss, betrifft es "normale" Auslandsgeschäfte erstmal nicht.

[BlueStarHH]

Eine interessante Nachricht bei heise.de:
"EU-Rat einigt sich auf E-Rechnung und Umsatzsteuermeldung in Echtzeit​"
Artikel unter: https://www.heise.de/news/EU-Rat-ein...-10005895.html

Im Heise-Forum dazu interessante Beitträge, die Themen aufgreifen, die hier auch diskutiert wurden:

1) Thema: Wie viele Bankverbindungen können in der E-Rechnung angegeben werden:
https://www.heise.de/forum/heise-onl...44591518/show/

2) Thema: Brutto-Rechnungen sind nicht möglich:
https://www.heise.de/forum/heise-onl...44590901/show/
(Aber vorsicht, einige dort verstehen das Problem nicht und haben eine vermeintliche Lösung)

[Kostas]

Hallo Zusammen,


ich habe ein allgemeine Frage zum Viewer. In dieser Komponenten ist ein E-Rechnungsviewer integriert.
Es gibt unendliche viele Rechnungsvarianten. Anhand den zwei Beispielen würde mich interessieren wie der Viewer das darstellen soll.

-Rechnung-A z.B. von einem Baumarkt.
beinhaltet die Positionen ArtikelNr, Menge, Einzelpreis und Pos.Gesamt.

-Rechnung-B z.B. Kabel verkauf in Meterware.
beinhaltet die Positionen ArtikelNr, Menge, Grundpreis, Kupferzuschlag, Legierungszuschlag, Teuerungszuschlag, Schnittzuschlag und Pos.Gesamt.

Ein Viewer muss beide Rechnungen darstellen können.

Bei Bauleistungsrechnungen wird es noch viel komplexer durch die Zahlungsanforderungen. Hier wird über die Laufzeit des Projektes nur die Mehrung in Rechnung gestellt. Am Ende einer jeden Rechnung werden alle vorher gestellte Rechnungen aufgelistet und auch der Zahlungseingang und das wird gegengerechnet. Die Rechnung macht jetzt also 1.500.000 € aus aber zu Zahlen ist nur die Mehrung von 23.500€. In irgend ein Anschreiben von der Behörde ist zu lesen dass die E-Rechnung derzeit keine Schluss-Rechnung darstellen kann. Es sollen nur Teilrechnungen erzeugt werden. Eine Zahlungsanforderungen ist dann so eine Teilrechnungen.

So ein Viewer kann doch unmöglich alle diese Varianten berücksichtigen. Werden nun alle Rechnungen auf den kleinsten gemeinsamen Nennen heruntergebrochen und nur ArtikelNr, Menge, Einzelpreis und Pos.Gesamt. oder was steckt für eine Magie dahinter?

[Rollo62]

Je tiefer man gräbt, umso schwachsinniger und undurchdachter wird das ganze Flickwerk.
Das wird wieder ein EU-weiter Beta-Test (naja, andere Länder sind da schon weiter ...).

Baumarkt/Mediamarkt ist gut, was ist, wenn ich dort für meine Firma z.B. dringendst einen Drucker kaufen muss, der > 250 EUR kostet, dann muss ich wohl an die Information, damit die mir irgendwie eine XRechnung ausstellen.
Sonst kann ich dort keine Teile als Firmenkunde dort einkaufen, es gibt glaube ich noch keine Pflicht unter 250 EUR, was dann für durchgängige eRechnung auch wieder blödsinnig ist, aber gut.
Kennt jemand etwa einen Baumarkt/Mediamarkt, der sowas schon anbietet oder in Arbeit hat?

Wahrscheinlich ist das ZUGFeRD sowieso Unsinn, und man sollte sich nur auf XRechnung konzentrieren.
Denn wie es schon in einem anderen Beitrag hieß, gibt es kleine Unterschiede/Fehler zwischen ZUGFeRD PDF und XML, dann hat man am Ende zwei separate Rechnungen vorliegen.
Da ist nur XML schon einfacher und man lässt das "schöne" PDF für den Kunden einfach weg, ist eh nur Ballast.

Was macht dann aber der Baumarkt/Mediamarkt, druckt der mir ein XML aus?

[stalkingwolf]

Hallo,

erstmal super Projekt. Funktioniert sehr gut.
Allerdings wird scheinbar eine Info nicht ausgelesen welche IMO ganz wichtig wäre.

Code:

 
<ram:SpecifiedTradeProduct>
    <ram:GlobalID schemeID="0160">4012345001235</ram:GlobalID>
    <ram:SellerAssignedID>TB100A4</ram:SellerAssignedID>
    <ram:Name>Trennblätter A4</ram:Name>
</ram:SpecifiedTradeProduct>

Und zwar die GlobalD. Das ist in der Regel die GLN und damit kann man Verkäufer identifizieren.
Ich sehe aktuell die Info nicht das ich dort dran komme.

Die Beispiele habe ich mir von der Seite www.awv-net.de heruntergeladen.

[sh17]

Zitat von stalkingwolf:

Hallo,

erstmal super Projekt. Funktioniert sehr gut.
Allerdings wird scheinbar eine Info nicht ausgelesen welche IMO ganz wichtig wäre.

Code:

 
<ram:SpecifiedTradeProduct>
    <ram:GlobalID schemeID="0160">4012345001235</ram:GlobalID>
    <ram:SellerAssignedID>TB100A4</ram:SellerAssignedID>
    <ram:Name>Trennblätter A4</ram:Name>
</ram:SpecifiedTradeProduct>

Und zwar die GlobalD. Das ist in der Regel die GLN und damit kann man Verkäufer identifizieren.
Ich sehe aktuell die Info nicht das ich dort dran komme.

Die Beispiele habe ich mir von der Seite www.awv-net.de heruntergeladen.

Anforderungen etc bitte nur über Github. Ich lese hier nicht alles mit und übernehme von hier auch keine Anregungen. Ansonsten gilt für mich auch der OpenSource Gedanke.

[jziersch]

Für diejenigen die PDFs mit ZUGFeRD Daten erzeugen müssen habe ich gerade die neue WPXOrder Bibliothek fertiggestellt.

https://www.delphipraxis.net/216155-...-erzeugen.html

Diese Bibliothek basiert auf einer Vielzahl von Klassen, die immer genau einen Sachverhalt wie er im XML stehen soll, enthalten.

Beim Lesen eine XML wird ein entsprechender Baum von Instanzen erzeugt, beim speichern rekursiv durchlaufen und geschrieben. Es werden nur Objekte und Eigenschaften geschrieben, die auch vorher erzeugt wurden, d.h. es werden keine undefinierte Objekte als leer geschrieben.

Es lassen sich alle Werte durch ansprechend der Objekt auslesen. Zu beachten ist, dass hierbei noch nicht erzeugte Objekte automatisch angelegt werden. Somit ist der Code zum Erzeugen der Daten und zum Auslesen sehr ähnlich.

Es steht ein Programm zur Verfügung, welches XML Daten automatisch in Delphi Code umwandelt. Damit sollte der Einstieg recht einfach sein.

Die eingebaute Berechnung kann das Summierungsobjekt automatisch befüllen - es wurde mit verfügbaren Beispieldaten getestet. Garantieren kann ich für die Funktionalität nicht da viele Sonderfälle (z.b. vielfache Währungen) nicht getestet werden konnten.

[Kostas]

Zitat von Rollo62:

Je ...
Was macht dann aber der Baumarkt/Mediamarkt, druckt der mir ein XML aus?

So wie ich das verstanden habe, kannst du eine PDF wie jetzt auch mit deinem Layout erzeugen und als Dateianlage beilegen. Das Problem ist, aus dem xml wird die Rechnung visualisiert und die muss natürlich identisch sein mit deiner PDF, zumindest inhaltlich. Aber genau das ist das Problem. Ein Viewer kann unmöglich alle Varianten abbilden. Viele Elemente einer Rechnung sind von der Platzierung her elementar, denn ansonsten ist es eine anderer Sachverhalt. Oder es wird alles herunter gerbrochen auf den kleinsten gemeinsamen Nenner. Das dürfte viele Rechnungsprüfer und co. zum Schwitzen bringen.

[Rollo62]

Genau, nur dass auch PDF und XML schon unterschiedlich sein können, je nachdem wie pingelig der Prüfer ist.
Deshalb bin ich mittlerweile fast der Meinung, vielleicht verzichtet man besser gleich auf das PDF, was ja nur optisches Beiwerk ist und hat einen Haufen Probleme weniger (technischer und finanzamtlicher Natur).