DATEV Schnittstelle liefert seit Update MwSt. falsche Beträge bei Rechnungen mit Positionsnachlässen

Hallo KonntecMG,

sofort als Gladbacher identifiziert .....

Ich habe mich hier gerade noch einmal tiefer eingelesen, nachdem ich zunächst das Problem nicht richtig verstanden habe. Jetzt sehe ich, das es sich bei eurem Problem auch um mein Problem aus diesem Eintrag handelt:

Wieder MWSt. / diesmal unerklärliche Wertabweichungen in den Auswertungen

Bisher war mir nicht klar, woher meine "Phantasienettosumme" kommt, aber ich habe nachgerechnet und der Wert entspricht dem Netto Rechnungswert ohne Rabattabzug.

Der MWSt. Betrag stimmt nun auch zu diesem falschen Netto Wert, seltsamerweise protestiert MB aber nicht, wenn der Kunde die richtige (niedrigere) Rechnungssumme überweist, sondern verbucht als vollständig bezahlt (ohne Skontoabzug) und agiert dann im Journal mit den nicht zueinander passenden Werten.

Rechnung, Gutschrift, neue Korrekturrechnung 2010382, alles stimmig!

Journal, Rechnung 2010382 mit dem abweichenden, falschen Nettowert und dazu passender MWSt. 16%

Journal, Zahlung zu Rechnung 2010382, hier kombiniert mit dem richtigen Brutto aus der Rechnung

bei mir läuft auch schon eine Supportanfrage, die erste Antwort waren ausschließlich die bekannten Standardlinks, hat nicht geholfen.
Weiß vielleicht jemand von den Erfahreneren hier (SAMM?) ob es eine Möglichkeit gibt Anfragen für ein gleichartiges Problem irgendwie bei Buhl zu bündeln? Oder kann mal jemanden vom Support hierauf stoßen .....

Jedenfalls viele Grüße an die Mit-Mönchengladbacher von Wohnen+Ideen auf der Lindenstraße

Peter

Guten Morgen,

mir ist das Problem auch nur durch den Zufall aufgefallen, dass mein Büro die Berechnung aus mehreren Lieferscheinen fälschlicherweise mit 19% Mehrwertsteuer abgerechnet hat obwohl alle Lieferscheine aus dem Juli stammten.

Die übliche Nachfrage durch mein Büro nachdem richtigen Mehrwertsteuersatz wurde nicht gestellt daraufhin habe ich sofort eine Korrekturrechnung erstellt, die ja automatisch Gutschrift und neue Rechnung vorbereitet und aufgrund dieser Problematik habe ich mir das Buchungsjournal angesehen.

Wobei die Differenz auffiel.

Ich habe dann eine Zeit gebraucht um in eurem Problem denselben Hintergrund zu erkennen, der auch bei mir vorliegt.

Die Frage ist halt wie kann man der Firma Buhl klar machen kann, dass es sich ja hier um ein reelles Problem bzw. einen Bug im Programm handelt und nicht um irgendeine Fehlbedienung eines Einzelnen.

Ebenfalls wundere ich mich, dass keine weiteren Rückmeldungen hier zu erscheinen. Vielleicht fällt diese Problematik halt nicht direkt ins Auge.

Zumindest wenn man eine Rechnung schreibt, die auf den ersten Blick korrekt erscheint, hat man ja eigentlich keinen Grund, diese direkt im Journal zu überprüfen.

Aktuell habe ich auch das Problem hier im Forum passende Diskussionen zur Mehrwertsteuer Problematik zu finden, da es wie in unserem Beispiel teilweise schwierig ist, eine vergleichbare Ursache festzustellen.

Ich exportiere per Datev Modul an den Steuerberater, also hätte ich das Problem selbst gar nicht auf euerem Weg feststellen können, sondern erst wenn sich mein Stb. beschwert.

Also hier die Aufforderung an alle Leser diesen Sachverhalt in der eigenen Anwendung einmal zu prüfen und falls der Fehler auftritt sich hier anzuschließen, so das dieses Thema vielleicht Beachtung findet.

Eine Bitte bzw. Frage an die "Profis": Kann man meinen o.g. Beitrag mit diesem hier zusammenlegen, das die Problematik identisch ist?

Grüße

Peter

Moin,

ich bin mit dem Support seit 3 Tagen dran (4 Stunden Hotline Zeit)

Beim Erzeugten der FiBu Daten, erzeugt das Programm falsche BU Schlüssel. Dadurch habe ich an der richtigen Stelle 16% bzw 19% und bei meinem Steuerberater kommt genau das Gegenteil an. Die BU Schlüssel 7 und 9 sind vertauscht.

Der Support arbeitet dran

Hallo Luziferia,

ich kann mit deinem Eintrag leider nichts anfangen und weiß nicht ob es das Problem von Konntec und mir ebenfalls betrifft. BU-Schlüssel 7 und 9 betreffen doch Kostenkonten/Ausgaben. Unser Problem tritt bei Ausgangsrechnungen auf, BU Schlüssel 0.

Ich habe allerdings heute ausgiebig mit dem Support telefoniert und dabei feststellen können, dass es tatsächlich einen Bug gibt!!!

In meinem Fall ist das Problem aufgetreten aufgrund der automatischen Rechnungskorrektur. Durch diese wird automatisch von MB

eine Gutschrift erstellt und eine neue Rechnung ausgegeben.

In diesen kopierten Belegen wird nicht automatisch der Positionsrabatt erkannt. Im Rechnungsbeleg erscheint der Rabatt Betrag ausgewiesen,

die Rechnung selbst wird fehlerfrei gedruckt und bei der Verbuchung der Zahlung des Kunden auch keine Fehlermeldung ausgegeben.

Der Rabatt wird aber nicht bei der Übernahme in die Summen-Saldenlisten oder in den DATEV Export übernommen.

Dieser Fehler ist nun bekannt und wird von der Entwicklungsabteilung bearbeitet werden.

Aktuell habe ich mir nun helfen können, indem ich in der neu erstellten Rechnung die rabattierte Position angewählt habe

und nochmals manuell den Rabatt im Rabatt Feld neu eingetragen habe.

Nur anklicken reicht nicht, ins Feld gehen und den Wert überschreiben und bestätigen.

Optisch ändert sich am Rechnungsbeleg nichts, aber bei der Übernahme ins Buchungsjournal und auch beim DATEV-Export

stimmen jetzt meine Werte.

Aktuell ist das Problem Buhl bekannt und tritt bei kopierten Belegen auf, ebenso wie in der Rechnungskorrekturfunktion (da die eben auch nur kopiert)

Aus Interesse: Kann KonntecMG das Problem auch darauf zurückführen?

Ich habe zwar weiterhin Probleme mit einer falsch berechneten Einnahme-Überschuss-Rechnung, das soll aber laut Support an anderen Dingen

liegen die wohl eher in meinen Eingaben zu finden sein sollen. Außerdem ist die EUER ohne Modul zur Übertragung ans Finanzamt nicht verbindlich (da geht ja auch immer eine Meldung auf).

Kkeine Ahnung, daran muss ich noch arbeiten, denn bisher stimmte die bei mir immer....

Ich bleibe jetzt mal hier im Beitrag, weil das Problem sicherlich auch mit der Mehrwertsteuer Umstellungen zu tun hat.

Beim weiteren prüfen meiner falsch ausgewerteten Einnahmenüberschussrechnungen, die laut BUHL wohl nicht verbindlich sind,

da ich kein Steuermodul besitze habe ich festgestellt, dass seit Juli die Werte von erhaltenen versteuerten Anzahlungen Konto 1718
nicht mehr richtig verbucht werden:

So sieht es beim Vergleich im Buchungsjournal Mai/Juli aus:

MB bucht die erhaltene Anzahlung nicht mehr als erhaltene Zahlung zur Rechnung von 8405 zu 8400, Umbuchung Steuer dito.
Dadurch bucht MB in der EUER die erhaltene Anzahlung aus, schlägt diese aber nicht dem Ertrag zu. Dadurch vermindern sich die mtl.

Betriebseinnahmen fälschlicherweise um den abgezogenen Anzahlungsbetrag.

Gerade erfahre ich im Support, das diese Probleme bekannt seien, wo mir aber leider ein öffentlicher Hinweis zu fehlt.

Ich schaue jetzt nochmal, ob es an anderer Stelle diese Frage schon gab....

Hallo zusammen,

auch wenn das Thema schon etwas älter ist, so habe ich anscheinend auch ein Problem mit meiner DATEV-Schnittstelle. Denn nach dem FIBU-Export an meinen Steuerberater meldet der sich zurück mit der Nachricht, dass einige Konten anders gebucht werden müssten, da diese sonst nicht übernommen werden können. In seiner Auflistung sehe ich, dass bei alle entsprechenden Positionen entweder Konto oder Gegenkonto fehlt. Wenn ich mir das allerdings im Buchungsjournal anschaue, dann fällt mir dort bei den gleichen Positionen nichts Auffälliges auf. Kann das auch mit kopierten Buchungssätzen zu tun haben (allerdings schon in 2019 getätigt), oder ist der Fehler woanders zu suchen? Hat Jemand irgend eine Idee, bin mit meinem Latein am Ende.

Vielen Dank und beste Grüße,

Julius

Hast du deine in MB angelegten Debitoren/Kreditoren ebenfalls exportiert und wurden diese in deinem DATEV-Mandanten entsprechend angelegt?
In der Primanota-Ansicht von Datev fehlen in den Zeilen mit Fehlermeldungen die Zuordnung zu den Debitoren-/Kreditoren-Konten.

BTW: Du hast zugleich Erlöse als Kleinunternehmer und mit USt? Bist du da sicher?

Hallo zusammen,

vielen Dank für eure Antworten, ich versuche das mal aufzudröseln:

marcator Beim Export habe ich, soweit ich es verstehe, alles angewählt und es gab auch keine Fehlermeldung. Auf den Screenshots 1+2 siehst du die Einstellungen. Ich habe darüber hinaus auch keine separate Exportfunktion für Debitoren/Kreditoren-Konten gefunden.

Muss man denn standardmäßig neben dem FIBU-Export noch andere Daten/Einstellungen exportieren, damit der Empfänger weiß wie, wo, was hingehört?

SAMM Erlöse als Kleinunternehmer sollten definitiv nicht vorkommen und ich habe mich ehrlich gesagt auch schon bei den Positionen gewundert über die seltsame Aufschlüsselung, denn das waren normale Rechnung. Ich habe gerade nochmals in die Buchungssätze in MB geschaut und die Rechnungen wurden definitiv mit USt. ausgewiesen und werden mir von MB auch als korrekt gebucht angezeigt.

Der Datev-Export mit den von dir gezeigten Einstellungen sollte mindestens zwei Dateien erzeugen:

- EXTF_Buchungsstapel_ ...
- EXTF_DebitorenKreditoren_ ...

Letztere beinhaltet Kunden und Lieferanten. Diese würde ich ebenfalls in Datev importieren und schon kannst du in deinem Buchungsstapel die entsprechenden Zuordnungen vornehmen und vor allem auch nachvollziehen.

Irgendwie kann ich mir gar nicht vorstellen, dass dein Stb damit nicht zurechtkommt.

Hallo SAMM,

danke dir für deine Antwort - ich zweifle deine Aussage wirklich nicht an, im Gegenteil - ich weiß ja wie erfahren ihr hier im Umgang mit der Thematik seid.

Allerdings scheine ich ein Brett vor dem Kopf zu haben, da ich den Fehler (den du beschreibst) nicht finden kann. Denn die markierten Buchungen haben doch in der Spalte MwSt. sogar die 19% Angabe stehen. Habe das Gefühl ich stehe komplett auf dem Schlauch. Wie gesagt - woher die Aufspaltung der "Solotech"-Buchungen in MB auf drei Buchungspositionen kommt, kann ich mir nicht erklären. Habe bei der Rechnung nichts anders gebucht, als bei anderen Rechnungen auch.

Gibt es irgendeinen Bereich in MB, abgesehen vom Buchungsjournal, wo ich einen weitern Überblick über den Buchungsprozess bekommen um ggf. eigene Fehler besser einsehen zu können?