Innergemeinschaftliche Lieferung - falsches Buchungskonto

    Ich habe gerade das Feedback meines Steuerberaters, zu ersten mit OpenXE erstellten Monatsabrechnung (Buchhaltungs-Export), erhalten. Offensichtlich gibt es ein kleines Problem mit den darin erzeugten Datensätzen im Bezug auf Belege für EU-Lieferungen die z.B. als "innergemeinschaftliche Lieferung" ausgeführt wurden....also auch ohne die Berechnung von MwSt..

    Anstatt solche Belege bzw. deren Produkte auf die hinterlegte Kontonummern für "Innergemeinschaftlich EU" zu buchen, wurden die Produkte auf die Kontonummer für "EU (normal)" gebucht.

    Unser Januar-Export hat das Problem nicht, habe gerade mal nachgeschaut, das Konto ist in den Firmendaten eingetragen. In der Rechung ist ausgewählt: EU-Lieferung / Lieferschwelle, UST ID ist eingetragen.


    Kontrolliere mal bitte diese Einstellungen, es kann sein dass ohne USTID die Mehrwertsteuer ausgewiesen wird, das ist aber meines Wissens nach steuerlich korrekt.

    Hmmmm...das steht bei mir in der Rechnung genauso drin. Der Beleg ist ja auch völlig korrekt, inkl. Ust.-ID des Kunden und dem Hinweis auf Innergem. Lieferung.,erstellt worden.

    Ich habe gerade noch einmal die Exportdatei kontrolliert. Bei mir steht bei dem entsprechenden Datensatz in der Spalte "EU-Steuersatz (Bestimmung)" 19 eingetragen. Hat dort nicht eine "19" eigentlich nichts zu suchen?

    Damit wir uns nicht falsch verstehen:

    Die Buchungskonten sind bei mir nicht in den Firmendaten eingetragen sondern in jedem Artikel...siehe Beispiel nachfolgend:

    Bei einem Verkauf dieses Produkt in Deutschland müsste auf "4401" gebucht werden, bei einem Verkauf ins europäische Ausland mit MwSt. auf "4315" und bei einem Verkauf ins europäische Ausland mit USt-ID und netto auf "4125" (innergemeinschaftlicher Lieferung).


    Der von mir geschilderte Fall ist ein Verkauf ins europäische Ausland mit USt-ID und netto...also eine innergemeinschaftliche Lieferung. Gebucht wurde der Beleg aber auf "4315" anstatt auf "4125".

    Ich habe den Fall jetzt nachgestellt und es kommt das Konto korrekt aus dem Artikel. Warum das bei Dir nicht stimmt müsste man genauer untersuchen. Kannst Du mal nachsehen ob auf Projektebene etwas hinterlegt ist? Gggf. müsste man die Funktion "GetArtikelSteuer" sonst mal mit Deinen Einstellungen debuggen...


    Den Code zur Ermittlung des korrekten Steuersatzes zu verstehen übersteigt meine Fähigkeiten <X

    Es stimmt übrigens, der Steuersatz in % wird immer wie Inland ausgegeben, das ist nicht korrekt, wird aber meines Wissens von Datev auch nicht ausgewertet...

    Das ist ja wirklich wie verhext. Ich habe im Januar genau 3 Belege für Österrreich. 1x mit MwSt. und 2x innergem.Lieferung. Der Beleg mit MwSt. ist korrekt auf "4315" und die beiden anderen Belege ohne MwSt. sind aber ebenfalls auf "4315" gebucht worden.


    Die Einstellungen der Buchungskonto in den Projekteinstellungen, entsprechen denen in den Artikeln. Ich habe sie aber trotzdem in den Projekteinstellungen eben mal gelöscht - es ändert sich dadurch aber nichts. Auch sind mir werder in den Kundeneinstellungen noch in den Belegen selber irgendwelche Einstellungen aufgefallen. Zumal auch an den Einstellungen nichts verändert wurde und das Problem zuvor in Xentral nicht aufgetreten ist.


    Ich habe eben sogar noch kontrolliert, ob die "4315" (EU inkl.MwSt.) und "4125" (EU ohne MwSt.) in der Datenbank in den richtigen Spalten stehen. Da aber mein einer EU-Beleg mit MwSt. ja korrekt gebucht wurde, kann das sowie nicht sein.

    Tja - was ist wohl der Trigger für die korrekte Auswahl des Buchungskontos?? Das kann ja eigentlich nur die Angabe der Ust.-ID im Vorgang sein. Meine drei Vorgänge sind alles Bestellungen, die ich aus meinem Shop importiert habe. Das heisst, dass auch dort die Prüfung der Gültigkeit der Ust-ID stattgefunden hat und nicht in OpenXE. Daher habe ich eben auch noch einmal die Überprüfung in OpenXE für den einen Kunden vorgenommen - ohne Veränderung im Ergebnis.

    Egal was ich eben noch so alles in den Einstellungen zum Testen geändert habe - es verändert nichts an dem Ergebnis in der Export-Buchungsdatei....außer wenn ich die Nummer des Kontos verändere X(

    Ich denke da muss ich mal Schritt für Schritt die einzelnen Funktionen mit Debug durchprüfen. Kannst Du mir nochmal so einen Datenbankabzug erstellen wie letztes Jahr, aber mit Daten die das Fehlverhalten zeigen? Dann ziehe ich mir das ins Testsystem und kann dann wahrscheinlich herausfinden an welcher Stelle das Konto falsch gezogen wird.

    Das wird datenschutztechnisch nicht ganz so einfach werden, Dir einen entsprechenden Auszug zu erstellen. Mal sehen, ob und wie ich das bewerkstellig bekomme, dass Du mit den Daten im Anschluß noch etwas anfangen kannst.


    Ich habe eben gerade auch noch einmal ausprobiert was passiert, wenn ich im Rechnungsbeleg die "Besteuerung" von "EU Lieferung / Lieferschwelle" auf Inland oder Export ändere. Dann ändern sich auch die Buchnungskonten korrekt in der Export-Datei. Wenn ich dann wieder zurück auf "EU Lieferung / Lieferschwelle" stelle, wird auch wieder das falsche EU-Konto ausgegeben.


    Ich denke noch mal laut:
    Irgendwo im System muss doch eine Funktion existieren die steuert was passiert, wenn die Besteuerrung im Beleg auf "EU Lieferung / Lieferschwelle" steht und eine Ust-ID eingetragen ist. Vielleicht gibt es in der Funktion ja Abweichungen im Handling oder den Bezeichnung zu Xentral!?

    Die Kategorien hatte ich tatsächlich nict mehr auf dem Zettel. Aber das eine Produkt war nicht einmal einer Kategorie zugeordnet und bei dem anderen Produkt stimmte die Zuordnung der Buchungskonten auch in der Kategorie. Ich würde ja aber auch denken, dass die höchste Priorität der Eintrag im Artikel sein dürfte. Aber wie gesagt: alle anderen Quellen wurden von mir eben noch einmal gecheckt und die sind korrekt

    Wo finde ich das Feld "ust_befreit" - im Auftrag oder in der Rechnung?


    So steht es bei mir im Auftrag:



    und so in der Rechnung:



    Meintest Du das?

  • Alex

    Hat das Label Erledigt hinzugefügt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden