Posts by blaschma

    Wo finde ich die Definition von

    <xs:element ref="AddressExtension" minOccurs="0" maxOccurs="unbounded"/>

    ?

    Wird in <xs:complexType name="AddressType"> verwendet.

    Ansonsten wird <xs:element ref="Extension" minOccurs="0"/> verwendet.

    Für die Diskussion zur Anzahl der benötigten Nachkommastellen beim Umrechnungskurs, habe ich die Heute im Amtsblatt der EU veröffentlichte EZB-Kurstabelle angehängt.

    In den meisten Fällen reichen 6 signifikante Stellen.
    Allerdings wird nicht auf EUR umgerechnet, sondern von EUR weg gerechnet.
    Für die geplante Umsetzung in ebInterface wäre daher von den angegebenen Kursen zuerst der Kehrwert zu bilden.

    Würde es dann nicht Sinn machen, dieses Element als complex zu definieren.

    Beispielsweise so:

    <PayableNonEuroAmount>
    <Currency>USD</Currency>
    <ForeignPayableAmount>123.45</ForeignPayableAmount>
    </PayableNonEurAmount>


    Wobei Currency eine aus der ISO 4217 Liste zu sein hat.

    ForeignPayableAmount ist der EUR-PayableAmount in "Currency" ausgedrückt.


    Der Umrechnungskurs würde sich dann aus PayableAmount und ForeingPayableAmount berechnen lassen, und bräuchte nicht extra angegeben werden.

    Grundsätzlich würde dieses Element in den Fällen sinnvoll sein, wenn in ein EU-Land abgerechnet wird, das nicht im SEPA Mitglied ist (z.B: HU, CZ).

    LG
    Martin Blaschka

    Hallo Zusammen,

    bis einen Punkt bin ich damit einverstanden.

    -) In der Doku wird an mehreren Stellen "AddressIdentifierTypeType" verwendet. Im XSD gibt es aber nur "AddressIdentifierType".
    Zum Attribut "AddressIdentifierType" wird in der Doku auf die ISO 6523 verwiesen. Diese scheint aber "nur" ein abstraktes Sammelbecken für organisationsspezifische Adressierungscode-Spezifikationen zu sein. Einzig "GLN" dürfte für die Anwendung in AT relevant sein.

    Sollte dieser Aspekt nochmal diskutiert werden?

    LG
    Martin Blaschka

    Hallo Zusammen,

    mir ist bei dieser Version (erstmalig :( ) aufgefallen, daß das InvoiceType Attribut "GeneratingSystem" verpflichtend ist.

    Hat das einen bestimmten Grund?
    Braucht das jemand (zwingend) für interne Verarbeitungen?
    Würde es reichen dieses Attribut auf Optional zu ändern, und eine verpflichtende Übergabe bilateralen Übereinkünften zu überlassen?

    Daß die Attribute "DocumentType" und "InvoiceCurrency" verpflichtend sein müssen, steht für mich außer Zweifel.


    Danke

    Martin Blaschka

    Hallo Zusammen,

    im Element ContactType wurde die Mail-Adresse auf maxOccurs="unbound" geändert.
    Das Element Phone darf aber nur einmal vorkommen.
    Konsequenterweise wäre auch hier maxOccurs="unbound" zu ergänzen - für diejenigen, die gerne (z.B.) Festnetz und Mobil Nummern eintragen wollen.

    Außer es spricht etwas dagegen.

    LG
    Martin Blaschka

    Hallo Zusammen,

    auf ROOT-Ebene gibt es im Element Tax das Element OtherTax.
    Lt. Doku sollen damit "andere" Steuern abgebildet werden, die nicht das USt.pflichtige Entgelt erhöhen.
    Wird dieses Feld für irgendetwas verwendet?
    Wenn Nein, könnten wir es entfernen.

    Das Element OtherVATTableTax in ReductionAndSurchchargeDetails soll jene Abgaben und Steuern abbilden, die USt. pflichtig sind.
    OtherVATTableTax selbst bietet aber keine Möglichkeit anzugeben, worauf sich diese Abgabe/Steuer bezieht.
    Dies wäre besser im Element Surcharge abzubilden, da hier die "Basiseinheit" referenziert werden kann.
    Wenn es keine Einwände gibt, könnte das Feld OtherVATTableTax entfernt werden.


    Im Zusammenhang mit der Redefinition des jetzigen Elementes VATItem sollte damit eb-Interface noch ein Stück besser werden.


    mit gesten Grüßen

    Martin Blaschka

    Hallo zusammen,

    vom UBIT Fachverbandsbüro wurde eine Information ausgesandt, daß die EU-Kommission fest entschlossen ist - unter dem "Deckmantel" der Betrugsbekämpfung - auch die ig-Lieferung dem MOSS-Regime zu unterstellen.

    Aktuell sind ig-Lieferungen (echt) Steuerbefreit. De lege feranda soll es zur Steuerpflicht im empfangenden Mitgliedstaat kommen.
    MOSS soll eine "Verwaltungsvereinfachung" sein, da die Meldung und Abfuhr der USt im Land des Rechnungslegers erfolgt - allerdings wird der Rechnungsleger dabei gewzungen, die nationale Umsetzung der EU-MwStSystRL des Empfängerlandes zu kennen, um die Rechnung richtig fakturieren zu können.
    Tendenziell soll die Steuerpflicht im Mitgliedstaat des Leistungsempfänger zur B2B-Generalklausel werden... :(

    Ich würde gerne sicherstellen, daß die V5.0 auch für solche "Blödheiten" gewappnet ist, und daß deswegen ein allfälliges Mapping auf andere Formate NICHT scheitert.

    Any Comments?

    Danke
    Martin Blaschka

    Nur zur Klarstellung: TaxExemption steht nicht nur für die unecht steuerbefreiten Umsätze des § 6 Abs. 1 UStG. Es kann auch ig-Lieferung, Reverse-Charge oder ein Dreiecksgeschäft sein.
    BTW1: wie wird die Differenzbesteuerung (Margenbesteuerung bei Reisevorleistungen bzw. die Differenzbesteuerung beim "Antiquitätenhandel") der §§ 23 f UStG dargestellt.
    BTW2: wie werden die Sonderfälle MOSS und Überschreiten der Lieferschwelle dargestellt? In beiden Fällen kommt es zur Verlagerung der USt.Pflicht in den Mitgliedstaat des Leistungsempfängers.

    BelowTheLine sollten die NICHT steuerbaren Umsätze (gem. Legaldefinition des § 1 UStG) sein.
    Dazu gehören speziell Gebühren und Abgaben die (u.a.) für hoheitliches Handeln oder von Kommunen für deren "Dienstleistungen" erhoben werden.

    Bei Notaren sehe ich immer wieder folgende Rechnungsaufstellung:
    Errichtung des GmbH Ges.Vertr.
    + Unterschriftenbeglaubigungen
    + Barauslagen
    = Netto
    + 20% USt
    = Brutto
    + Gerichtsgebühren (diese werden 1:1 als Durchläufer weitergereicht und sind daher nicht steuerbar)
    = Zahlbetrag

    Bei einem Bestatter tritt an die Stelle der Gerichtsgebühren die Gebühren die von der Kommune erhoben werden.
    Bei der Hotellerie könnte an dieser Stelle die Ortstaxe stehen - auch diese wird von der Kommune vorgeschrieben.

    In Frage kommen natürlich auch die bereits erwähnten Vorauszahlungen / Anzahlungen / Restschuld von vorangegangenen Rechnungen / ....
    (Aufgrund der EU-DurchführungsV bez. Gutscheinen könnten diese eventuell einer genaueren Beleuchtung bei der Rechnungslegung bedürfen.)

    Anders verhält es sich mit dem Wiener Sportgroschen oder der Wiener Lustbarkeitsabgabe.
    Beide sind im jeweiligen LGBl als USt. pflichtiger Zuschlag zum Netto-Entgelt vorgeschrieben.
    Ebenso die 5% Werbeabgabe oder die vielen anderen "Sondersteuern" (z.B: Mineralölsteuer, Alkoholsteuer, Verbrauchsteuer, Schaumweinsteuer, Biersteuer, Tabaksteuer, ...) die auf Bundesebene eingehoben werden und das USt.pflichtige Entgelt erhöhen.

    Soweit Unklar?

    Sehr geehrte Damen und Herren,

    wie in der letzten AK-Sitzung besprochen, stellen wir hiermit die Business Terms von EN 16931-1 zur Diskussion. (Rechtsklick auf den Link und dann "Speichern unter" wählen)

    https://github.com/austriapro/ebi…terface5p0.xlsx

    Welche der gelb markierten Business Terms sollen aus Ihrer Sicht Teil von ebInterface 5.0 werden? Bitte posten Sie Ihre Anmerkungen als Antworten auf diesen Thread. In der nächsten AK-Sitzung im Herbst werden die konsolidierten Ergebnisse präsentiert.

    Philipp Liegl

    BT-113 (Prepaid Amount) macht als optionales Element durchaus Sinn - speziell bei Vorauskasse.
    BT-122 bis BT-125 könnten als optionale Elemente sinnvoll sein, da das UStG das Referenzieren anderer Dokumente erlaubt, die die erbrachte Leistung beschreiben.
    Die anderen Punkte haben wir entweder bereits (anders) abgebildet bzw. sehe ich dafür keine Notwendigkeit im ebInterafce.

    Hallo zusammen,

    nachdem ich es endlich schaffe Rechnungen im 4.3 Format zu erstellen und diese auch positiv geprüft werden, scheitere ich nun an der digitalen Signatur.

    Lt. UStG ersetzt die DSig den verläßlichen Prüfpfad für die Anerkennung des Vorsteuerabzuges beim Empfänger.

    Da meine ebInterface-generierende Software allerdings das Signatuer Objekt nicht eingebettet erzeugen kann, kann das XML durch eine "angehängte" Signatur nicht mehr verifiziert werden.

    Soll dafür eine Option geschaffen werden, oder bin ich damit alleine auf weiter Flur?

    Danke - von einem Neuling in diesem Forum
    Martin Blaschka