Runden bei Negativwerten

[mtlmarko89]

Eine Kunde von uns will, dass bei Gutschriften die Wert mit einem Minus versehen werden sollen. Gem. den Vorschriften ist das bei Gutschriften gestattet, auch wenn ich persönlich das eher irritierend als hilfreich finde, aber man sagt ja so schön, der Kunde ist König, und solange man damit nicht gegen gesetzliche Vorschriften oder andere Normen verstößt ...

Beim Validieren mit Mustang ist mir dabei jedoch ein Fehler aufgefallen. Bei Rechnungen ist es immerhin typisch gem. DIN 1333 kaufmännisch und nicht mathematisch zu runden. In diesem konkreten Fall, müsste also bei Negativwerten der Betrag und nicht der Wert an sich gerundet werden. Somit müsste also (bspw. beim Steuerbetrag) wenn -12,345 € rauskommt nicht -12,34 €, sondern man müsste zunächst 12,345 runden, was dementsprechend 12,35 ergibt und dann entsprechend des Originalwerts wieder negativ setzen, somit wäre der richtige Wert dann -12,35 €.

[jstaerk]

Den Vorschriften nach ist sind negative Beträge nur bei Stornorechnungen/Rechnungskorrekturen (Typecode 384), nicht bei kaufmännischen Gutschriften (Typecode 389) gestattet, vgl. EN16931-1.

Das Verhalten bei negativen Zahlen bzw. kaufmännisch vs. Bankers rounding ist trotzdem interessant und würde ja dann auch bei Stornorechnungen auftreten, ein Issue 150 der AWV beschäftigt sich auch mit dem in XSLT verankertem Bankers Rounding.

Lange Rede kurzer Sinn: gibt es steps to reproduce, lies könnten Sie mir bitte ein vollständiges Beispiel schicken? XML reicht. Danke.

[mtlmarko89]

OK, da scheine ich wohl nur die Hälfte gelesen zu haben, aber Danke, darauf werde ich dann mal meinen Kunden aufmerksam, denn so wie ich das verstanden habe, wollen die bei allen, was irgendwie Gutschrift heißt, Negativbeträge schreiben. Danke für den Hinweis!

Derzeit bin ich nicht am Arbeitsplatz, aber am Montag kann ich auf jeden Fall die XML aus der PDF hier anhängen, die ich versucht hatte zu validieren.

Bis Montag dann und noch ein schönes Restwochenende!

[mtlmarko89]

Interessant, ich kann gar keine XML hochladen, na ja, dann eben so:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- English disclaimer below.-->
<!--Nutzungsrechte
ZUGFeRD Datenformat Version 2.1, 24.03.2020

Zweck des Forums elektronisch Rechnung Deutschland, welches am 31. März 2010 unter der Arbeitsgemeinschaft für
wirtschaftliche Verwaltung e. V. gegründet wurde, ist u. a. die Schaffung und Spezifizierung eines offenen Datenformats
für strukturierten elektronischen Datenaustausch auf der Grundlage offener und nicht diskriminierender, standardisierter
Technologien („ZUGFeRD Datenformat“).

Das ZUGFeRD Datenformat wird nach Maßgabe des FeRD sowohl Unternehmen als auch der öffentlichen Verwaltung
frei zugänglich gemacht. Hierfür bietet FeRD allen Unternehmen und Organisationen der öffentlichen Verwaltung eine
Lizenz für die Nutzung des urheberrechtlich geschützten ZUGFeRD-Datenformats zu fairen, sachgerechten und nicht
diskriminierenden Bedingungen an.

Die Spezifikation des FeRD zur Implementierung des ZUGFeRD Datenformats ist in ihrer jeweils geltenden Fassung
abrufbar unter www.ferd-net.de.

Im Einzelnen schließt die Nutzungsgewährung ein:
=====================================

FeRD räumt eine Lizenz für die Nutzung des urheberrechtlich geschützten ZUGFeRD Datenformats in der jeweils
geltenden und akzeptierten Fassung (www.ferd-net.de) ein.
Die Lizenz beinhaltet ein unwiderrufliches Nutzungsrecht einschließlich des Rechts der Weiterentwicklung,
Weiterbearbeitung und Verbindung mit anderen Produkten.
Die Lizenz gilt insbesondere für die Entwicklung, die Gestaltung, die Herstellung, den Verkauf, die Nutzung oder
anderweitige Verwendung des ZUGFeRD Datenformats für Hardware- und/oder Softwareprodukte sowie sonstige
Anwendungen und Dienste.
Diese Lizenz schließt nicht die wesentlichen Patente der Mitglieder von FeRD ein. Als wesentliche Patente sind Patente
und Patentanmeldungen weltweit zu verstehen, die einen oder mehrere Patentansprüche beinhalten, bei denen es sich um
notwendige Ansprüche handelt. Notwendige Ansprüche sind lediglich jene Ansprüche der Wesentlichen Patente, die durch
die Implementierung des ZUGFeRD Datenformats notwendigerweise verletzt würden.
Der Lizenznehmer ist berechtigt, seinen jeweiligen Konzerngesellschaften ein unbefristetes, weltweites, nicht übertragbares,
unwiderrufliches Nutzungsrecht einschließlich des Rechts der Weiterentwicklung, Weiterbearbeitung und Verbindung mit
anderen Produkten einzuräumen.

Die Lizenz wird kostenfrei zur Verfügung gestellt.

Außer im Falle vorsätzlichen Verschuldens oder grober Fahrlässigkeit haftet FeRD weder für Nutzungsausfall, entgangenen
Gewinn, Datenverlust, Kommunikationsverlust, Einnahmeausfall, Vertragseinbußen, Geschäftsausfall oder für Kosten,
Schäden, Verluste oder Haftpflichten im Zusammenhang mit einer Unterbrechung der Geschäftstätigkeit, noch für konkrete,
beiläufig entstandene, mittelbare Schäden, Straf- oder Folgeschäden und zwar auch dann nicht, wenn die Möglichkeit der
Kosten, Verluste bzw. Schäden hätte normalerweise vorhergesehen werden können.-->
<!--Right of use
ZUGFeRD Data format version 2.1, March 24, 2020

The purpose of the Forum elektronische Rechnung Deutschland (FeRD), which was founded on March 31, 2010 under the
umbrella of Arbeitsgemeinschaft für wirtschaftliche Verwaltung e. V., is, among other things, to create and specify an
open data format for structured electronic data exchange on the basis of open and non discriminatory, standardised
technologies ("ZUGFeRD data format").

The ZUGFeRD data format is used by both companies and public administration according to the FeRD
made freely accessible. For this purpose FeRD offers all companies and organisations of the public administration a
License to use the copyrighted ZUGFeRD data format in a fair, appropriate and non
discriminatory conditions.

The specification of the FeRD for the implementation of the ZUGFeRD data format is, in its currently valid version
available at www.ferd-net.de.

In detail, the grant of use includes
=====================================

FeRD grants a license for the use of the copyrighted ZUGFeRD data format in the respective
valid and accepted version (www.ferd-net.de).
The license includes an irrevocable right of use including the right of further development,
Further processing and connection with other products.
The license applies in particular to the development, design, production, sale, use or
other use of the ZUGFeRD data format for hardware and/or software products and other
applications and services.
This license does not include the essential patents of the members of FeRD. The essential patents are patents
and patent applications worldwide which contain one or more claims that are
necessary claims. Necessary claims are only those claims of the essential patents which are
the implementation of the ZUGFeRD data format would necessarily be violated.
The Licensee is entitled to provide its respective group companies with an unlimited, worldwide, non-transferable,
irrevocable right of use including the right of further development, further processing and connection with
other products.

The license is provided free of charge.

Except in the case of intentional fault or gross negligence, FeRD is not liable for loss of use, loss of
Profit, loss of data, loss of communication, loss of revenue, loss of contracts, loss of business or for costs
damages, losses or liabilities in connection with an interruption of business, nor for concrete,
incidental, indirect, punitive or consequential damages, even if the possibility of
costs, losses or damages could normally have been foreseen.-->
<rsm:CrossIndustryInvoice xmlns:a="urn:un:unece:uncefact:data:standard:QualifiedDataType:100" xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:10" xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100" xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>DAR.3110037431</ram:ID>
    <ram:TypeCode>384</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20240613</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:AssociatedDocumentLineDocument>
        <ram:LineID>1</ram:LineID>
      </ram:AssociatedDocumentLineDocument>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Betonrecycling 0/45</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>870.2000</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="H87">-12.5000</ram:BilledQuantity>
      </ram:SpecifiedLineTradeDelivery>
      <ram:SpecifiedLineTradeSettlement>
        <ram:ApplicableTradeTax>
          <ram:TypeCode>VAT</ram:TypeCode>
          <ram:CategoryCode>S</ram:CategoryCode>
          <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
        </ram:ApplicableTradeTax>
        <ram:SpecifiedTradeSettlementLineMonetarySummation>
          <ram:LineTotalAmount>-10877.50</ram:LineTotalAmount>
        </ram:SpecifiedTradeSettlementLineMonetarySummation>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>
    <ram:ApplicableHeaderTradeAgreement>
      <ram:BuyerReference>419281</ram:BuyerReference>
      <ram:SellerTradeParty>
        <ram:ID>700031</ram:ID>
        <ram:Name>Muster GmbH</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="0002"/>
        </ram:SpecifiedLegalOrganization>
        <ram:DefinedTradeContact>
          <ram:PersonName>Nicolas Igel</ram:PersonName>
          <ram:TelephoneUniversalCommunication>
            <ram:CompleteNumber>0000 000 000 00</ram:CompleteNumber>
          </ram:TelephoneUniversalCommunication>
          <ram:EmailURIUniversalCommunication>
            <ram:URIID>n.igel@domain.de</ram:URIID>
          </ram:EmailURIUniversalCommunication>
        </ram:DefinedTradeContact>
        <ram:PostalTradeAddress>
          <ram:PostcodeCode>01234</ram:PostcodeCode>
          <ram:LineOne>Musterstra&#xDF;e 1a</ram:LineOne>
          <ram:LineThree>Deutschland</ram:LineThree>
          <ram:CityName>Musterhausen</ram:CityName>
          <ram:CountryID>DE</ram:CountryID>
        </ram:PostalTradeAddress>
        <ram:SpecifiedTaxRegistration>
          <ram:ID schemeID="FC">01/234/56789</ram:ID>
        </ram:SpecifiedTaxRegistration>
        <ram:SpecifiedTaxRegistration>
          <ram:ID schemeID="VA">DE123456789</ram:ID>
        </ram:SpecifiedTaxRegistration>
      </ram:SellerTradeParty>
      <ram:BuyerTradeParty>
        <ram:ID>419281</ram:ID>
        <ram:Name>Musterfirma AG</ram:Name>
        <ram:PostalTradeAddress>
          <ram:PostcodeCode>04808</ram:PostcodeCode>
          <ram:LineOne>Schillerstraße 28</ram:LineOne>
          <ram:LineThree>Deutschland</ram:LineThree>
          <ram:CityName>Wurzen</ram:CityName>
          <ram:CountryID>DE</ram:CountryID>
        </ram:PostalTradeAddress>
      </ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>
    <ram:ApplicableHeaderTradeDelivery/>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:SpecifiedTradeSettlementPaymentMeans>
        <ram:TypeCode>30</ram:TypeCode>
        <ram:PayeePartyCreditorFinancialAccount>
          <ram:IBANID>DE89370400440532013000</ram:IBANID>
        </ram:PayeePartyCreditorFinancialAccount>
        <ram:PayeeSpecifiedCreditorFinancialInstitution>
          <ram:BICID>COBADEFFXXX</ram:BICID>
        </ram:PayeeSpecifiedCreditorFinancialInstitution>
      </ram:SpecifiedTradeSettlementPaymentMeans>
      <ram:ApplicableTradeTax>
        <ram:CalculatedAmount>-2066.73</ram:CalculatedAmount>
        <ram:TypeCode>VAT</ram:TypeCode>
        <ram:BasisAmount>-10877.50</ram:BasisAmount>
        <ram:CategoryCode>S</ram:CategoryCode>
        <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
      </ram:ApplicableTradeTax>
      <ram:SpecifiedTradePaymentTerms>
        <ram:Description>rein netto innerhalb 13 Tagen
</ram:Description>
        <ram:DueDateDateTime>
          <udt:DateTimeString format="102">20240626</udt:DateTimeString>
        </ram:DueDateDateTime>
      </ram:SpecifiedTradePaymentTerms>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>-10877.50</ram:LineTotalAmount>
        <ram:ChargeTotalAmount>0.00</ram:ChargeTotalAmount>
        <ram:AllowanceTotalAmount>0.00</ram:AllowanceTotalAmount>
        <ram:TaxBasisTotalAmount>-10877.50</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">-2066.73</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>-12944.23</ram:GrandTotalAmount>
        <ram:TotalPrepaidAmount>0.00</ram:TotalPrepaidAmount>
        <ram:DuePayableAmount>-12944.23</ram:DuePayableAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
      <ram:InvoiceReferencedDocument>
        <ram:IssuerAssignedID>DAR.3110037430</ram:IssuerAssignedID>
      </ram:InvoiceReferencedDocument>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Bei der Steuer käme eig. -2066,725 € heraus, also genau besagter Fall.

Falls Ihnen die IBAN echt vorkommt, das ist Sie nicht, dass ist lediglich eine bei ChatGPT erfragte IBAN, die nicht echt, aber formal trotzdem korrekt ist. Ansonsten sind auch alle Namen und Adressen verändert.

[jstaerk]

https://awv-git.de/einvoicing/factur-x/-/issues/150

[mtlmarko89]

Guten Tag,
mir wurde vom Kunden gesagt, dass ich die ZUGFeRD-Versionsangaben für Version 2.2 verwenden soll, da die Validatoren dann alle die Steuer kaufmännisch runden. Ist da zufällig etwas Wahres dran?

Bei AWV-Git habe ich es bisher leider noch nicht geschafft, mich zu registrieren und die Github-Zugänge scheinen dort nicht zu greifen (meine Angaben werden jedenfalls verweigert), daher konnte ich bisher noch nicht das zuletzt genannte Ticket verfolgen, falls dort schon was drin steht, dass es mit der 2.2 behoben wäre.

[jstaerk]

Hallo

mir wurde vom Kunden gesagt, dass ich die ZUGFeRD-Versionsangaben für Version 2.2 verwenden soll, da die Validatoren dann
alle die Steuer kaufmännisch runden. Ist da zufällig etwas Wahres dran?
Nein

Bei AWV-Git habe ich es bisher leider noch nicht geschafft, mich zu registrieren und die Github-Zugänge scheinen dort nicht zu
greifen (meine Angaben werden jedenfalls verweigert), daher konnte ich bisher noch nicht das zuletzt genannte Ticket verfolgen,
falls dort schon was drin steht, dass es mit der 2.2 behoben wäre.

Es gibt einige (unter anderem ich) die vehement für eine Öffnung des AWV-Git stimmen aber Stand jetzt ist Zugang nur für Mitglieder und ehrenamtlich Beitragende zum Standard. Möchten Sie bei der Entwicklung mithelfen? Ich kann das vielleicht weiterleiten, der Arbeitsaufwand hält sich in Grenzen, in der Regel 2h Telko pro Monat.

Und ZUGFeRD 2.3 wird ein großartiges Release aber bezüglich 150 hat sich nichts getan.

ciao
Jochen