[Gelöst] Upgrade Dimensionen in DimensionSetID

[tjane]

Hallo,

hat bereits jemand ein Update auf 2013 vorgenommen und musste dabei eine Anpassung implementieren,
welche es dem User erlaubt, nachträglich Dimensionen in gebuchten Posten zu ändern?

Bisher war es so, dass die Funktion für jeden Posten einzeln aufgerufen wurde
(die Korrektur hat also nicht alle zugehörigen Posten selbstständig gesucht).

Da es ja nun die neue DimensionSetID gibt, bedeutet dass, das ich den entsprechenden Set per DimSetID des Postens in der Tabelle 480 suche und die gewünschten Dimensionen ändere. Zusätzlich werden mittels der Korrekturfunktion alle Posten mit der gleichen DimSetID gesucht und die enthaltenen Werte in den Feldern KST und KTR geändert (also Sachposten, Debitorposten, usw.).

Getestet und für besser befunden, da der User nun nur 1 Korrektur eingibt und alle Posten korrigiert werden, die es betrifft.

In der Echt-Test-DB ist mir nun aber aufgefallen, dass sich die Korrektur aufhängt, bzw. ewig braucht.
Dabei habe ich nun nach der Ursache gesucht und zu einer Dimension-Set-ID in diesem konkreten Beispiel 529 Sachposten gefunden.
Aus verschiedenen Jahren mit unterschiedlichen Belegnummern, die überhaupt nicht zusammen gehören.

Ändert die Funktion nun die Dimensionen in der Tab 480, erhalten logischerweise alle Posten mit der gleichen ID
die geänderten Dimensionen, obwohl das überhaupt nicht sein sollte.

Frage: Fehler in der Updateroutine? Ich konnte mich noch nicht bis zur letzten Codezeile durcharbeiten. Vergibt er etwa für alle Sachposten, die die gleiche Kombination an Dimensionen haben sie gleiche DimSetID? (so sieht es für mich auf den ersten Blick aus)

Zuletzt geändert von tjane am 27. Februar 2013 15:22, insgesamt 1-mal geändert.

Vorsicht, guck dir das Prinzip z.B. aus den Intercompany-Codeunits (kann dir gerade leider keine Objekt-ID nennen. Evtl. schau dir mal an, wie die Page zum Bearbeiten von Dimensionen geöffnet und mit temp. Records gefüttert wird).

Geändert wird (seit 2013) niemals direkt in den Dimensionstabellen. Stattdessen erstellst/editierst du nur temporäre Dimension-Records. Diese werden einer Standardfunktion übergeben, welche dir eine DimensionSet-ID zurückliefert (ob die alte beibehalten wird oder eine neue generiert wird, entscheidet NAV). Diese ID musst du dann in deinem Zielrecord speichern.

OK,

das bedeutet dann aber, dass eine Änderung nur Posten für Posten möglich ist? (Und jeder Posten bekommt dann u.U. eine eigene DimSetID? --> ich probiere mal ...)

das bedeutet dann aber, dass eine Änderung nur Posten für Posten möglich ist? (Und jeder Posten bekommt dann u.U. eine eigene DimSetID? --> ich probiere mal ...)

Die Änderung muss tatsächlich für jeden Posten einmal durchgeführt werden. Wahrscheinlich (?) wird aber NAV für die nachfolgenden Posten dieselbe DimSetID zurückgeben wie für die erste, sofern die Dimensionen identisch sind. Es wäre mir wichtig, dass du das durch deinen Test einmal bestätigen könntest - danke.
Falls immer dieselbe DimSetID herangezogen wird, könnte man den Prozess sicherlich verkürzen, indem man nur beim ersten Posten das gesamte Prozedere durchläuft und für alle weiteren Posten nur MODIFYALL(DimSetID,...) absetzt. Ich bin da nur sehr vorsichtig, da es auch eine Dimensions-Hiercharchie-Tabelle gibt und ich nicht weißt, wie die arbeitet.

OK, also ...

eine DimensionsSetID steht für eine bestimmte Kombination an Dimensionen (=Dimension Set). Dabei ist es unerheblich, in wievielen Belegen diese Kombination verwendet wird. Weist man einem Beleg eine Kombination zu, die es bereits gibt, so bekommt der Beleg die DimSetID des bereits vorhandenen DimSets.
Diese Prüfung wird von der Page 480 angestoßen (Dimensionswerte editieren). Das steht auch so in der Hilfe beschrieben, aber ich hatte bei der Übersetzung ins Deutsche das Ganze wohl fehlinterpretiert. Ich hatte angenommen, dass DimensionSets je Beleg erstellt werden.
Daher sind die mehrfachen DimSetIDs in den upgedateten Sachposten völlig korrekt.

Wenn ich jetzt also eine Dimension für einen Posten ändere, schaut NAV: gibt es die Kombi schon, wenn ja, wird die vorhandene ID zugewiesen. Wenn Nein wird ein neuer DimensionSet erstellt und die neue DimSetID zugewiesen.

Demnach bekommt der nächste Posten, den ich ändere, auch die gleiche ID, wie der erste geänderte Posten, vorraussgesetzt, die Dimensionen stimmen überein.

(Wenn ich die 2. Änderung sparen möchte, müsste ich alle zugehörigen Posten per Code suchen und die DimSetID ändern, was ich in meinem Fall nicht einprogrammiere. Ich belasse es bei der Posten-für-Posten-Änderung, wie es bisher auch gehandhabt wurde.)

Dazu habe ich jetzt doch noch eine Frage.

In dieser Anpassung wird zwar jeder Sachposten separat vom User geändert, aber die zugehörigen Debitor-, Kreditorposten (usw.) werden anhand der lfd. Nr. gesucht und geändert. (Sprich if CLE.get(GLE."Entry No.") then ...)
Ist es tatsächlich so , dass die laufende Nr. des Sachposten immer gleich der laufenden Nummer des Debitorpostens, etc. ist ? (Natürlich gibt es nicht zu jedem Sachposten einen Debitorenposten, in diesem Fall zu dem des Forderungskontos).

Stichprobenartig kann ich das bestätigen. Konnte auch Lücken in der lfd. Nr. der Debitorenposten finden, die sich ja logischerweise daraus ergeben müssen, wenn dem so ist.

Da ich das zum ersten Mal sehe, möchte ich lieber sichergehen, bevor ich das so update. (Wenn ja, ist es in 2013 immer noch so? Ich traue meinen Stichproben nicht ganz .)

Ist es tatsächlich so , dass die laufende Nr. des Sachposten immer gleich der laufenden Nummer des Debitorpostens, etc. ist

Das ist DEFINITIV nicht so

Zumindest nicht im NAV- Standard. Was soll denn mit den Kreditorenposten passieren, werden die nicht auf Sachkonten gebucht und erzeugen keine Sachposten?

Es darf auch keine Lücken in den Debitorenposten geben. Es sei denn Sie sind komprimiert worden, was man aber auch vermeiden sollte.

Gruß, Fiddi

Es ist (zumindest unter NAV 5 SP1) eher umgekehrt:
Der Debitorenposten erhält die Lfd. Nr. des Sachpostens mit dem Forderungskonto.
Somit sind die Lfd. Nr. des Hauptbuchs (Sachposten) lückenlos, die in den Nebenbüchern (Debitoren-/Kreditorenposten) enthalten entsprechende Lücken.

Es ist (zumindest unter NAV 5 SP1) eher umgekehrt:
Der Debitorenposten erhält die Lfd. Nr. des Sachpostens mit dem Forderungskonto.
Somit sind die Lfd. Nr. des Hauptbuchs (Sachposten) lückenlos, die in den Nebenbüchern (Debitoren-/Kreditorenposten) enthalten entsprechende Lücken.

Genauso hatte ich es gemeint.

Es ist (zumindest unter NAV 5 SP1) eher umgekehrt:
Der Debitorenposten erhält die Lfd. Nr. des Sachpostens mit dem Forderungskonto.
Somit sind die Lfd. Nr. des Hauptbuchs (Sachposten) lückenlos, die in den Nebenbüchern (Debitoren-/Kreditorenposten) enthalten entsprechende Lücken.

Genauso hatte ich es gemeint.

Dabei natürlich beachten, dass sich auch die Sachposten komprimieren lassen , dann sind da ggf. auch Lücken.