[gelöst] Dimensionen bei Artikel- und Zu-/Abschlagsbuchungen

[SilverX]

Guten Morgen,

Mich treibt folgende Frage um: In einem Beleg wird eine Artikelzeile und eine Zuschlagszeile (zugewiesen auf Artikel) gebucht. Sowohl der Artikel als auch der Zuschlag haben Vorgabedimensionen konfiguriert.

• Artikel: Dimension A, Wert A, Gleicher Code
• Zuschlag: Dimension A, Wert B, Gleicher Code

Im Dynamics NAV Standard ist diese Konstellation nicht erlaubt, da die Zuschlagsbuchung den Dimensionen der Artikelbuchung folgt/folgen soll. Dementsprechend der Zuschlag ebenfalls mit A/A gebucht werden muss.

Die "Verteilung" von Dimensionen ist dann also Artikelposten A/A, Wertposten Artikel A/A und Wertposten Zuschlag A/A.

Meine Frage: Ist dieses Verhalten sinnvoll, gibt es Szenarien, wo das so aus Integritäts- oder Analysesicht notwendig ist? Oder wäre durch Aufhebung der Blockade auch denkbar ggf. sinnvoller, hier dem Nutzer die Freiheit zu lassen auch folgende Konstellation zu erlauben:

• Artikelposten: Dimension A, Wert A
• Wertposten Artikel: Dimension A, Wert A
• Wertposten Zuschlag: Dimension A, Wert B

Danke für eure Meinungen.

Zuletzt geändert von SilverX am 23. Juli 2013 13:26, insgesamt 1-mal geändert.

Moin,

da Zuschläge ein eigenes Kostenelement sind, könnte man sagen warum nicht. Der Nachteil wäre aber, das dann Flowfields evtl. nicht nachvollziehbare Werte zeigen, z.B. Verbrauch (MW) in der Artikelkarte, wenn auf Kostenstelle oder Kostenträger gefiltert wird und diese betroffen sind. Oder eben Artikelanalyseansichten. Deswegen gibt es die Einschränkung. Wenn man sich dessen bewusst ist kann man natürlich diese Einschränkung aufheben. Besser ist es aber wohl die geforderten Werte (B) aus der Dimension A in eine Dimension B unterzubringen und mit zuzuweisen.

LG Jens

Hallo Carsten,

auch ich sehe die größten Probleme beim Kostenträger. Insbesondere wenn der Artikel der Kostenträger ist, müssen natürlich auch die Z/A entsprechend geschlüsselt werden.
Ich finde Jens' Ansatz mit der zusätzlichen Dimension sehr gut.

Viele Grüße
Mike

OK, agree.

Da wir aber wissen, dass Dynamics NAV ein flexibles System ist und letztendlich die korrekten Einstellungen zählen, sollte es da nicht auch hier mehr Flexibilität geben?

Derzeit funktioniert nämlich auch A-A und B-B nicht korrekt, sofern für den Artikel in der Dimension A Gleicher Code angegeben ist...

Hallo Carsten,

öhm... könnte schwieriger werden. Aus CU22, NAV2013 (RU2):

Code:

InsertValueEntry(VAR ValueEntry : Record "Value Entry";VAR ItemLedgEntry : Record "Item Ledger Entry";TransferItem : Boolean)
WITH ItemJnlLine DO BEGIN
  IF TransferItem THEN BEGIN
    ValueEntry."Global Dimension 1 Code" := "New Shortcut Dimension 1 Code";
    ValueEntry."Global Dimension 2 Code" := "New Shortcut Dimension 2 Code";
    ValueEntry."Dimension Set ID" := "New Dimension Set ID";
  END ELSE BEGIN
    IF (GlobalValueEntry."Entry Type" = GlobalValueEntry."Entry Type"::"Direct Cost") AND
       (GlobalValueEntry."Item Charge No." <> '') AND
       (ValueEntry."Entry Type" = ValueEntry."Entry Type"::Variance)
    THEN BEGIN
      GetLastDirectCostValEntry(ValueEntry."Item Ledger Entry No.");
      ValueEntry."Gen. Prod. Posting Group" := DirCostValueEntry."Gen. Prod. Posting Group";
      MoveValEntryDimToValEntryDim(ValueEntry,DirCostValueEntry);
    END ELSE BEGIN
      ValueEntry."Global Dimension 1 Code" := "Shortcut Dimension 1 Code";
      ValueEntry."Global Dimension 2 Code" := "Shortcut Dimension 2 Code";
      ValueEntry."Dimension Set ID" := "Dimension Set ID";
    END;
  END;
  RoundAmtValueEntry(ValueEntry);
...

Frei übersetzt: Ist die Buchung ein Artikelzu/Abschlag, nimm die Dimension des letzten Wertpostens für diesen Artikelposten vom Typ "Einkauf". Die tatsächlich bei der Buchung angegebenen Dimensionswerte sind dann schnurzegal. Wahrscheinlich gibt es je nach Beleg noch Checks vorher, die zu einem Fehler führen. Diese Stelle müsste aber auf jeden Fall angepasst werden.

Soviel zum Thema Flexibilität.

Grüße und schönes Wochenende

Jens

Hallo,

ich habe nochmal etwas tiefer geschaut. Ein Teilproblem ist, das die Vorgabedimensionen der Zu/Abschläge in CU21 nicht mit zur Prüfung herangezogen werden. Das ist einfach behoben. In CU22 ist es dann nicht mehr ganz so einfach.
Das größere Problem ist, das die bisher gebuchten Dimensionen eines Artikelpostens in allen Wertposten so bleiben müssen, damit die Auswertung mittels Flowfields nachvollziehbar funktioniert. Wenn man jetzt für die Zu/Abschläge eine extra Dimension einführt um diese zusätzlich auszuwerten, würde man dieses Prinzip verletzen. Wenn das ok ist, müssten die Dimensionen der Artikelbuchblattzeile aber eigentlich so gebildet werden:

pro Artikelzu/Abschlagszuordnung:
- Hole die gebuchten Dimensionen des Artikelpostens (nicht Wertposten), nimm diese als Basis für die Buchblattzeile.
- Ergänze die Dimensionen die aus der Verkaufs/Einkaufs/Servicezeile mitgegeben werden. Das müsste dann ähnlich wie CreateDim() funktionieren.

Eine ungefähr vergleichbare Logik existiert in CU12 zur Erzeugung von detaillierten Posten mit InitNewCVLedgEntry() und InitOldCVLedgEntry(). Alle Felder die wegen der Flowfields gleich bleiben müssen stecken in InitOldCVLedgEntry().

Diese Lösung ist dann schon recht aufwendig, wäre aber flexibel in der Anwendung. Und oben erwähnter Vorschlag funktioniert auch leider nur dann.

LG Jens

Danke euch, speziell dir Jens, für deine Mühe. Ich habe mich so lange nicht gemeldet, da ich noch Antworten abwarten wollte und auch (leider) etwas viel Arbeit habe

Jens, deine Hinweise und Schlussfolgerungen sind gut und hilfreich. Letztendlich war der Grund für diesen Post die Frage eines Partners bzw. seines Kunden bzgl. der Kollision von Vorgabedimensionen zu Artikeln und Zu-/Abschlägen. Letztlich gibt es verschiedene Varianten, so etwas abzubilden, der Standard hält sich hier an die Devise: Nehme die Vorgabe- bzw. eingerichteten Dimensionen für den Zu-/Abschlag, es sei denn, diese kollidieren mit denen der zugehörigen Artikelzeile, dann zeige einen Fehler

Die "Lösung" oder Einigung letztendlich war folgende: Wertposten müssen immer die Dimensionen des zugehörigen Artikelpostens erben, spezielle Dimensionen des Zu-/Abschlags werden ignoriert. Damit wird die Konsistenz über alle am Artikelposten hängenden Wertposten und drauf basierenden Analysen sichergestellt.

Selbstverständlich gäbe es andere Möglichkeiten und Wege, aber das war die Entscheidung des Kunden. Ich setze den Beitrag mal auf gelöst.

Nochmals Danke!

Die "Lösung" oder Einigung letztendlich war folgende: Wertposten müssen immer die Dimensionen des zugehörigen Artikelpostens erben, spezielle Dimensionen des Zu-/Abschlags werden ignoriert. Damit wird die Konsistenz über alle am Artikelposten hängenden Wertposten und drauf basierenden Analysen sichergestellt.

Dabei nicht vergessen, dass das dann auch für alle bei der Lagerregulierung zusätzlich erzeugte neue Wertposten gelten muss.