Libraler/Libertärer und pro-kapitalistischer Blog, umbenannt als Homage an "This time is different". Schreiblage: Von locker über ernst, ironisch bis sarkastisch und manchmal nur noch makaber. Ab Dez 2017 auch 'The next money will be different' integriert
Man muß sich schon ein wenig in diesem Bereich auskennen und ich bin dort zumindest seit mehr als 30 Jahren tätig. Anno 2008 hatte ich für mich beschlossen, mich langsam daraus zurückzuziehen und ich lag damit richtig.
„XRechnung und ZUGFeRD sind zwei Standards für elektronische Rechnungen in Deutschland. Die folgende Tabelle zeigt die wichtigsten Unterschiede und jeweiligen Vor- und Nachteile auf einem Blick:
Feature
XRechnung
ZUGFeRD
Format
Reiner XML-Standard
Hybrides Format: PDF mit eingebettetem XML
Syntax
UBL 2.1 oder CII
CII
Ziel
Automatische Verarbeitung
Menschliche Lesbarkeit und maschinelle Verarbeitung
Verpflichtend
Für B2G seit 27.11.2020, für B2B ab 01.01.2025
Freiwillig, aber weit verbreitet
Vorteile
Hohe Automatisierung, fälschungssicher
Gute Lesbarkeit, flexibel
Nachteile
Komplexere Erstellung, erfordert XML-Kenntnisse
Nicht so fälschungssicher wie XRechnung
Erfahren Sie nun, wie sich die XRechnung in den letzten Jahren entwickelt hat und welche Verpflichtungen in den nächsten Jahren auf Sie zukommen werden.“
Meine Güte, wie kann man so einen Blödsinn schreiben? UBL und CII sind zwei XML-Formate, Rechnung und Zugriff erfüllen die Anforderungen an eine Rechnung EN16931:2017
Fälschungssicher ist der totale Blödsinn das Ganze sieht so aus:
<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>123456XX</cbc:ID>
<cbc:IssueDate>2016-04-04</cbc:IssueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:Note>#ADU#Es gelten unsere Allgem. Geschäftsbedingungen, die Sie unter […] finden.</cbc:Note>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference>
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="EM">seller@email.de</cbc:EndpointID>
<cac:PartyName>
<cbc:Name>[Seller trading name]</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>[Seller address line 1]</cbc:StreetName>
<cbc:CityName>[Seller city]</cbc:CityName>
<cbc:PostalZone>12345</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>DE</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>DE 123456789</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>[Seller name]</cbc:RegistrationName>
<cbc:CompanyID>[HRA-Eintrag]</cbc:CompanyID>
<cbc:CompanyLegalForm>123/456/7890, HRA-Eintrag in […]</cbc:CompanyLegalForm>
</cac:PartyLegalEntity>
<cac:Contact>
<cbc:Name>nicht vorhanden</cbc:Name>
<cbc:Telephone>+49 1234-5678</cbc:Telephone>
<cbc:ElectronicMail>seller@email.de</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="EM">buyer@info.de</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID>[Buyer identifier]</cbc:ID>
</cac:PartyIdentification>
<cac:PostalAddress>
<cbc:StreetName>[Buyer address line 1]</cbc:StreetName>
<cbc:CityName>[Buyer city]</cbc:CityName>
<cbc:PostalZone>12345</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>DE</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>[Buyer name]</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>
<cac:PaymentMeans>
<cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
<cac:PayeeFinancialAccount>
<!-- dies ist eine nicht existerende aber valide IBAN als test dummy -->
<cbc:ID>DE75512108001245126199</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentTerms>
<cbc:Note>Zahlbar sofort ohne Abzug.</cbc:Note>
</cac:PaymentTerms>
<cac:TaxTotal>
<cbc:TaxAmount currencyID="EUR">22.04</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="EUR">314.86</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="EUR">22.04</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>7</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="EUR">314.86</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">314.86</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">336.9</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="EUR">336.9</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
<cbc:ID>Zeitschrift [...]</cbc:ID>
<cbc:Note>Die letzte Lieferung im Rahmen des abgerechneten Abonnements erfolgt in 12/2016 Lieferung erfolgt / erfolgte direkt vom Verlag</cbc:Note>
<cbc:InvoicedQuantity unitCode="XPP">2</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">288.79</cbc:LineExtensionAmount>
<cac:InvoicePeriod>
<cbc:StartDate>2016-01-01</cbc:StartDate>
<cbc:EndDate>2016-12-31</cbc:EndDate>
</cac:InvoicePeriod>
<cac:OrderLineReference>
<cbc:LineID>6171175.1</cbc:LineID>
</cac:OrderLineReference>
<cac:Item>
<cbc:Description>Zeitschrift Inland</cbc:Description>
<cbc:Name>Zeitschrift [...]</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>246</cbc:ID>
</cac:SellersItemIdentification>
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="IB">0721-880X</cbc:ItemClassificationCode>
</cac:CommodityClassification>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>7</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">288.79</cbc:PriceAmount>
</cac:Price>
</cac:InvoiceLine>
</ubl:Invoice>
Es ist ein Textformat, das man in jedem Editor bearbeiten kann. Es gibt keine Prüfsummen und keinerlei Sicherheit gegen Fälschung. Nachteile sind falsch, weil beide XML-Formate sind AFAIKT, läuft es bei Zugferd so, man generiert eine XML-Rechnung und generiert dann daraus das PDF.
Nur 2 von 6 Punkten sind richtig. Das ist jenseits von armselig.
In den docs Invoice line allowance amount Invoice line allowance base amount Invoice line allowance percentage Anz 0..1 Invoice line allowance reason Anz 0..1
Allowance Charge taucht nicht auf und schon gar nicht mal muß es da sein. reason code 0..1 -> es ist optional Nope, der muß da sein und wenn man den Text angibt, dann muß er genau dem code entsprechen. Der <cbc:ChargeIndicator>false</cbc:ChargeIndicator> ist extrem wichtig, wird aber nicht beschrieben. Wenn er auf false steht ist es ein Rabatt, bei true ein Zusatzaufwand.
Hm, der Staat gibt also Vorgaben vor, die fehlerhaft sind …
In der Spezifikation: „Es wird davon ausgegangen, dass alle Kosten und Zuschläge dem gleichen Umsatzsteuersatz unterliegen.
Tja und deswegen darf das in den Discounts nicht auftauchen.
Einfach nur „super“
Wie war es noch mit Standards? Es gibt 10 leicht voneinander abweichende Standards, lass uns die doch mal zusammenfassen und voilà 11 Standards.
Ihr blöden ITler bekommt echt nichts auf die Reihe, das bekommen wird dann zu hören.
Ach ja, auch witzig, es gibt Erweiterungen Die haben eine bestimmte Kennung: urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0#conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0
Was ist damit erlaubt? Sub Invoice Lines
Also Unterpositionen für Rechnungspositionen. Extrem sinnvoll, aber glauben Sie mal nicht da, dasi „so“ einfach. Sie müssen dann eine Position erfinden und darunter alles aufführen. Sie können keine Führungsposition mit Zahlen haben, da alle Summen in Unterpositionen zusammen genau der Summe der Überposition entsprechen müssen. Ihre Hauptposition muss als nach unten verschoben werden, damit die Summe übereinstimmt. Auch damit ist noch nicht alles gut. Schicken Sie es durch eine Validator wie diesen: https://erechnungsvalidator.service-bw.de/
Bekommen Sie eine Warnung, auch wenn Sie angeben, daß man die Extension benutzen will.
Es ist absurd. Bei Mitwirkende sind über 80 Personen angegeben, alle Staatsangestellte, und mir will jemand erzählen, dass es keinem von denen aufgefallen ist?
Die Implementierer der Validator müssen sich doch bei denen gemeldet haben – oder aber die Validierer taugen auch nicht viel.
Es ist wirklich absurd.
Es ist tatsächlich lustiger als es sein sollte.
Und als Tüpfelchen auf dem i. Es gibt keine Adresse, an die man sich wenden können um, umhler zu melden!
Der Staat und seine Angestellten machen keine Fehler:
Zitat: „Die Bürokratie entsteht aus etwas gutem heraus, du sagst es sind alles Idioten versteht man nicht wo das Problem ist. Es ist etwas Gutes, denn der Staat macht ja keine Fehler. Stellen Sie sich vor, jede zweite Baugenehmigung wäre wieder zu kassieren. Und Sie wären mit dem Risiko alleine gelassen. Oder jede zweite Lebensmittelausgabe, Bäcker oder Restaurants wäre gesundheitsgefährdend und alle hätten permanent Durchfall. Wäre auch nicht gut.“
Schwachkopf darf man diesen Menschen nicht nennen, dann gibt „reichlich fehlerlosen Staat“
Nirgendwo hat der Sozialismus den Menschen eine bessere Zukunft beschert, nur mehr Leid bis zum Mord. Dabei ist es völlig egal, ob es um die internationale Variante oder die nationale ging/geht.
