Dynamics User Group - Archived Forums

The forums in this section of DUG are no longer accepting new post, but you can still get lots of value from the old posts here.
Please visit the active forums to comment/post new questions (choose which product you are interested in):


Neuplanung in 5.0 SP1

Hallo, mit SP1 ist eine ziemliche Umstellung des Planungsablaufs durchgeführt worden. Ich habe folgendes Problem: bei der Planung eines Artikels mit 2 Lagerhaltungsdaten, wird der Bedarf - soweit ich das mitverfolgen konnte - richtig aufgebaut. Beim Aufbau der Bedarfsdeckung geht solange alles gut, bis Navision zum Artikel mit 'Fester Bestellmenge' kommt. Nav stellt fest, dass einige Stück fehlen und kommt zum Trigger, Adjustreorderquantit und führt dabei die Supply.line no. mit. Allerdings gehts von da zu einer Codeunit (990000856), die die Menge nicht anüaßt, sondern ein insert versucht. Da die Line no. (primary key) schon vorhanden ist, kommt eine Fhlermeldung und tilt. Hat jemand dieses Problem auch schon gehabt. Michael
  • hallo!

     

    Wie bereits vorhin per Email besprochen. Ich sehs mir heut abend mal an und geb Feedback. Vielleiht kommt j hier auch noch was anderes "rein".

    LG

    Rene

  • In reply to ReGa:

     Ich hbae mir den Code noch einmal näher angeschaut (CU 990000854). Im Abschnitt nextstate:matchqty wird demand."untracked qty" - supply."untracked qty" berechnet ("untracked qty" = Menge ohne Bedarfsverursacher?). In meinem Beispiel ergibt sich ein Wert von 33 (ist dann neededqty). Von hier aus geht's zum Trigger IncreaseQtyToMeetDeman, um Increaseqty mit Supply und neededqty aufzurufen. Dieser Trigger ruft wiederum AdjustReorderQty auf. Hier wird abgefragt SKU."Order Multiple" <> 0 und neededqty (33) auf den Losgrößenrundungsfaktor (10) gerundet = Delta = 7. Dies ist der Ausgangspunkt, um nach CU 99000856 zu verzweigen, und dann erfolgt eben der Veruch, ein Insert mit der Zeilennummer der Supply-Zeile, deren menge erhöht werden soll, zu starten.

  • In reply to Quasimodo:

    Hi sorry war gestern abend kurzsfristig verhindert. seh es mir heut noch an

    lg

    rene

     

  • In reply to ReGa:

    hi,

    also hab mit deinem dataport das in eine 5.0 sp1 cronus ag importiert.

    btw. danke das hat viel arbeit erspart!

    hab allerdings trotz aller versuche die planung zu beeinflussen

    • - lagerbestand vorher und nachher geändert
    • - Aufträge angelegt
    • - bestellungen angelegt

    und nach den Änderungen jeweils die Planung durchgeführt den Fehler nicht bekommen. Sad

    Du hast allerdings bei einem Lager als Beschaffungsmethode Fertigungsauftrag hinterlegt.Ich habe aufgrund deines Setups keine Fertigungsstückliste.

    Ich nehme an du hast eine? Vielleicht machst das noch den Unterschied aus das ich den Fehler nicht krieg?

    Hast du eine ? Kannst du mir sagen wie es also um die Komponenten steht? Hast du es schon in einer CRONUS DB probiert?

    LG,

    Rene

     

     

     

     

  • In reply to ReGa:

     Hi Rene,

     

    vielen Dank für den Einsatz. Ich habe von 'hinten' angefangen und mich dann bis zum Merge von 4.0 SP03 vorgearbeitet. Dort mußte ich feststellen, dass beim Merge - obwohl keine Änderung war - der Primary Key verstümmelt wurde (Table 99000854). Wir sind noch in der Testphase, aber muss ich damit rechnen, dass dies ein Feature des Developer Tools ist?

     

    Noch einmal vielen Dank

    Michael

  • In reply to Quasimodo:

    Hallo!

     Kein Problem, gerne!

    Also mir wäre nichts bekannt das dies ein Fehler ist, allerdings muss man beim Merge von Objekten immerr vorsichtig sein.....

    Heißt mit dem richtigen PK gehts jetzt? Falls kleine Tipp: versuche immer es mal in einer Standarddb anchzuvollziehen. Damit kann man sowas oft schnell eingrenzen!!

    LG

    Rene

    PS lso bleib der Community hier weiterhin treu, auch wenn du es selbst gelöst hast! ;-)

Related