[GELÖST]Dimesion Kostenstelle in Vk-Aufträgen

Hallo Liebes Forum!

wenn ich in einem Verkaufsauftrag im Kopfbereich eine Kostenstellen eingebe und danach einen Verkäufercode auswähle wird die Kostenstelle wieder geleert.

Auf dem Verkäufer sind keine Dimensionen zugeordnet und im System sind auch keine Tabellenvorgabedimensionen hinterlegt.

Ist das ein Fehler oder gibt es hierfür eine Erklärung?

PS: ich habe es auch in der Cronus-Datenbank getestet, läuft genau so.

NAV-Version = 2013 RTM

Ursache ist die u.s. Funktion die aus dem Trigger "Salesperson Code - OnValidate()" aufgerufen wird. Hier werden die Felder "Shortcut Dimension 1 Code" und ""Shortcut Dimension 2 Code" geleert!

Unbenannt.jpg

Vielen Dank!
Gruß Kamkams

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

Zuletzt geändert von KAMKAMS am 8. Mai 2014 22:01, insgesamt 1-mal geändert.

Hallo Liebes Forum!

wenn ich in einem Verkaufsauftrag im Kopfbereich eine Kostenstellen eingebe und danach einen Verkäufercode auswähle wird die Kostenstelle wieder geleert.

Auf dem Verkäufer sind keine Dimensionen zugeordnet und im System sind auch keine Tabellenvorgabedimensionen hinterlegt.

Ist das ein Fehler oder gibt es hierfür eine Erklärung?

PS: ich habe es auch in der Cronus-Datenbank getestet, läuft genau so.

NAV-Version = 2013 RTM

Ursache ist die u.s. Funktion die aus dem Trigger "Salesperson Code - OnValidate()" aufgerufen wird. Hier werden die Felder "Shortcut Dimension 1 Code" und ""Shortcut Dimension 2 Code" geleert!

Unbenannt.jpg

Vielen Dank!
Gruß Kamkams

Hab grad kein NAV 2013, aber NAV 2009 CC: gleiches Verhalten.

VK-Auftrag Kopf, KST = 3110, Artikel 70000, KST = 3110
Sobald Verkäufercode geändert, ändert sich auch die KST = VERKAUF
Habe dann per Shift + F5 die Karte des Verkäufers aufgemacht und auf dem Reiter ... steht KST und KTR.
Diese werden bevorzugt genommen und überschreiben die vorherige KST.
Hatte der Verkäufer KST = leer, wird diese trotzdem genommen und überschreit in meinem Bsp. die vorherige 3110.

Abhilfe schafft hier wohl nur das Ganze so zu programmieren, dass die KST des Verkäufers ignoriert wird.

Oder alternativ: hinter dem Debitor einen Verkäufercode zu hinterlegen, der wiederum eine bzw. gar keine KST hat.
Erst nachdem im VK-Auftragskopf die DebitorNr eingetragen wird, validiert das NAV und zieht den Verkäufercode.
Danach kann man bedenkenlos die korrekte KST eintragen, z.B: 3110.

Hatte der Verkäufer KST = leer, wird diese trotzdem genommen und überschreit in meinem Bsp. die vorherige 3110.

Das Überschreiben einer bestehenden Vorgabedimension kann man über die Vorgabedimensionsprioritäten verhindern (FiBu -> Einrichtung -> Dimensionen -> Standarddimension Prioritäten). Man muß nur wissen, welcher Herkunftscode bei welchen Aktionen gesetzt wird.

Hier geht es wohl darum, daß keine Vorgabedimension gesetzt ist, wenn ich das richtig verstanden habe. In dem Fall nützen einem auch die Prioritäten nichts, da von einer etwaigen höheren Priorität keine Vorgabe kommt. Selbst wenn man Code notwendig mit leerem Dimensionswertcode auf dem Debitoren setzt, wird die manuelle Dimension trotzdem wieder entfernt. Einziger Vorteil ist dann, daß man im Nachgang eine Fehlermeldung bekommt, wenn die Dimension fehlen sollte.

Hatte der Verkäufer KST = leer, wird diese trotzdem genommen und überschreit in meinem Bsp. die vorherige 3110.

Das Überschreiben einer bestehenden Vorgabedimension kann man über die Vorgabedimensionsprioritäten verhindern (FiBu -> Einrichtung -> Dimensionen -> Standarddimension Prioritäten). Man muß nur wissen, welcher Herkunftscode bei welchen Aktionen gesetzt wird.

Hier geht es wohl darum, daß keine Vorgabedimension gesetzt ist, wenn ich das richtig verstanden habe. In dem Fall nützen einem auch die Prioritäten nichts, da von einer etwaigen höheren Priorität keine Vorgabe kommt. Selbst wenn man Code notwendig mit leerem Dimensionswertcode auf dem Debitoren setzt, wird die manuelle Dimension trotzdem wieder entfernt. Einziger Vorteil ist dann, daß man im Nachgang eine Fehlermeldung bekommt, wenn die Dimension fehlen sollte.

Auch wenn es etwas peinlich ist, aber ich gebe zu, dass ich das nimmer weiss, wo man das parametrisiert:


Man muß nur wissen, welcher Herkunftscode bei welchen Aktionen gesetzt wird.


Wo konfiguriere ich: IF VK-Auftrag THEN Herkunfstcode = 'VK-Auftrag'; IF Verkäufer THEN Herkunftscode = 'Verkäufer'?

Thx!


EDIT: unter FiBu -> Einrichtung -> Dimensionen -> Standarddimension Prioritäten sehe ich oben "Buchunngsspurcode" als Filter. (in der DEU DB nennt sich das Ursachencode).
Sobald ich Verkauf wähle, sehe ich als Prio: 1. Debitor 18, 2. Artikel 27
=> bedeutet das, dass wenn ich hier 1. Sales Header und als 2. SalesPerson eintrage, dann würde die KST von SalesPerson nie einen KST-Eintrag von SalesHeader überschreiben?

Ich finde das überhaupt nicht peinlich. Passiert mir ständig, daß ich nicht mehr weiß, wo man bestimmte Aktionen macht. NAV ist auch einfach zu umfangreich, um immer alles sofort präsent zu haben. Wichtig ist, daß man weiß, daß es irgendwie geht und den Rest kann man nachgucken.

EDIT: unter FiBu -> Einrichtung -> Dimensionen -> Standarddimension Prioritäten sehe ich oben "Buchunngsspurcode" als Filter. (in der DEU DB nennt sich das Ursachencode).

Buchungsspurcode ist in der Tat der Schweizerische Begriff. Im Deutschen sollte es eigentlich Herkunftscode heißen. Ursachencode (Reason Code) ist da meiner Meinung nach falsch, denn es sollte eigentlich auf Source Code basieren.

Den Herkunftscode richtet man ein unter FiBu -> Einrichtung -> Verfolgungscodes -> Herkunftscodes bzw. Herkunftscode Einrichtung. Auf den Buch.-Blattvorlagen kann man allerdings nochmal extra welche angeben.

Sobald ich Verkauf wähle, sehe ich als Prio: 1. Debitor 18, 2. Artikel 27
=> bedeutet das, dass wenn ich hier 1. Sales Header und als 2. SalesPerson eintrage, dann würde die KST von SalesPerson nie einen KST-Eintrag von SalesHeader überschreiben?

Leider kann man hier nicht den Verkaufskopf angeben. Damit wäre ja das ursprüngliche Problem gelöst. Es lassen sich im Prinzip nur Vorgabedimensionen von Stammdaten auswählen. Diese kann man dann weiter mit einer Priorität versehen. Heißt also für das konkrete Standardbeispiel (Debitor 1, Artikel 2): Wenn sowohl auf dem gewählten Debitoren als auch auf dem gewählten Artikel eine Dimensionen mit einem Vorgabewert belegt ist, dann wird im Auftrag immer die Vorgabedimension des Debitoren genommen. Unabhängig von der Reihenfolgen, in der die Felder validiert werden.

Oder anders ausgedrückt, in oberster Instanz gelten immer die Vorgabedimensionen des Debitoren, danach erst die des Artikels und dann die aller anderen Stammdaten. Heißt also, wenn man das so eingerichtet hat und bei Debitor und Artikel keine Kostenstelle eingetragen hat, dann gelten die der anderen Stammdaten, die man validiert (z.B. Verkäufer, Projekt,...). Diese Überschreiben sich dann aber auch gegenseitig, je nachdem welches Feld als letztes validiert wird.