[gelöst] Fibujournal: Falsche Zuordnung der MwSt.-Posten

Mir fiel in unserer Kundendatenbank (2009 R2) auf, dass im Fibujournal bei manchen Datensätzen die "Von MwSt.-Posten Lfd. Nr." GRÖSSER als "Bis MwSt.-Posten Lfd. Nr." ist.
Erschrocken wie ich war, habe ich erst einmal die Microsoft Knowledge Base nach bekannten Fehlern durchsucht, aber keinen entsprechenden Eintrag gefunden.

Dann habe ich unsere NAV 2009 R2 Cronus-DB geöffnet, und siehe da: auch dort zeigt sich dieser Fehler:

Fibujournal.png

Oder ist das etwa kein Fehler?
Wenn doch, kann jemand von euch nachsehen, ob der in Folgeversionen noch immer besteht?

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Hi Natalie,

hab's grad in 2013R2 mal geöffnet -> gleiches in grün

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Oder ist das etwa kein Fehler?

Was der Verwirrung dient, ist im ERP-Bereich immer ein Fehler .
Das ist auch in älteren Versionen so. Das sind die Datensätze, wo eigentlich gar kein Posten da ist.
Da das Anzeigecodeunit 238 G/L Reg.-VAT Entries dann mit SETRANGE filtert, wird auch keiner angezeigt, weil der Von-Bis-Filter natürlich nichts finden kann.

Code:

VATEntry.SETRANGE("Entry No.","From VAT Entry No.","To VAT Entry No.");

Schöner wäre es, wenn da 0 stehen würde. Die Buchungen, die diese Nummern dann wirklich bekommen, stehen im Journal darüber bzw. darunter.

Hallo,

ja, das hat einen Sinn. Wenn man ein Filter "falsch herum" baut, z.B. '43..42', zeigt das damit aufgerufene Fenster nichts an. Da in Buchungen durchaus mal keine MwSt.-Posten generiert werden, ist das eine Möglichkeit, beim Nachschauen (Journal->MwSt. Posten) mit einfachem Code zu arbeiten. Wenn man stattdessen 0 reinschreiben würde, zeigt das Fenster "normalerweise" auch nichts an, ausser manchmal. Mit anderen Worten: Das soll so, war schon in Financials 2.x so, evtl. viel älter.

LG Jens

Schöner wäre es, wenn da 0 stehen würde. Die Buchungen, der diese Nummern dann wirklich bekommen, stehen im Journal darüber bzw. darunter.

Stimmt: Jetzt wo du es sagst, sehe ich es auch.
Wer mit Zugang zu Supportfällen wäre so nett, das mal zu melden ...?

Also irgendwie fehlt mir hier ein eindeutiges "ist ein Fehler". Aktuell, abgesehen von der Verwirrung, sehe ich hier eher ein "funktioniert doch gut". Oder übersehe ich etwas (als nicht-Finance-Profi)?

Also irgendwie fehlt mir hier ein eindeutiges "ist ein Fehler". Aktuell, abgesehen von der Verwirrung, sehe ich hier eher ein "funktioniert doch gut". Oder übersehe ich etwas (als nicht-Finance-Profi)?

Es hat einen geringen "business impact", das stimmt wohl. Trotzdem ist es ein Fehler, eine Nummer einzutragen, die gar nicht zum aktuellen Journal-Datensatz gehört. Da muss, wie Kai schon gesagt hat, eine 0 drin stehen, sowohl beim "von" als auch beim "bis".

Aktuell, abgesehen von der Verwirrung, sehe ich hier eher ein "funktioniert doch gut".?

Innerhalb von C/AL sicherlich, bei optischer Betrachtung der Liste muss der Anwender aber zeilenweise "um die Ecke" denken, und dass die Lfd. Nr., die dort angezeigt werden, gar nicht zu der Buchung gehören, sieht dann eher unsauber aus.

Innerhalb von C/AL sicherlich, bei optischer Betrachtung der Liste muss der Anwender aber zeilenweise "um die Ecke" denken, und dass die Lfd. Nr., die dort angezeigt werden, gar nicht zu der Buchung gehören, sieht dann eher unsauber aus.

Aber dann ist noch die Frage ob es nicht irgendwo anders Seiteneffekte gibt, wenn "From VAT Entry No." und "To VAT Entry No." 0 werden?

mfg,
winfy

Aber dann ist noch die Frage ob es dann nicht Seiteneffekte gibt wenn "From VAT Entry No." und "To VAT Entry No." 0 werden?

Und ob es die gibt: Plötzlich kann man einem Journaleintrag sofort die MwSt-Posten-Losigkeit (*g*) ansehen,
oder man kann sogar das ganze Journal nach Zeilen mit/ohne MwSt-Posten-Bezug filtern

... Skandalös!

Aber dann ist noch die Frage ob es dann nicht Seiteneffekte gibt wenn "From VAT Entry No." und "To VAT Entry No." 0 werden?

Wenn man wirklich einen Posten mit Lfd. Nr. 0 hat, hat man sicherlich noch ganz andere Probleme. Die sollte es im Normalbetrieb ja gar nicht geben. Als manuelle Abgrenzungsposten habe ich die schon gesehen, weil bei Migrationen aus anderen System Übernahmeposten mit negativen Nummern erzeugt wurden, die dann weiterverarbeitet wurden, aber auch ein solches Vorgehen ist kaum zu empfehlen .

Also irgendwie fehlt mir hier ein eindeutiges "ist ein Fehler". Aktuell, abgesehen von der Verwirrung, sehe ich hier eher ein "funktioniert doch gut". Oder übersehe ich etwas (als nicht-Finance-Profi)?

Konnten wir dich mittlerweile überzeugen?

Wer mit Zugang zu Supportfällen wäre so nett, das mal zu melden ...?

Niemand ...?

Hallo,

ich habe mir mal die Artikeljournale angesehen. Dort steht überall 0, wenn kein Artikelposten erzeugt wurde...

Insofern haben wir noch den Ansatzpunkt "Einheitlichkeit" und ich werde es mal als Call absetzen...

LG
Mike

Insofern haben wir noch den Ansatzpunkt "Einheitlichkeit" und ich werde es mal als Call absetzen...

Daaanke
Würdest du uns dann auf den aktuellen Stand der Supportfrage halten?

Na klar...

Habe den Call gerade abgesetzt...

Habe jetzt auf dem Testsystem ein Skript laufen lassen, das bei allen Journaleinträgen mit Von-Nr > Bis-Nr beide Nummern auf 0 setzt.

Und siehe da (keine Überraschung): Viel übersichtlicher, und keine Lücken in der Nummerierung.

Na klar...

Habe den Call gerade abgesetzt...

Danke Mike, Khoi hat ihn übernommen :) Auch intern halten unsere Finance Engineers das für einen Fehler.

Der Fall wurde jetzt an das Produktmanagement weitergegeben...

Hallo,

Neuigkeiten von Microsoft, aber keine guten....

Die Entwicklung hat eine Änderung abgelehnt, sinngemäß mit der Begründung, dass das Verhalten schon seit Ewigkeiten so sei (Stimmt ) und keinen Fehler darstelle.

Viele Grüße aus Dortmund
Mike

Ha, das ist ja unglaublich.
Dann weiß ich jetzt, wo meine User den Satz herhaben "Das haben wir schon immer so gemacht".

Danke für die Info.

Gruß
Marion

Von mir auch danke für die Info.
Mit der Antwort von Microsoft ganz und gar nicht einverstanden.
Wenn ich mal Zeit habe (und ihr mir nicht vorauseilt), schreibe ich die Korrektur selber und zeige sie euch hier. Dann ist das Thema hier auch erledigt

Also ich verstehe die Aufregung hier leider gar nicht, denn ich habe diese "lustige Zahlenabfolge" von Anfang an in Navision in den Fibu-Journalen gesehen - und der Anfang bei mir war in 1997 als NAV noch Navision war

Es geht doch einfach darum, dass es Fibu-Journale geben kann bei denen kein neuer MwSt.-Posten entstanden ist. Und anstatt dann die Nummern der MwSt.-Posten leer zu lassen werden die Nummern des letzten Journals mitgeführt - nur eben falsch rum.
Es gibt bestimmt Wichtigeres zu lösen in NAV, oder?

Ich kann Microsoft also hier mal echt verstehen, dass da nichts geändert werden wird - was bei mir ja auch eher selten vorkommt

VG Anke

Und anstatt dann die Nummern der MwSt.-Posten leer zu lassen werden die Nummern des letzten Journals mitgeführt - nur eben falsch rum.

Und damit ist das Journal falsch erstellt. Das ist eigentlich ein Verstoß gegen die Klarheitsgrundsätze der GoB.
Einem Buchhalter, der zu Zeiten der manuellen Durchschreibjournale sein Grundbuch mit derart kreativen Zusätzen garniert hätte, wäre umgehend gekündigt worden.
In NAV 2013 R2 hat ja ein komplettes Refactoring von Codeunit 12 stattgegefunden, da hätte man sich dieser Eigenheit sicherlich auch annehmen können.
Bei einer Korrekur würde man allerdings indirekt zugeben, dass die Journale der letzten 20 Jahre redigiert werden müssten. Insofern ist das "kein Fehler" m.E. lediglich eine Schutzbehauptung. Natürlich ist das ein Fehler, die Antwort von Microsoft kann ich nicht ernstnehmen. In anderen Modulen klappt es ja auch.

Wenn ich mal Zeit habe (und ihr mir nicht vorauseilt), schreibe ich die Korrektur selber und zeige sie euch hier. Dann ist das Thema hier auch erledigt

Und hier ist meine Lösung für NAV 2009 R2 - ohne Gewähr und auf eigene Gefahr :

Codeunit 12, Funktion InitCodeunit

Code:

    [...]
    GLReg.INIT;
    GLReg."From Entry No." := NextEntryNo;
    // >> NEU
    // GLReg."From VAT Entry No." := NextVATEntryNo;
    // << NEU
    GLReg."Creation Date" := TODAY;
    [...]

Codeunit 12, Funktion FinishCodeunit

Code:

    [...]
    UNTIL GLEntryTmp.NEXT = 0;

    // >> NEU
    IF GLReg."From VAT Entry No." = 0 THEN BEGIN
      IF NextVATEntryNo - 1 >= FirstNewVATEntryNo THEN BEGIN
        GLReg."From VAT Entry No." := FirstNewVATEntryNo;
        GLReg."To VAT Entry No." := NextVATEntryNo - 1;
      END;
    END ELSE
    // << NEU
      GLReg."To VAT Entry No." := NextVATEntryNo - 1;

    IF GLReg."To Entry No." = 0 THEN BEGIN
    [...]

Ich hoffe, die Änderungen lassen sich auch für Versionen >= 2013 R2 durchführen.

Wer darüber hinaus die bisherigen Journaleinträge korrigieren möchte, muss eine kleine Stapelverarbeitungn schreiben. Diese muss in jedem Datensatz prüfen, ob "Von MwSt.-Posten Lfd. Nr." größer als "Bis MwSt.-Posten Lfd. Nr." ist. Wenn ja, beide Felder auf 0 zurücksetzen.

@Mike: Könntest du den alten Supportfall mit diesem Hinweis wieder eröffnen?

Hallo Natalie,

tja, dumm gelaufen - da ich den Arbeitgeber gewechselt habe, komme ich leider nicht mehr an den alten Call bei MBS dran...

Viele Grüße
Mike