Beiträge von cetusia

    Das poppte gerade wieder auf...

    Zuschläge werden bei mir derzeit in 8400 (SKR03) mit 16% USt. gebucht.


    Weiß jemand wo ich die 19% einstellen kann?


    Das Konto 8400 ist mit allgemeiner Steuersatz konfiguriert, da gehen alle Umsätze, und immer mit 19% (außer den Zuschlägen). :(


    Update:

    Gerade nochmals. Jetzt bucht er korrekt in 8400 mit 19%.

    Keine Ahnung, was da los war. Da es aber eine Zahlung aus 08/2021 war hätte die damals schon mit 19% verbucht werden sollen! Egal. :)

    Feld 67 war OK

    bei mir stehen in Feld 47 die Beträge des Kontos 1797, die wiederum die zu zahlende Steuer meiner Konten 4761 / 4962 darstellt.

    Steuerformularzuordnung für Feld 47 werden sowohl in Konto 4761 / 4962 gemacht (Bild 1) als auch in Konto 1797 (Bild 2). Welche Zuordnung jetzt relevant ist kann ich Dir spontan nicht sagen, aber eine der beiden wird bei Dir fehlen?!


       


       

    Bei Buhl habe ich keinen Hinweis auf die Variable <M_EUROVATTEXT> gefunden, dafür in der orgaMax Anleitung

    https://info.deltra.com/faq/das-one-stop-shop-verfahren


    Funktioniert auch bei MB, allerdings wird diese nur dargestellt, wenn auch bei 0% UST in der ersten Zeile das Konto 8320 gewählt wurde...

    Ich hoffe mit dem neuen Patch geht es besser, siehe Ankündigung bei orgaMax:

    https://www.deltra.com/neuerungen-online-updates/21/

    Nach dem Update bucht und erklärt Mein Büro die OSS-Umsätze wie folgt:

    Umsatz SKR03 Konto 8320, keine Übertragung in die USTVA / USTERKL

    USt SKR03 Konto 1777, USTVA Feld 36, USTERKL Feld 156


    Bei beiden bin ich mir unsicher, habe jetzt mal beim Steuerberater nachgefragt.

    Die Übertragung der Bemessungsgrundlage Kto 8320 (SKR03) in Feld 45 der USTVA ist vor und mit OSS richtig.

    MB bringt hoffentlich einen Fix lt. Hinweis vom 06.08.

    https://www.buhl.de/shop/faqs?article=2480

    Alleine habe ich es leider nicht hinbekommen...

    Für die Voranmeldung Juni habe ich den mir bekannten Betrag manuell eingetragen in die USTVA, besser als später eine Korrektur zu senden wie vorgeschlagen.


    Kto 1777 habe ich die Übertragung in Feld 36 USTVA gelöscht, dann passt das.


    Kto 8590 habe ich die Übertragung in Feld 43/48 USTVA gelöscht, dann passt das jetzt auch.


    Hallo, wir haben den Update und den neuesten Patch installiert.

    Heute haben wir die Umsatzsteuervoranmeldung gemacht.

    Was fehlt ist das Konto 1588 Bezahlte Einfuhrumsatzsteuer im Feld 62 auf der Voranmeldung.

    Hat jemand das gleiche Problem ?

    Nein, bei mir werden die Beträge aus 1588 in der USTVA dargestellt.




    Zugegeben finde ich den neuen Kontenplan sehr unübersichtlich zu bearbeiten...

    <rechte Maustaste> hilft bei der Zuordnung der Konten zu den Buchungsschemen und Steuerformularfelder

    ABER ich blicke im Gewirr aus

    - Buchungsschemen nach Steuersatz, Steuerschlüssel oder Konto

    - Steuerschlüsseln

    - Steuerformular-Zuordnungen

    nur noch bedingt durch.

    Gibt es da eine aktualisierte Bedienungsanleitung irgendwo bei Buhl oder Deltra?



    Und gibt es schon irgendwo einen Hinweis, wie die Umsatzsteueranmeldung für OSS funktionieren soll im Oktober? Technisch und buchhalterisch?

    Geht es da nach Bestimmungsland? Oder müssen wir selber das Konto 8320 teilen?

    Probleme...


    Bis 30.06. haben wir die Umsätze mit in der EU fälliger USt wie folgt gebucht/erklärt:

    Umsatz SKR03 Konto 8320, USTVA Feld 45, USTERKL Feld 205

    USt SKR03 Konto 1767, nicht in die USTVA / USTERKL übertragen, dafür in die entsprechende EU-Umsatzsteuererklärung/-voranmeldung


    Nach dem Update bucht und erklärt Mein Büro die OSS-Umsätze wie folgt:

    Umsatz SKR03 Konto 8320, keine Übertragung in die USTVA / USTERKL

    USt SKR03 Konto 1777, USTVA Feld 36, USTERKL Feld 156


    Bei beiden bin ich mir unsicher, habe jetzt mal beim Steuerberater nachgefragt.


    Kann es sein, dass alle OSS Umsätze gar nicht mehr in der USTVA aufkreuzen? Da es kein neues Feld in der Juli USTVA gibt, sollten die Beträge vermutlich nach wie vor im Feld 45 erklärt werden, oder?

    Dass die UST-Beträge, die über OSS abgeführt werden, in Feld 36 aufkreuzen, ist definitiv verkehrt, dann dann bezahle ich die ja bereits im Rahmen der USTVA, und das darf/soll ja erst im Rahmen des OSS am Ende des Quartals geschehen.




    Unabhängig davon haben wir die monatlichen steuerfreien Gutscheinkarten für die Mitarbeiter (44,- Euro) über einen Kreditor in Konto 8590 gebucht. Seit dem Update definiert Mein Büro diese Buchungen vermutlich wegen der 0% USt. als "steuerfreie Ausfuhrlieferungen und erklärt die Beträge in Feld 43 der USTVA, was 1) verkehrt und 2) vor dem Update auch so nicht war.



    Die Hotline konnte dazu nix sagen und hofft auf Nachbesserung.

    Ich auch. :) Patch 21.02.03.001 hat es nicht gebracht, was auch immer da nachgebessert wurde.

    Nun abwarten bis ne EU-Bestellung reinkommt.

    Läuft bis jetzt einwandfrei und was die Meldung anbelangt, da heißt es abwarten und Tee trinken.

    Allerdings bekommt mein Steuerbüro diese Woche ja meine Daten für Juli und dann wollen wir mal einen Testmeldung generieren. Mal sehen, ob die von MB übermittelten Daten dann auch wirklich korrekt ausgewertet werden können.


    Ich werde berichten.

    Bei mir wurden die (nicht vorhandenen) USt-Sätze sogar automatisch angelegt.

    Ansonsten alles automatisch auf 8320 + 1777 (SKR03) verbucht, außer die bereits existierenden und definierten USt.-Sätze von 19% & 20%.

    Update auf Version 21.02.02.001 erfolgreich durchgeführt...

    Bisher alles gut, die hier besprochenen Probleme sind bei uns nicht relevant.


    Aber es gibt (mind.) einen "systematischen" Fehler...


    Wir waren (bis 30.06.) in AT USt-pflichtig und hatten uns dafür von Buhl den USt-Satz 20% installieren lassen.

    Somit wurden alle unsere AT-Rechnungen mit 20% in die Buchungskonten 8050 + 1720 (SKR03) gebucht, das war auch leider nicht veränderbar.

    Dann habe ich einmal pro Monat die kompletten AT-Rechnungen in die Konten 8320 + 1767 umgebucht.


    Das Update hat zwei Konsequenzen:


    1) Das Konto 8050 (Erlöse 20,0 % USt.) wurde in das Konto 8061 geändert, alle Buchungen wurden von 8050 auf 8061 geändert. Achtung, wenn man die Buchungssätze exportiert hat, zu wem auch immer.


    2) Da ab sofort für dem USt.-Satz 20% die Buchungskonten 8320 + 1777 als Standard definiert sind, sind leider auch alle Rechnungen aus dem Zeitraum 01.01.-30.06. automatisch auf die Konten 8320 + 1777 umgebucht worden. D.h. ich muss meine Korrekturbuchungen bzw. Saldenüberträge entsprechend anpassen, damit zumindest meine Salden und vor allen die UST-VA 06/2021 in Deutschland und Österreich stimmen, denn die werden ja erst jetzt abgegeben, denn in 06/21 wird die USt ja noch nach AT abgeführt, erst ab 01.07. über OSS.



    Unabhängig davon wäre es interessant zu erfahren, wie die OSS Anmeldung ablaufen wird. Einzelne Konten pro Land habe ich derzeit absichtlich nicht installiert, denn

    1) kann Buhl nur 4-stellige Konten, d.h. die vorgesehenen Konten 8320-8329 (SKR03) reichen nicht aus für alle Länder und

    2) kann man ja nur einen Standard pro Steuersatz festlegen, d.h. z.B. bei 20% müsste man sich entscheiden ob AT, FR, SK, EE oder BG das "Standardkonto" wird, und die anderen 4 Länger müssten immer noch manuell umgebucht werden.

    Wo habt Ihr Euer Report-Verzeichnis bei einer Serverinstallation?


    Variante A:

    An einem zentralen Ort? Z.B. im Stammverzeichnis des Servers oder in einem extra Verzeichnis?

    Vorteil: Alle greifen auf die gleichen Reports zu, Anpassungen an den Report müssen nur einmalig gemacht werden.

    Nachteil: Bei einem Update meckert MB ggf., dass es die Report nicht im Stammverzeichnis des Clients findet. Dann musste ich das Verzeichnis für jedes Update umbenennen...


    Variante B:

    Im Stammverzeichnis des Servers UND der Clients?

    Vorteil: Keine Probleme beim Update.

    Nachteil: Manuell angepasste Reports müssen auf alle Clients überspielt werden.

    Dann das übliche Spiel, dass auch die Datenbank aktualisiert werden muss. Das dauerte bisher immer ähnlich lange wie die Datensicherung, so ca. 2 Stunden.


    Dieses Mal sind 24 Stunden vergangen und nicht passiert mehr außer anhängendes Bild...

    Ich könnte in die Tischkante beißen... aber ggf. als Learning für andere:


    Vor dem Update macht man ja eine Datensicherung.

    Diese Sicherung hatte ich, warum auch immer, mit einem anderen Server-User gemacht. Das Update war durch, aber das MB-Fenster nicht geschlossen. :evil:

    Dann habe ich mich am Server umgeloggt auf den Admin-Account und das MB-Update gemacht. Leider weder Fehlermeldung noch ein Hinweis, dass noch ein zweiter User angemeldet ist und deswegen das Update nicht durchgeführt werden kann. :censored::censored::censored:


    Erst heute, als ich unter dem Admin Account deinstallieren wollte sagt mir Windows, dass da noch ein zweiter User angemeldet ist und ich deswegen nicht deinstallieren kann... =O


    Ja, mein Fehler, ich weiß.

    ABER den Hinweis von Windows hätte ich mir von der MB-Installations-/Update-Routine auch gewünscht...




    Think positive:

    Es war schon lange fällig zu testen, ob MB mit unserer 20 GB-Datenbank auf einem sehr schnellen Einzel-PC signifikant schneller läuft als auf dem in die Jahre gekommenen Server. Das können wir jetzt tun nach der Notinstallation vom Wochenende...

    Aha,


    Und warum kommuniziert das Buhl nicht an uns? Das wurde zumindest einige Gemüter und Spekulationen beruhigen.

    Weiß ich nicht.


    Aber das war die Antwort vom Einrichtungsservice, als ich mir neben den bereits vor Monaten installierten 20% noch die weiteren 8 Steuersätze installieren lassen wollte.

    Problem sind vermutlich die damit verbundenen Buchungskonten, denn mein zusätzlicher 20% UST-Satz wird auf 8050 + 1720 gebucht, obwohl ich ihn gerne auf 8320 + 1767 hätte, was aber wiederum nicht konfigurierbar ist, wie man es von anderen Buchungskonten gewohnt ist.

    Wenn MB wenigstens die Steuersätze akzeptieren würde dann könnte man Rechnungen schreiben damit. Die Zuordnung hätte ja dann noch Puffer.

    Ganz genau das ist es, was ich so schäbig von Buhl finde. Neue Steuersätze einrichten war bislang schon immer über den Support kostenpflichtig möglich. Was also soll das Rumgeeiere?

    Aber nur max. 3 zusätzliche Steuersätze waren/sind technisch möglich bei MB. Wir benötigen aber derzeit neun, wenn man nur vom vollen UST-Satz ausgeht.

    Ich weiß. 8);(

    Aber bis man von MB eine Antwort oder gar eine Lösung erhält, haben wir ca. 1.000 neue Aufträge verarbeiten müssen. Ich kann die Firma ja nicht auf STOP schalten. Ich glaube wir sind zu groß geworden...


    Wie dem auch sei, die Neuinstallation der aktuellen Variante hat geklappt, keine Fehlermeldung.

    Datensicherung eingespielt - hat geklappt.


    Aber jetzt schon wieder die Fehlermeldung, die uns seit Wochen nervt.

    Jemand ein Idee was das "übersetzt" heißt bzw. bedeutet?




    Wir haben 3GB Datensicherung und die dauert etwa 5min.

    Wobei da auch tausende Scans als Dokumente mit drin sind.

    Wie groß ist die DB?

    Unsere DB ist 20GB groß, die Datensicherung aber "nur" 1,2 GB, wobei das 100% Datensätze sind, ca. 500.000 Rechnungen/Kunden plus alles weitere.



    Die lange Zeit der Datensicherung ist gar nicht so mein Problem. Läuft ja wenn niemand daneben sitzt...

    Aber MB ist generell überlastet, das Abholen von Aufträgen (Shopware, Amazon) dauert gefühlt "ewig" (z.B. 50 Aufträge / 10 min), Zahlungen zuweisen, etc. pp.

    Den Arbeitsspeicher habe ich nicht im Verdacht, die 32 GB sind niemals auch nur annähernd ausgelastet.

    Prozessor ist i7, jetzt i9

    Eher schickt nach unserer Vermutung MB bei jeder Operation GB-weise Daten hin und her, obwohl das nicht unbedingt nötig wäre. Der Server soll alleine rechnen und dann das Ergebnis auf dem Bildschirm darstellen. Ich weiß zugegeben nicht, warum GB hin und her geschoben werden, wenn ich vom Client aus z.B. ein "Filter zurücksetzen" mache... Dauert dann auf dem Client > 10 min, auf dem Server ca. 1 min.

    Bei (fast) jeder UST-VA das gleiche Spiel: Ihr Programm ist nicht auf dem neuesten Stand, sie müssen updaten BEVOR Sie die Daten per Elster senden können...

    Also dann mal wieder ein Update, bei 20 GB Datenbank immer eine zeitliche Herausforderung.


    Und dieses Mal ging es schief...

    Das Update ging mit ein paar Fehlermeldungen durch, das ist ja mehr oder weniger "normal".

    Dann das übliche Spiel, dass auch die Datenbank aktualisiert werden muss. Das dauerte bisher immer ähnlich lange wie die Datensicherung, so ca. 2 Stunden.


    Dieses Mal sind 24 Stunden vergangen und nicht passiert mehr außer anhängendes Bild...


    Was nun stellt sich die Frage?


    Ich probiere jetzt eine komplett neue Serverinstallation aufzusetzen, dann Datensicherung einspielen, dann hoffen und beten, und dann ein erneuter Updateversuch?

    Jemand einen besseren Vorschlag?

    Hier gibt es schonmal einen kleinen Vorgeschmack darauf, wie das später in der Software aussieht:

    https://info.deltra.com/faq/das-one-stop-shop-verfahren

    Danke für den Link.

    D.h. das Update scheint fertig, schaun wir mal, in welcher Nachtschicht wir das einspielen dürfen.


    Und ohne Update keine Chance, das auch nur ansatzweise richtig zu verbuchen...

    D.h. kein Update heißt 26 Lieferländer auf allen Verkaufskanälen deaktivieren...

    Ja, wir denken zu kompliziert... :)


    Bei Amazon war es schon immer gang und gebe, dass die Umsatzsteuer anhand der Lieferadresse angepasst wird. Und das ist m.W. auch legal, soange der Nettobetrag gleich bleibt.


    D.h. Kunde ruft deutschen Shop auf, Artikel kosten 100+19=119 Euro

    Kunde gibt österreichische Lieferadresse ein, schwupps kostet der gleiche Artikel 100+20=120 Euro

    Und das machen ist seit Jahren so, völlig unabhängig von OSS.


    Allerding haben Sie seit neuestem den Hinweis neben dem Preis geändert:

    Früher: "inkl. USt."

    Jetzt: "Preisangaben inkl. USt. Abhängig von der Lieferadresse kann die USt. an der Kasse variieren."

    Preisschwankungen, die ausschließlich auf der unterschiedlichen gesetzlichem USt. beruhen, verstoßen nicht gegen Geoblocking etc. Sie sind halt nicht unbedingt Kundenfreundlich, aber dann bleibt nur ein Subshop pro Land.