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...
    ?( 8|

    • Offizieller Beitrag

    Zusammenfassende Meldung - Falsche Werte :

    Zitat

    Nur wenn MIT Zeitpunkt der Rechnungsstellung beim > Kunde unter > Statistik/Konditionen der Haken
    > Nettorechnung UND eine > USt ID Nummer (unwichtig, ob Gültigkeit überprüft wurde per Internet) eingetragen war, wird die Rechnung in ZM übertragen.


    Korrekturen: Zusammenfassende Meldung bearbeiten

    Zitat

    Nachträgliche Korrekturen, nachträglicher Eintrag der USt ID Nr und/oder Haken bei Nettokunde bringen keine nachträglichen Änderungen in der ZM bezügl. dieser Rechnung.


    Soviel kann ich aus eigener Erfahrung berichten. Da teste das doch nochmal aus. Anscheindend wurden Rg's gelöscht oder neu zugeordnet. Wie auch immer - die ZM ändert sich nie mehr mit.


    [Verbesserungsvorschläge] Zusammenfassende Meldung - Leerzeichen in UID muss weg

  • 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. :cursing:


    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.

    • Offizieller Beitrag

    Hallo,


    unsere Entwickler haben zum Fall, dass eine Rechnung an einen Kunden mit einer rein numerischen Umsatzsteuer-Identnummer in der ZM erscheint, geantwortet. Aus der Antwort möchte ich ausschnittsweise zitieren:


    "...Um den Datensatz aus der ZM zu entfernen, muss der Rechnungsdatensatz aktualisiert werden. Am besten einmal den Kunden aus der Rechnung entfernen, einen Dummy-Kunden hinterlegen und abspeichern. Danach den korrigierten Kundendatensatz erneut in der Rechnung hineinladen. Das Feld MOV_INVOICES.VATID sollte jetzt leer sein und somit auch nicht mehr in der ZM aufgeführt werden. Welche Rechnungen einen falschen Datensatz besitzen, kann ganz bequem über eine Tabellenauswertung => Rechnungen ermittelt werden (Spalte VATID hinzufügen und auswerten)..."


    Ich kann jetzt natürlich bei unseren Entwicklern nachfragen, ob hier eine automatische Prüfung auf eine möglicherweise unzulässige USt-ID (z.B. ID ohne Länderkennzeichen) eingefügt wird. Ich vermute allerdings, dass ich dann einen Hinweis auf die bereits eingeführte Prüfroutine erhalte, die allerdings im Kundendatensatz manuell anzustoßen ist.


    Mit freundlichem Gruß


    Christoph Diel

  • 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. :wacko:


    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. :P

  • Wie man aber zukünftig - wenn die Rechnungen festgeschrieben werden - diese nochmal bearbeiten und die USTID entfernen kann, bleibt mir schleierhaft.

    Moin Heiko,
    geh mal ins Orgamax Forum, da haben die schon den "Salat", dass man Rechnungen nicht mehr bearbeiten kann. Bleibt nur zu hoffen, dass die Entwickler die Zeit bis zur Veröffentlichung der neuen MB Version nutzen, um solche Fehler zu korrigieren.

  • 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 :monster:

  • Ja, und wenn die Versanddaten exportiert werden, kann die Rechnung auch nicht mehr bearbeitet werden...
    Wie geschrieben, hoffe ich, dass das MB Update ein paar Korrekturen dazu beinhaltet...

  • Moin,
    ich muss hierzu auch nochmals meinen Senf hinzugeben:
    der Automatismus von MB ist vollkommen unsinnig:

    • es reicht allein, wenn in den Adressdaten unter Konditionen die Umsatzsteuerid steht. (Beispiel: eine Kundin hat vor Jahren in Holland ein Gewerbe betrieben und eine innergemeinschaftliche Lieferung erhalten. Heute lebt und arbeit sie in Berlin, die Aprilrechnung taucht in der ZM auf) Es ist das Häkchen "Kunde bekommt netto Rechnung" nicht aktiviert.
    • Es gibt auch EU Kunden, die eine ID haben und in MB eingetragen sind, und dennoch keine innergemeinschaftliche Lieferung erhalten. Dennoch wird von MB jede Rechnung in die ZM eingetragen.

    Der Workaround von Herrn Diehl ist ja ganz nett, nur mit GOBD hat das ja nichts zu tun. Mal davon abgesehen, dass die Rechnung durch Löschen der ID auch verändert wird.
    Dringend notwendig ist es, dass eine ZM nur erfolgt, wenn auch das entsprechende Erlöskonto in der Rechnung ausgewählt ist oder es dort eine Einstellung gibt, dass es sich um eine innergemeinschaftliche Lieferung handelt, aber so geht es definitiv nicht!

  • 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.
    X(

    • Offizieller Beitrag

    Hallo Heiko66,


    trotz mehrfacher Versuche habe ich es nicht geschafft, bei einem Kunden


    - aus Deutschland
    - mit eingetragener deutscher Umsatzsteuer-ID
    - ohne Häkchen bei "Dieser Kunde bekommt eine Netto-Rechnung"


    eine Rechnung zu erstellen, die in der ZM auftaucht. Deshalb meine Frage: Was genau haben Sie in der Rechnung ausgewählt: Steht die Mwst auf null? Gibt es evtl. sogar Positionen mit unterschiedlichen Steuerangaben? Welche Einstellungen sind unter dem Reiter "Erweitert" bei "Sonstiges" gewählt? Welcher Standardfall für steuerfreie Rechnungen ist in den Firmenstammdaten hinterlegt?


    Ohne den Sachverhalt hier nachvollziehen zu können, kann ich den Fall (und das ist ein anderer Fall als in Ihrem Eröffnungspost) nur schwer unseren Entwicklern vorlegen. Deshalb wären weitere Infos für uns hilfreich.


    Mit freundlichem Gruß


    Christoph Diel

  • 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.

    • Offizieller Beitrag

    Hallo Heiko66,


    meine Nachfrage hatte folgenden Hintergrund: Ich kann nur den Sachverhalt aus Ihrem Eröffnungspost nachvollziehen; Trage ich bei einem Kunden nur eine Zahl bei der "Ust-Identnummer" ein, also ohne den Vorsatz "DE", erscheinen Rechnungen an diesen Kunden in der ZM. Trage ich aber eine tatsächliche Umsatzsteuernummer ein, also MIT dem Präfix "DE", und mache sonst alles wie von Ihnen beschrieben, erscheint diese Rechnung hier vor Ort nicht in der ZM! Ich habe es an mehreren Rechnern getestet. Daher vermute ich evtl. zwei unterschiedliche Ursachen und wollte mich daher versichern, wie Sie genau vorgegangen sind.


    Gerne können auch andere Anwender ihre Erfahrung hier posten, um festzustellen, ob es sich bei dem von Ihnen in Post #16 geschilderten Sachverhalt um einen Einzelfall, den gleichen Sachverhalt wie im Ausgangspost oder um zwei unabhängig voneinander auftretende Phänomene handelt.


    Mit freundlichem Gruß


    Christoph Diel

  • Moin,
    ich habe das mal so gut wie möglich im Demomandanten durchgepielt, dort taucht die Rechnug auch nicht in der ZM auf.
    @ Heiko: mache doch mal das gleiche im Demomandanten und sieh dort mal, ob das Problem bei Dir ebenfalls auftaucht. Vielleicht kann man das Problem so eingrenzen.
    @ Christoph Diel: wie ich oben weiter geschrieben habe, sollte der Eintrag in die ZM an das Erlöskonto in Verbindung mit der ID gekoppelt sein. Damit wäre sowohl Heikos als auch mein oben geschildertes Problem erledigt.