MWST Umstellungstool

mal ne frage nebenbei: kann es sein, dass das o.g. problem mit den nicht mehr sichtbaren sections in 4.0 sp3 behoben ist? ich kann alle sections in dem bericht sehen und habe noch massig platz weiter runter zu scrollen...

Ab 4.0 SP3 ist dieser Bug tatsächlich behoben, leider ist dieser technische Stand nicht überall im Einsatz. Zumindest bei der Entwickung kommt man so aber ran, danke für den Hinweis. Neue Sections lassen sich aber auch mit dem neuen Client nicht einfügen.

Lt. Open issues-Dokument existiert beim Tool nach wie vor ein Bug, dass Preise incl. Mwst in Verkaufszeilen bei der Konvertierung neu berechnet werden.

Hallo,

mal 'ne andere Frage. Unser Kunde ist kein herkömmliches Handelsunternehmen und bucht die meisten Umsätze MwSt-frei. Genügt es dann nicht, wenn wir die neue Produktbuchungsgruppen anlegen und in der Buchungsmatrixgruppe (Produktbuchungsgruppe) bei der neu erstellten am Jahresbeginn das Booleanfeld "Automatisch einfügen als Vorgabe" auf TRUE setzen? Wenn ich das richtig verstanden habe, wird bei MwSt.-Pflichtigen Buchungen dann die neue Produktbuchungsgruppe verwendet. Microsoft empfiehlt in dem Whitepaper, dass man die Erfolgskonten doppelt (16 % und 19%), so dass Buchungen die das alte Jahr betreffen getrennt voneinander buchen kann. Bei der eigentlichen Buchung kann dann anstelle der neuen Standard Produktbuchungsgruppe (mit 19 %) die abweichende alte mit 16 % verwendet werden.

Um das ganze noch mal auf den Punkt zu bringen. Unser Kunde hat (fast) keine Produkte, die Mehrwertsteuerpflichtig sind.

Fast keine ? ... Das heißt doch ... einige ...
Und das Gesetz schreibt vor, es soll MWST rein gebucht werden.
Also werdet auch Ihr wohl nicht drum rum kommen neue Erlöskonten für die 19% anzulegen Gleiches Leid für alle Der Steuerprüfer wirds euch danken

Hallo,
Genügt es dann nicht, wenn wir die neue Produktbuchungsgruppen anlegen und in der Buchungsmatrixgruppe (Produktbuchungsgruppe) bei der neu erstellten am Jahresbeginn das Booleanfeld "Automatisch einfügen als Vorgabe" auf TRUE setzen? Wenn ich das richtig verstanden habe, wird bei MwSt.-Pflichtigen Buchungen dann die neue Produktbuchungsgruppe verwendet.

Das hat nichts damit zu tun. "Automatisch einfügen als Vorgabe" bedeutet, dass die "MWST Produktbuchungsgruppe" auf der Artikel- oder Ressourcenkarte anhand dem Wert in dem Feld "Vorg. MwSt.-Produktbuchungsgr." automatisch gefüllt wird, wenn die Produktbuchungsgruppe dort eingetragen wird.

In der Funktion CanConvertSalesDocument wird ja geprüft, ob ein Beleg
konvertiert werden kann. Leider ist auch in der korrgierten Version ein Bug , der den Rückgabewert auf FALSE setzt, weil der Code in der VATProdPostingGroupConv bzw. GenProdPostingGroupConv vorhanden ist.
Genau das ist aber notwendig, um konvertieren zu können.

Code:

// Status on Header
IF StepToCheck IN [0,1] THEN
  IF (SalesHeader.Status <> SalesHeader.Status::Open) AND (IgnoreStatusOnSalesHeader = FALSE) THEN
    WITH SalesLine DO BEGIN
      RESET;
      SETRANGE("Document Type",SalesHeader."Document Type");
      SETRANGE("Document No.",SalesHeader."No.");
      IF FIND('-') THEN REPEAT
        IF "Outstanding Quantity" > 0 THEN BEGIN
          IF UpdateVATProdPostingGroup = TRUE THEN
            IF VATProdPostingGroupConv.GET("VAT Prod. Posting Group") THEN
              ExitValue := FALSE;
          IF ExitValue = TRUE THEN
            IF UpdateGenProdPostingGroup = TRUE THEN
              IF GenProdPostingGroupConv.GET("Gen. Prod. Posting Group") THEN
                ExitValue := FALSE;
        END;
      UNTIL (NEXT = 0) OR (ExitValue = FALSE);
    END;


Richtig wäre :

Code:

IF NOT VATProdPostingGroupConv.GET("VAT Prod. Posting Group") THEN
              ExitValue := FALSE;

bzw.

Code:

IF NOT GenProdPostingGroupConv.GET("Gen. Prod. Posting Group") THEN
                ExitValue := FALSE;


Außerdem sind etliche Zeilen vorhaden

Code:

IF "Outstanding Quantity" > 0 THEN BEGIN

Wenn in Belegzeilen mit negativen Mengen gearbeitet wird, ist auch dieser Wert negativ. Solche Zeilen werden bislang ignoriert.
Besser :

Code:

IF "Outstanding Quantity" <> 0 THEN BEGIN

Im Einkaufsbereich CanConvertPurchaseDocument alles analog.

In Umlagerungsauftragszeilen (Tabelle 5741 Transfer Line) ist die Produktbuchungsgruppe ebenfalls enthalten. Diese werden durch das Tool nicht konvertiert, dieses ist im White Paper nicht erwähnt.

Der Defaultwert für das Update der Produktbuchungsgruppe ist die "Vorg. MwSt.-Produktbuchungsgr." zu ändern. Das passt aber nicht zu den Defaultwerden "Beides" für die Artikel etc., nur wenn keine neue Produktbuchungsgruppe verwendet wird muss dieser Wert von 16 auf 19 geändert werden. Wenn das Tool mit diesen Einstellungen läuft, hat man hinterher sowohl für die alte als auch für die neue Produktbuchungsgruppe eine 19er- "Vorg. MwSt.-Produktbuchungsgr.". Wenn mit díesen Einstellungen in 2007 Belege für 2006 erstellt werden und die Produktbuchungsgruppe in der Zeile den alten Wert erhält wird dann 19 % statt 16 % Steuer gebucht.

So. habe nun auch endlich das MWST Tool bekommen
Aber schon vor dem testen, tut sich mir die erste Frage auf, in den Inventurauftragszeilen (Inventur Komfortmodul) wird die Produktbuchungsgruppe gespeichert.

Zwar hat die Inventur nichts mit MWST zu tun, aber der Produktbuchungsgruppe ist ja eine MWST Produktbuchungsgruppe hinterlegt.

Da die Inventurauftragszeilen "jetzt" generiert werden, um anschl. die Erfassungslisten zu drucken, wird die aktuelle Produktbuchungsgruppe hinterlegt. Am 31.12. wird gezaehlt, erste KW werden die Daten erfasst und gebucht.

Im White Paper wird diesbezüglich nichts erwaehnt.

Muss ich da was berücksichtigen?

Wenn nun etwas gezaehlt/erfasst wird, was nicht im Inventurauftrag vorkommt, werde ich das wohl manuell mit der alten Produktbuchungsgruppe erfassen müssen?

Das White Paper deckt nur die Tabellen aus dem Standard ab, da gehört das Inventurmodul nicht dazu.
Durch Zusatzfunktionen kann man natürlich das Tool dazu bringen, auch durch diese Tabelle zu laufen, aber beim Inventurstichtag 31.12 wäre das nicht nur unnötig, sondern auch falsch.

Bei Nacherfassung im neuen Jahr : Alles was im 2007 erfasst wird, aber noch 2006 betrifft, muss manuell auf die alte (MWST)- Produktbuchungsgruppe gesetzt werden, weil vom Artikel dann die neuen Werte gezogen werden.

Hmm. Ok. Soweit klar.

Inventur Komfortmodul ist aber ein Standard Modul? Wird aber nicht abgedeckt weils nicht bit Basis Lizenz zu haben ist?

Naja. Ok. Also brauch ich mir da keine Sorgen machen. Die jetzt erfassten Inv. Auftragszeilen werden im neuen Jahr richtig gebucht, und neue Inventurauftragszeilen ändere ich die Produktbuchungsgruppe Manuell.

Damit kann ich leben.
Danke

Es existiert nach wie vor ein bestätigter Bug, dass in Verkaufszeilen mit Preisen incl MWST die Preise neu berechnet werden und nach der Konvertierung zu hoch sind. Lt. Aussage MS soll dieser Bug noch behoben werden, nur wann

Bei der Anpassung für 2.60 habe ich wegen schon vorhandener extra Addon-Felder einen Workaround gefunden, der die Preise erhält, und zum Glück arbeiten alle unsere derzeitigen 3.70/4.0 Kunden mit Preisen exkl. MWST.

Ich habe mit unserem Kunden die Vorgehensweise der Konvertierung abgesprochen. Er möchte, dass die Sachkonten auf die neue Produktbuchungsgruppe geändert werden. Die Erlöskonten, die noch ggf. für alte Buchungen benötigt werden, sollen gedoppelt werden. Jetzt habe ich die neue Produktbuchungsgruppe erstellt und in der Mwst Buchungsmatrix Einrichtung hinterlegt. Natürlich habe ich auch neue Konten für die Umsatz- und Vorsteuer erstellt.

Ich habe das Tool laufen lassen und die Option "Update Sachkonten" gewählt. Im Bericht, der die Änderungen durchführen soll, habe ich dann die Konten mit 16 % die beibehalten werden sollen, rausgefiltert.

Wenn ich das richtig verstanden habe, sollte doch die Option "Update Sachkonten" die neue Produktbuchungsgruppe und MwSt.-Produktbuchungsgruppe bei den Sachkonten hinterlegen. Nach der Konvertierung schaue ich mir die Konten an und muss feststellen, dass dies nicht der Fall ist. (Die Option "Konvertierung durchführen ist natürlich gesetzt worden)

Hab ich da was falsch verstanden oder vielleicht vergessen ein Option zu setzen?

Nachtrag: Habe das Tool auf einem Testsystem mit einer geclonten DB laufen lassen!

Ich habe das Tool laufen lassen und die Option "Update Sachkonten" gewählt. Im Bericht, der die Änderungen durchführen soll, habe ich dann die Konten mit 16 % die beibehalten werden sollen, rausgefiltert.

In Sachkonten wird nur die MwSt.-Produktbuchungsgruppe geändert. Die Konten, die konvertiert werden sollen, müssen ausgefiltert werden, nicht umgekehrt.

In der Funktion CanConvertSalesDocument wird ja geprüft, ob ein Beleg
konvertiert werden kann. Leider ist auch in der korrgierten Version ein Bug , der den Rückgabewert auf FALSE setzt, weil der Code in der VATProdPostingGroupConv bzw. GenProdPostingGroupConv vorhanden ist.
Genau das ist aber notwendig, um konvertieren zu können.

Code:

// Status on Header
IF StepToCheck IN [0,1] THEN
  IF (SalesHeader.Status <> SalesHeader.Status::Open) AND (IgnoreStatusOnSalesHeader = FALSE) THEN
    WITH SalesLine DO BEGIN
      RESET;
      SETRANGE("Document Type",SalesHeader."Document Type");
      SETRANGE("Document No.",SalesHeader."No.");
      IF FIND('-') THEN REPEAT
        IF "Outstanding Quantity" > 0 THEN BEGIN
          IF UpdateVATProdPostingGroup = TRUE THEN
            IF VATProdPostingGroupConv.GET("VAT Prod. Posting Group") THEN
              ExitValue := FALSE;
          IF ExitValue = TRUE THEN
            IF UpdateGenProdPostingGroup = TRUE THEN
              IF GenProdPostingGroupConv.GET("Gen. Prod. Posting Group") THEN
                ExitValue := FALSE;
        END;
      UNTIL (NEXT = 0) OR (ExitValue = FALSE);
    END;


Richtig wäre :

Code:

IF NOT VATProdPostingGroupConv.GET("VAT Prod. Posting Group") THEN
              ExitValue := FALSE;

bzw.

Code:

IF NOT GenProdPostingGroupConv.GET("Gen. Prod. Posting Group") THEN
                ExitValue := FALSE;


Außerdem sind etliche Zeilen vorhaden

Code:

IF "Outstanding Quantity" > 0 THEN BEGIN

Wenn in Belegzeilen mit negativen Mengen gearbeitet wird, ist auch dieser Wert negativ. Solche Zeilen werden bislang ignoriert.
Besser :

Code:

IF "Outstanding Quantity" <> 0 THEN BEGIN

Im Einkaufsbereich CanConvertPurchaseDocument alles analog.

Den Bug in CanConvertSalesDocument kann ich nicht bestätigen. Der genannte Codeabschnitt wird nur durchlaufen, wenn IgnoreOnSalesHeader=FALSE und es sich um einen nicht offenen Beleg handelt. Wenn also gewünscht ist, den Status zu beachten (wann auch immer das der Fall ist; die Standardeinstellung ist ja auch TRUE), würde mit Deiner Änderung der Beleg angefasst werden (sobald in der Tabelle VATProdPostingGroupConv ein Eintrag für diesen MwSt.Satz vorhanden ist, andernfalls passiert mit diesem Beleg ja eh nichts). Meiner Meinung nach ist der Code so korrekt, da ein Beleg nicht geändert wird, wenn der Status nicht offen ist und der Status beachtet werden soll.

Meiner Meinung nach ist der Code so korrekt, da ein Beleg nicht geändert wird, wenn der Status nicht offen ist und der Status beachtet werden soll.

Vermutlich hast du recht, danke für den Hinweis (und "Herzlich Willkommen im Forum !")

Merkwürdig finde ich allerdings, dass wenn diese Funktion nur dazu da ist, etwas zu prüfen, was erfüllt sein müsste, um dann die Konvertierung zu verhindern, hätte ein EXITVALUE := FALSE nach der ersten IF Bedingung auch genügt. So wie es programmiert ist, werden freigegebene Aufträge mit ausschliesslich 7% Zeilen als konvertierbar zurückgemeldet, bis die aufrufende Funktion dann merkt, dass sie gar nicht konvertieren kann, weil dieser Steuercode nicht in der VATProdPostingGroupConv vorhanden ist.

Gestolpert war ich über diese Funktion beim Anpassen für 2.60. Wenn hier der Status (den es hier ja noch nicht gibt) ignoriert wird, bewirkt gerade diese Funktion, dass überhaupt kein Beleg mehr konvertiert wird.

Im allgemeinen 19% Hype ist die gleichzeitige Erhöhung der Durchschnittsbesteuerung (5% auf 5,5% bzw. 9% auf 10,7%) für Produkte der Land- und Forstwirtschaft weitgehend untergegangen. Falls es jemand betrifft, nicht vergessen!

Merkwürdig finde ich allerdings, dass wenn diese Funktion nur dazu da ist, etwas zu prüfen, was erfüllt sein müsste, um dann die Konvertierung zu verhindern, hätte ein EXITVALUE := FALSE nach der ersten IF Bedingung auch genügt.

Das wird denk ich mal so gemacht, da die Funktion nur FALSE zurückgeben soll wenn ein Beleg der eigentlich umgestellt werden sollte (aufgrund der Restauftragsmengen in den Zeilen), nicht umgestellt werden kann, weil der Status nicht offen ist. In diesem Fall wird dies protokolliert und am Ende im Bericht ein Hinweis ausgeben, dass dieser Beleg manuell umzustellen ist. Bei Belegen die schon komplett geliefert sind, oder die nur 7% Zeilen haben soll die Funktion aber TRUE zurückgeben, da für diese kein Hinweis ausgegeben werden muss.

In der 2.60 kann meiner Meinung nach der ganze Code auskommentiert werden. Natürlich dann auch die Aufrufe von CanConvertSalesDocument mit StepToCheck=1.

Es existiert nach wie vor ein bestätigter Bug, dass in Verkaufszeilen mit Preisen incl MWST die Preise neu berechnet werden und nach der Konvertierung zu hoch sind. Lt. Aussage MS soll dieser Bug noch behoben werden, nur wann

Für alle, die noch keinen Workaround für die Verkaufszeilen mit Artikel mit Bruttopreisen hat, kann im "NAV MwSt.-Tool - Known Issues" Dok. dazu etwas finden. (Zu finden im PartnerSource "Downloads & Updates / Steueränderungen")

Seit wann diese Korrektur bzw. der Workaround im Dok drin ist, steht nirgends....

Wolfgang

voyager, kannst du uns den Ausschnitt PS20420 (sollte ja der sein) kurz posten? Unser NSC reagiert leider erst ab Mittag.

Wäre echt ein Traum

Workaround für PS20420, die Funktionen in Report 11080 müssen erweitert werden.

PS20420
Problem:
Preise inklusive MwSt. Durch das Eintragen der neuen MwSt.-Produktbuchungsgruppe in Zeilen die nicht gesplittet wurden wird der Preis neu kalkuliert. Grundsätzlich werden Preise und Rabatte durch das Tool nicht geändert.

Lösung:
Resolution/Workaround:

----------------------------------------------------------------

- Please run Object Designer
- browse to object report 11080
- open object report 11080 in design mode
- press F9 to view C/AL Code
- browse to function "UpdateExistingSalesLine"
- open C/AL Locals
- browse to tab Variables and add the following variable: "OldSalesLine", DataType: "Record", SubType "Sales Line"
- close C/AL Locals
- change the code of function "UpdateExistingSalesLine":

old:
// updating Sales Line
IF GenProdPostingGroup <> '' THEN
SalesLine.VALIDATE("Gen. Prod. Posting Group",GenProdPostingGroup);
IF VATProdPostingGroup <> '' THEN
SalesLine.VALIDATE("VAT Prod. Posting Group",VATProdPostingGroup);
SalesLine.MODIFY;

new:
// updating Sales Line
OldSalesLine := SalesLine; // new
IF GenProdPostingGroup <> '' THEN
SalesLine.VALIDATE("Gen. Prod. Posting Group",GenProdPostingGroup);
IF VATProdPostingGroup <> '' THEN
SalesLine.VALIDATE("VAT Prod. Posting Group",VATProdPostingGroup);
SalesLine.VALIDATE("Unit Price",OldSalesLine."Unit Price"); //new
SalesLine.MODIFY;

- browse to function "UpdateExistingPurchaseLine"
- open C/AL Locals
- browse to tab Variables and add the following variable: "OldPurchaseLine", DataType: "Record", SubType "Purchase Line"
- close C/AL Locals
- change the code of function "UpdateExistingPurchaseLine":

old:
// updating Purchase Line
IF GenProdPostingGroup <> '' THEN
PurchaseLine.VALIDATE("Gen. Prod. Posting Group",GenProdPostingGroup);
IF VATProdPostingGroup <> '' THEN
PurchaseLine.VALIDATE("VAT Prod. Posting Group",VATProdPostingGroup);
PurchaseLine.MODIFY;

new:
// updating Purchase Line
OldPurchaseLine := PurchaseLine; //new
IF GenProdPostingGroup <> '' THEN
PurchaseLine.VALIDATE("Gen. Prod. Posting Group",GenProdPostingGroup);
IF VATProdPostingGroup <> '' THEN
PurchaseLine.VALIDATE("VAT Prod. Posting Group",VATProdPostingGroup);
PurchaseLine.VALIDATE("Direct Unit Cost",OldPurchaseLine."Direct Unit Cost"); // new
PurchaseLine.MODIFY;

- save the object and close it-

Danke Kowa :)

Bei der Vorabprüfung wird leider nicht geprüft, ob die Artikel in den Belegen noch im Artikelstamm vorhanden sind. Die Konvertierung bricht dann ab. Um dies abzufangen, muss in die CanConvert... Funktionen für Type::Item pro Zeile noch ein Test-GET auf den Artikelstamm damit dieser Fehler rechtzeitig auftritt. Die Zeile muss dann gelöscht oder der Artikel kann mit gleicher Nr. neu angelegt werden ( falls dieser irrtümlich gelöscht wurde).
Für Ressourcen, Zu/Abschläge dito.

So. Habe nun auch endlich mal testen können :)
Die Auftraege und Bestellungen sind so gut wie alle fakturiert , die noch offenen nicht geliefert, dürfte ansich keine Probleme geben mit der Umstellung, und ziemlich schnell von dannen gehen? Wir arbeiten weder mit Brutto Preisen, noch Service Rechnungen, noch Zu/Abschlaege, Artikelverfolg, Reservierungsposten usw....

Mache mir nun eine Checkliste mit Sachen die ich prüfen muss nach der Umstellung.

Scheinbar schaff ich es doch noch zur 0:00 Party am 1.1.

Edit, was mich grad wundert ist das nicht gelieferte Spezialauftraege auch umgestellt wurden trotz das das White Paper schreibt die würden nicht vopm Tool berührt. Evtl eine Anpassung unseres NSC ?

Hi elTorito!

[...] Edit, was mich grad wundert ist das nicht gelieferte Spezialauftraege auch umgestellt wurden trotz das das White Paper schreibt die würden nicht vopm Tool berührt. Evtl eine Anpassung unseres NSC ?

Das Tool - so wie es von Microsoft kommt - irgnoriert unteranderem all' die Verkaufszeilen die im Feld "Special Order" ein Häkchen und im Feld "Special Order Purchase No." einen beliebigen Wert stehen haben. Es sieht also aus, als hätte dein NSC die Finger im Spiel.

Gruß, Marc

Na. Ich will mal ausnahmsweise Positiv denken
Scheint so als wenn das Update inkl. Kontrolle in einer Std getan ist (in unserem Fall)

Hoffe für alle das die Updates alle Reibungslos laufen.