Zusammenfassende Meldung

Hallo Zusammen,

gerade will ich meine ZM abgeben und da entdecke ich, dass neben zwei korrekten Buchungen mit USTID aus Österreich (ATU...) auch eine Buchung dabei ist, bei der die USTID ohne Länderkennung einfach nur aus Zahlen besteht. Das hat mich stutzig gemacht und so habe ich mal die USTVA angesehen und unter innergem. Lieferungen nur die beiden Lieferungen nach Österreich gefunden. Da stellt sich mir jetzt die Frage, wie ermittelt MB die Daten für die ZM? Aber noch viel wichtiger ist für mich die Frage, wie bekomme ich den falschen Eintrag in der ZM weg?

Mit der Suche findet man ja dutzende Threads zur ZM, aber immer irgendwie andere Probleme...

Danke SAMM,

trotzdem bin ich ein wenig ratlos. Wenn ich eine Nettorechnung ausstelle, dann müßte die ja in der USTVA auch entsprechend auftauchen und wäre damit identifizierbar. Aber in der USTVA sind eben neben ein paar Exportlieferungen in die Schweiz nur zwei innergemeinschafliche Lieferungen nach Österreich enthalten und die finden sich korrekterweise dann auch auf der ZM wieder. Wie soll man denn dann die falsche Rechnung in der ZM herausfinden?

Eine USTID (oder manchmal auch eine Steuernummer) wird von meinen Kunden beim Einkauf im Onlineshop angegeben und entsprechend Gültigkeit weist dann das Shopsystem dem Kunden die entsprechende Kundengruppe zu (Geschäftskunden DE mit Nettopreisanzeige und Ausweisung von 19% MwSt auf der Rechnung, oder eben EU-Geschäfstkunden mit Nettopreisen und 0% MwSt auf der Rechnung. Ist die angegebene USTID ungültig, wird der Kunden der Standardkundengruppe zugewiesen und bekommt Bruttopreise vorgesetzt. Das wird alles auch so korrekt von Mein Büro übernommen und entsprechend auf den Rechnungen angezeigt. Soweit sogut.

Wie soll man aber jetzt aus ca. 600 Rechnungen im letzten Quartal die eine falsch zugeordnete Rechnung herausfinden. Ich habe mir jetzt mal alle Rechnungen mit einem Preis von 52-54€ anzeigen lassen (laut ZM sind es 53€), aber keine dieser Rechnungen hat eine USTID beim Kunden hinterlegt und die MwSt ist auch korrekt drin. Selbst wenn ich die 53€ laut ZM mit 1,19 multipliziere oder dividiere - in der fraglichen Preisspanne habe ich keine Rechnung ohne MwSt und der komische USTID in meinem System. Es ist zum Haare raufen.... Zumal bei dieser komischen USTID (siehe Bild) mein Shopsystem den Kunden sowieso als normalen Kunden behandelt hätte.

Ich meine, es muss doch in MB eine Möglichkeit geben, die Schritte des Programms nachzuvollziehen.

So, der Fehler liegt eindeutig bei Mein Büro. So einen Schmarrn kann man in einem Programm eigentlich gar nicht verzapfen.

Ich habe mir jetzt über eine Tabellenauswertung mal alle Kunden mit hinterlegter USTID anzeigen lassen. Da waren eine Menge mit DE-Nummer dabei und an denen hat sich MB nicht gestört. Die haben ja auch nicht den Haken bei "Kunden bekommt Nettorechnung" gehabt. Nun habe ich aber auch einen Kunden gehabt, der hier offenbar seine Steuernummer (nicht USTID) angegeben hat. Kein Problem, mein Shopsystem behandelt den dann einfach als normalen Kunden. Folglich bekommt der KEINE Nettorechnung, sondern fein brav die MwSt ausgewiesen. Allerdings hat dieser Kunde - wie übrigens alle Kunden, die eine USTID oder Steuernummer angegeben haben und keine ausländischen Kunden sind, auf der Rechnung in den Positionen Nettopreise angezeigt und erst am Ende der Rechnung die MwSt als separate Position ausgewiesen. Und genau hier scheint sich MB zu verschlucken. Wieso prüft das Programm bei der ZM nicht, ob MwSt auf einer Rechnung enthalten ist, oder nicht. Bei der USTVA wird doch auch richtig gerechnet. Das ist Pfusch!

Btw. die betreffende Rechnung konnte ich mit der Suche nach der Rechnungssumme nicht finden, weil der Kunde im letzten Quartal 2x bestellt hatte und sich die 53€ aus zwei Rechnungen zusammen gesetzt haben. Ich habe nun die Steuernummer aus dem Feld für die USTID entfernt und schon ist die ZM korrekt. Hier sollte aber trotzdem dringend der Prüfalgorithmus in MB überprüft und korrigiert werden.

Übrigens... da Problem besteht immer noch.

Kunde hinterlegt bei Bestellung seine deutsche USTID ohne Länderkennung (also nur Zahlen) und prompt erscheint diese Rechnung dann auch in der ZA, auch wenn der Kunde gar keine Nettorechnung bekommen hat.

Ich schubs das Thema daher mal wieder nach oben, da die ZA Berechnung wohl einer Überarbeitung bedarf.

Naja... Den vorgeschlagenen "Lösungsweg" praktiziere ich die ganze Zeit schon, nur dass es eben reicht, die Rechnung nochmal zu öffnen, Bearbeitung aktivieren und dann die Kundendaten zu bearbeiten und die falsche UstId zu löschen.

Mir kann aber keiner erzählen, dass es nicht möglich sein soll, eine UstId programmseitig auf Plausibilität zu prüfen. Schon da würde eine ID ohne Buchstaben nämlich durchfallen.

So und nachdem ich nun das aktuelle Update drauf habe und meine ZA Meldung abgeben will, stehen da plötzlich zwei deutsche USTIDs mit drauf, obwohl diese Kunden keine Nettorechnung erhalten haben. Da hat man wohl etwas verschlimmbessert.

Zum Glück habe ich mir dazu eine Tabellenauswertung gebastelt, damit die betreffenden Rechnungen schnell identifiziert werden können. Wie man aber zukünftig - wenn die Rechnungen festgeschrieben werden - diese nochmal bearbeiten und die USTID entfernen kann, bleibt mir schleierhaft.

Also nochmal für die lieben Entwickler zum mitschreiben: Ich muß eine Plausibilitätsprüfung einbauen, die USTIDs mit deutscher und solche ohne Länderkennung nicht berücksichtigt. Und das Ganze bitte bis morgen fein säuberlich 1000x abschreiben. Wie, das ist Zuviel Arbeit? Na dann fangt von mir aus gleich mit der Programmiererei an.

Zitat von Mausko

geh mal ins Orgamax Forum, da haben die schon den "Salat", dass man Rechnungen nicht mehr bearbeiten kann

Oh fein, dort gibt's ja einen echt lustigen Thread dazu.. Aber da hat es sich Deltra mit der Entfernung des "Bearbeiten" Buttons und der entsprechenden Einträge im Kontextmenü wohl etwas einfach gemacht.
Im Orgamax-Forum lese ich dazu gerade:

Na ja, den Button "Bearbeitung freigeben" gibt es nicht mehr, ich hoffe das ist ein Bug, aber über F2 kann man immer noch die Rechnung zur Bearbeitung freigeben. Wenn man dann die bearbeitete Rechnung als nicht ausgedruckt speichert, kann sie auch gelöscht werden.


Da möchte man manchmal einfach

Zitat von Heiko66

So und nachdem ich nun das aktuelle Update drauf habe und meine ZA Meldung abgeben will, stehen da plötzlich zwei deutsche USTIDs mit drauf, obwohl diese Kunden keine Nettorechnung erhalten haben.

Offenbar haben die Entwickler beim Update soviel zu tun gehabt (nasebohren oder so), dass man die "nebensächlichen" Dinge mal eben unter den Tisch hat fallen lassen. Will sagen: auch mit der aktiellen MB-Version erscheinen auf der ZA wieder deutsche UStIDs, die da nix zu suchen haben. Der Kunde bekommt keine Netto-Rechnung im Sinne einer steuerfreien innergemeinschaftlichen Lieferung, sondern lediglich eine Netto-Rechnung mit Nettopreisen und separat ausgewiesener MwSt - was also hat dieser Kunde auf der ZA zu suchen? Außerdem erzeugt die nun notwendig werdende Rechnungsbearbeitung völlig unnötig einen neuen Eintrag im Journal.

Wenn jemand also ungeprüft seine ZA erstellt und abschickt, könnte es sein, dass diese falsch ist, oder anders gesagt: MB kann man nicht trauen.
Himmelherrgottnochmal, so schwer kann es doch nicht sein, ein Programm zumindest in solchen Dingen sicher zu machen und wenn man das nicht hinbekommt, dann sollte man wenigstens so ehrlich seinen Kunden gegenüber sein und mit einem extra Popup-Fenster darauf hinweisen, dass man seine ZA lieber nochmal kontrollieren soll. Wenn ich bei meinen Kunden so schlampig arbeiten würde, bräuchte ich kein MB mehr - so siehts doch aus.

Hallo Herr Diel,

das ist schnell erklärt:

Der Kunde hat eine normale Rechnung mit 19% MwSt. erhalten. In der Positionsauflistung wurde "netto" ausgewählt, damit die Steuer separat ausgewiesen wird. Bei den Konditionen ist halt die DE-UStID eingetragen, aber kein Häkchen für "Kunde bekommt netto-Rechnung" gesetzt. Der Standardfall für die steuerfreie Rechnung ist die innergemeinschaftliche Lieferung und alle Positionen laufen mit dem vollen Steuersatz von 19%

Mit anderen Worten: Die Rechnung hätte nie in der ZA auftauchen dürfen. Nachdem ich die UStID entfern habe (ohne sonst irgendwas an der Rechnung zu ändern), ist diese dann auch aus der ZA verschwunden.

Und nebenbei: Es handelt sich um genau den gleichen Fall, wie im Eröffnungspost. Auch damals sind Rechnungen in der ZA aufgetaucht, bei denen eine Steuernummer eingetragen war, in der Positionsauflistung "netto" ausgewählt wurde und jeder Artikel korrekt mit 19% MwSt ausgewiesen wurde. Ob es sich nun um eine Steuernummer nur aus Zahlen, oder eben komplett mit DE davor handelt, ist doch völlig irrelevant. Das Programm hat Rechnungen mit ausgewiesener MwSt nicht in die ZA zu nehmen, egal ob da ne Steuernummer eingetragen ist, oder nicht.