ebInterface 4.1 - OtherVATableTax

    • ebInterface 4.1 - OtherVATableTax

      Hallo!

      Bei der Definition der OtherVATableTax in ebInterface 4.1 sind Unklarheiten aufgetaucht die gelöst werden müssen.
      * Einerseits gibt es Steuern, die sich nicht prozentual berechnen, sondern auf einer anderen Basis (zB Biersteuer auf Basis der Stammwürze). Daher muss ein "Percentage"-Element jedenfalls optional sein.

      * Es gibt Fälle, in denen eine zusätzliche Steuer mit anderen Aufschlägen oder Rabatten kombiniert werden kann (zB Biersteuer), wobei Auf- und Abschläge vor oder nach der sonstigen Steuer definiert werden.

      * Die Definition von OtherVATableTax befindet sich derzeit nur auf globaler Ebene und nicht auf Zeilenebene. Daraus ergeben sich folgende Interpretationsmöglichkeiten:
      1. Der TaxAmount der OtherVATableTax wird zur TaxedAmount der VAT addiert. Dadurch stimmt die bisherige "Formel" (Summe der LineItemAmounts +- Summe der Auf-/Abschläge + Steuer = TotalGrossAmount) nicht mehr. Außerdem würde das bedeuten, dass die Werte auf Zeilenebene nicht angeführt werden dürfen (im LineItemAmount), da sie sonst doppelt berechnet werden könnten. Dadurch geht der Bezug von OtherVATableTax zur Rechnungsposition verloren. Bei auszeichnungspflichtigen Steuern eine suboptimale Lösung.
      2. OtherVATableTax wird nur als Zusammenfassung dargestellt, hat aber keinen Einfluss auf die Berechnung, da sie bereits im LineItemAmount enthalten ist. Dadurch wäre ebenfalls oben genannte Formel verletzt, da OtherVATableTax keinen Einfluss auf die Berechnung mehr hat.

      Pseudocode zu 1.
      <ListLineItem>
      <Quantity>5</Quantity>
      <UnitNetPrice>10</UnitNetPrice>
      <TaxRate>20</TaxRate>
      <LineItemAmount>50</LineItemAmount>
      </ListLineItem>
      ...
      <Tax>
      <OtherVATableTax>
      <TaxedAmount>50</TaxedAmount>
      <TaxAmount>4</TaxAmount>
      <TaxRate>20</TaxRate>
      <Comment>Biersteuer von 4 EURO</Comment>
      </OtherVATableTax>
      <VAT>
      <VATItem>
      <TaxedAmount>54</TaxedAmount>
      <TaxRate>20</TaxRate>
      <TaxAmount>10.8</TaxAmount>
      </VATItem>
      </VAT>
      </Tax>


      Pseudocode zu 2.
      <ListLineItem>
      <Quantity>5</Quantity>
      <UnitNetPrice>10</UnitNetPrice>
      <TaxRate>20</TaxRate>
      <SurchargeListLineItem>
      <Amount>4</Amount>
      <Comment>Biersteuer von 4 EURO</Comment>
      </SurchargeListLineItem>
      <LineItemAmount>54</LineItemAmount>
      </ListLineItem>
      ...
      <Tax>
      <VAT>
      <VATItem>
      <TaxedAmount>54</TaxedAmount>
      <TaxRate>20</TaxRate>
      <TaxAmount>10.8</TaxAmount>
      </VATItem>
      </VAT>
      </Tax>


      Das Problem mit Variante 1 ist, dass die Informationen auf Zeilenebene verloren gehen
      Das Problem mit Variante 2 ist, dass die Summe der Informationen verloren geht, da die Surcharges nicht "typisiert" sind. Außerdem können so keine auszeichnungspflichtigen Steuern gekennzeichnet werden.

      Der Lösungsvorschlag zu diesem Problem sieht wie folgt aus:
      a) Auf ListLineItem-Ebene wird die Reduction/Surcharge-Choice um ein "OtherVATableTaxListLineItem"-Element erweitert. Dieses könnte wie folgt definiert sein:
      <xs:complexType name="OtherVATableTaxBaseType">
      <xs:sequence>
      <xs:element ref="BaseAmount"/>
      <xs:element ref="Percentage" minOccurs="0"/>
      <xs:element ref="Amount" />
      <xs:element name="TaxID" type="IDType"/>
      <xs:element ref="Comment" minOccurs="0"/>
      </xs:sequence>
      </xs:complexType>

      BaseAmount, Percentage, Amount und Comment haben die selbe Semantik wie bei Reduction/Surcharge. Das Element TaxID definiert die Art der Steuer. Dabei muss in einer Rechnung immer der selbe Terminus für die selbe Steuerart verwendet werden (zB "WA" für Werbeabgabe oder "BS" für Biersteuer).
      Damit wären Steuern separat gekennzeichnet, in der Berechnung hätten Sie die Semantik einer Surcharge (Addition), und über die TaxID könnten Sie aggregiert werden. Außerdem können Sie durch die Einbindung in die Choice beliebig mit anderen Aufschlägen und Rabatten kombiniert werden.
      b) auf ROOT-Ebene gibt es ebenfalls ein OtherVATableTax-Element mit der selben Semantik wie Reduction/Surcharge um sonstige Steuern die sich auf die gesamte Rechnung beziehen, abbilden zu können. Auch hierfür wird ein zusätzliche TaxRate-Element benötigt, damit die Steuer einem USt-Satz zugeordnet werden kann.
      <xs:complexType name="OtherVATableTaxType">
      <xs:complexContent>
      <xs:extension base="OtherVATableTaxBaseType">
      <xs:sequence>
      <xs:element ref="TaxRate"/>
      </xs:sequence>
      </xs:extension>
      </xs:complexContent>
      </xs:complexType>

      Wenn eine sonstige Steuer schon auf ListLineIteme-Ebene angegeben ist, dann muss sie nicht mehr auf ROOT-Ebene angegeben werden.
      c) der OtherVATableTax-Teil fliegt aus dem Tax-Element raus. Es gibt keine expliziten Summenangabe der sonstigen Steuern.

      Da somit eine verstärkte Verwendung des Wortes "Tax" vorkommt, würde sich damit auch eine Umbenennung des Elements "TaxRate" in "VATRate" anbieten, um klarzustellen, das es sich nicht um eine "Steuer" sondern um die "Umsatzsteuer" handelt.

      vg P. Helger