Deterministische Preisberechnungen auf allen Ebenen

    • Deterministische Preisberechnungen auf allen Ebenen

      Sowohl für jede Rechnungszeile als auch für den Gesamtbetrag sollten eindeutige Rechenregeln definiert werden, da diese in der Praxis unterschiedlich interpretiert werden. D.h. pro Rechnungszeile sollte definiert werden, wie der LineItemAmount zustande kommt, und auf globaler Ebene sollte definiert werden, wie der TotalGrossAmount zustande kommt. Diese Regeln sollten sowohl für ebInterface 3.0.x als auch für ebInterface 4.0 definiert werden.

      In den Regeln berücksichtigt ist ein optionales Feld “BaseAmount” mit dem Standardwert “1”. Dieses kann verwendet werden, wenn Elemente in bestimmten Verpackungseinheiten (z.B: 1000) verkauft werden. Dadurch kann verhindert werden, dass sich der Einzelpreis nicht mehr mit 4 Dezimalstellen ausdrücken lässt.

      Vorschläge seitens des BRZs, die aber noch auf das steuerrechtliche Approval vom BMF warten:
      LineItemAmount:
      • UnitNetAmount / BaseAmount * Amount +- (Reduction/Surcharge in der angegebenen Reihenfolge)
      • Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden

      LineItemGrossAmount:
      • Ungerundeter LineItemAmount * (100 + TaxRate) / 100
      • Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden

      TotalRoundingAmount:
      • Summe(ungerundeter LineItemGrossAmount) - Summe(gerundeter LineItemGrossAmount)
      • Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden

      TotalGrossAmount:
      • Summe(gerundeter LineItemGrossAmount) +- (Reduction/Surcharge in der angegebenen Reihenfolge) + TotalRoundingAmount
      • Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden

      Das bedingt, dass es auf globaler Ebene ein neues Element "TotalRoundingAmount" geben muss, in dem optional Rundungsdifferenzen abgelegt werden können.
      Außerdem wäre in diesem Zusammenhang ein Element "LineItemGrossAmount" auf Zeilenebene hilfreich.

      Zusätzlich sollte es eine Definition des zu verwendenden Rundungsmodus werden, aber auch hier sollte eine Aussage vom BMF kommen.
      Der Bund verwendet derzeit den Modus „HALF_UP“ der bei uns wie folgt definiert ist:
      • Rounding mode to round towards "nearest neighbor" unless both neighbors are equidistant, in which case round up. Behaves as for RoundingMode.UP if the discarded fraction is >= 0.5; otherwise, behaves as for RoundingMode.DOWN. Note that this is the rounding mode commonly taught at school.
      International üblich ist der Rundungsmodus “HALF_EVEN”:
      • Rounding mode to round towards the "nearest neighbor" unless both neighbors are equidistant, in which case, round towards the even neighbor. Behaves as for RoundingMode.HALF_UP if the digit to the left of the discarded fraction is odd; behaves as for RoundingMode.HALF_DOWN if it's even. Note that this is the rounding mode that statistically minimizes cumulative error when applied repeatedly over a sequence of calculations. It is sometimes known as "Banker's rounding," and is chiefly used in the USA. This rounding mode is analogous to the rounding policy used for float and double arithmetic in Java.


      Update 16:58: Folgende Infos habe ich auf BMF-Seiten gefunden:
      Quelle: findok.bmf.gv.at/findok/freie_suche.do mit dem Suchwort „rundung“ und der betroffenen Norm „§ 11 ustg“

      11.1.5.6.4. Auf- und Abrundung
      1516
      Über die Auf- oder Abrundung der USt bei der Rechnungserteilung enthält das Steuerrecht keine besonderen Vorschriften. Die USt muss daher vom Unternehmer für die von ihm ausgeführten steuerpflichtigen Leistungen genau berechnet werden. Soweit in einer Rechnung der Steuerbetrag oder der Rechnungsendbetrag (der zivilrechtliche Preis) auf- oder abgerundet wurde, hat dies für die Höhe der Steuerschuld keine Bedeutung bzw. ist § 11 Abs. 12 UStG 1994 sinngemäß anzuwenden.
      Siehe auch EURO-Einführungserlass, AÖF Nr. 019/1999.

      Update 12.8.2013: nach Auskunft des BMF soll immer kaufmännisch gerundet werden, also nach dem "HALF_UP" Modus!

      vg P. Helger
    • Laut diesem Forum-Beitrag aus 2011 wurden diese Regeln ganz bewusst nicht in den Standard übernommen:
      Rundung in ebInterface 4.0 .

      Ich sehe das genauso wie Prof. Huemer: Eine Spezifizierung dieser Themen wäre eine implizite Vorgabe an die interne Verarbeitungslogik von ERP- und Billing-Systemen. Das ist sehr problematisch.

      Für die Firmen, die ich in Sachen e-Rechnung berate, ist es nicht möglich die interne Rechenlogik der ERP- und Billing-Systeme nur wegen der e-Rechnung umzustellen. Solange gesetzliche Vorgaben erfüllt werden, gibt es meiner Ansicht nach keine Erfordernis hier zusätzliche Regeln festzulegen.


      Mit freundlichen Grüßen,
      P. Gerstbach
    • Hallo !

      Zum Punkt Rundung gebe ich Herrn Gerstbach vollinhaltlich recht.

      Jedoch ist es dringend erforderlich, dass es so rasch als möglich eine abgestimmte Rechenregel für die Berechnung des LineItemAmount gibt.

      Derzeit wird vom Bund der TAG für die Reduction/Surcharge nicht verwendet. (http://www.ebinterface.org/forum/index.php?page=Thread&threadID=105)
      -> Das bedeutet, dass der UnitPrice inklusive aller Zu- und Abschläge dargestellt werden muss.
      (SAP: Also NettoPositionspreis / Stück … bei Konditionen, die auf Grund der niedrigen Höhe, auf Basis 1000 Stück berechnet sind, auf 4 Nachkommastellen genau … auch diese Darstellung muss im SAP eigens neu programmiert werden).
      Der TAG Reduction/Surcharge gilt derzeit somit „nur“ als Information zur genaueren Darstellung des Preisgefüges – also als „Davonpositionen“ zum Einzelpreis x Stück.

      Bei einer Änderung dieser Berechnung, muss aus dem UnitPrice wieder der Zu-/Abschlag herausgerechnet werden.

      Bitte hier um Info, wie die weitere geplante Vorgehensweise seitens des Bunds, auch zeitlich, aussieht.

      Mit freundlichen Grüßen
      Gerald Ehart
    • Ich glaube nicht, dass buchhalterische Rechnungs- und Rundungsregeln ein Thema ist, dass ich erst auf der Ebene der Rechnung lösen kann. Das ist klassischerweise ein Thema von AGBs und Handelsbräuchen. Diese stehen schon vor Vertragsschluss allgemein fest und ich kann sie nicht im nachhinein auf der Ebene der Rechnung ändern. Eventuell ergibt sich da auch etwas durch das Zahlungsverzugsgesetz (portal.wko.at/wk/format_detail…gid=1&stid=720075&dstid=0).
      Ich bin SEHR zurückhaltend, diese inhaltlichen Fragen technisch zu lösen....
      Aber wenn der Bund diesbezüglich mit AGBS herauskommt, wär das sicher interessant und könnte zu einer Erweiterung der Bundes-Schematron-Regeln führen.

      freundliche Grüsse
      Gerhard Laga
    • Hallo

      Sinngemäß wir das BRZ meine ich, dass "definierte/standardisierte/besprochene/...." Rechenrechenregel keine schlechte Sache sind.
      Es gibt immer öfter Problem mit 1 Cent Rechenfehler bei Übernahmen von Shopsystemen meiner Kunden die daher rühren, da einmal gerundete Zeilensummen und einmal ungerundete Zeilensummen zur Errechnung der Gesamtsumme verwendet werden.

      LineItemGrossAmount:

      Ungerundeter LineItemAmount * (100 + TaxRate) / 100
      Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden
      Warum wird hier runden? Was ist der tiefer Zweck?
      mMn sollte aus ungerundeten Zeilensummen die Gesamtsumme und erst davon dann die USt errechnet werden.

      Am besten wäre das BMF erklärt anhand definierte Beispiele.

      sG

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von woax ()

    • <PricePerUnit>

      Überlegung zum Preis pro Einheit

      Beispiel:

      <eb:Quantity eb:Unit="ST">5000.000</eb:Quantity>
      <eb:UnitPrice>0.0597</eb:UnitPrice>

      Der UnitPrice ist im Grunde 5,97 pro 100 Einheiten.







      Ein neuer Tag <eb:PricePerUnit> würde evtl. Rundungsprobleme bei hohen Stückzahlen lösen.

      5.000 / 100 * 5.97 = ...

      <eb:Quantity eb:Unit="ST">5000.000</eb:Quantity>
      <eb:UnitPrice>5.97</eb:UnitPrice>
      <eb:PricePerUnit>100</eb:PricePerUnit>


      Wenn <eb:PricePerUnit> nicht mitgegeben wird oder leer ist, gilt automatisch Wert "1".

      Fg Jan
    • mMn liegt das Problem, dass die Preise nur 4 stellen haben können und netto sein müssen.

      Deswegen können Produkte die z.B. 100,- Brutto kosten nicht ordentlich fakturiert werden, da es unweigerlich zu Rundungsfehlern kommt. Siehe Anlagen.
      z.B. 100,- € Brutto gehen, 2x 100,- € Brutto

      Lösungsansätze:

      1) Aus Unitprice ein ganz normales xs:decimal machen. Das ist auch genau der Datentyp der für kaufmännische Preise vorgesehen ist. Es hätte sich dann auch das obige Problem gelöst.
      2) Kennzeichen ob der Preis brutto oder netto angeben ist. Optional boolean PriceIsGrossAmount oder PriceIsNetAmount

      sG

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von woax ()