Speicherüberlauf bei Lagerregulierung (R 795) in BC14

Hallo,
einer unserer Kunden kann für einen bestimmten Artikel die Lagerregulierung zu fakturierten Einstandspreisen nicht mehr aufrufen. Es kommt diese Fehlermeldung (s.Anhang).
Dass die Lagerregulierung in einer Endlosschleife hängt, ist auf den ersten Blick jetzt nicht zu erkennen.
Beim Debuggen fällt auf, dass immer wieder die Funktionen ForwardCostToOutbndEntries und ForwardCostToInbndEntries in der CU 5895 aufgerufen werden. Ich konnte allerdings nicht erkennen, ob sich Artikelposten wiederholen (bin mir auch nicht sicher, ob das problematisch ist). Es scheint so, als wenn wie wild Posten gegeneinander ausgeglichen werden und irgendwann der Stapel überläuft.
Mir fällt allerdings gerade keine Möglichkeit ein, wie ich den problematischen Posten bzw. die problematischen Posten eingrenzen könnte. Hat irgendjemand hier eine Idee?

@Edit:
Für den Artikel gibt es momentan 520 Ausgleichsposten. Ich habe leider keine Vorstellung, was da normal ist. Im Moment sieht es so aus, als wenn schlicht und ergreifend zu viele Posten vorhanden sind. Aber eigentlich sollte doch programmseitig verhindert werden, dass die Anzahl der Rekursionen ein bestimmtes Level übersteigt (beim Abbruch beträgt der Wert für LevelNo[3] 42).

Code:


LOCAL ForwardAppliedCost(ItemLedgEntry : Record "Item Ledger Entry";Recursion : Boolean) AppliedQty : Decimal
WITH ItemLedgEntry DO BEGIN
  // Avoid stack overflow, if too many recursions
  IF Recursion THEN
    LevelNo[3] := LevelNo[3] + 1
  ELSE
    LevelNo[3] := 0;

  IF LevelNo[3] = MaxLevels THEN BEGIN
    SetAppliedEntryToAdjust(TRUE);
    LevelExceeded := TRUE;
    LevelNo[3] := 0;
    EXIT;
  END;


@Edit
Mir ist da jetzt noch eine Sache aufgefallen; Die Lagerregulierung bleibt bei einem bestimmten Artikelposten hängen. Der wiederum gehört zu einer gebuchten Gutschrift in der ein- und derselbe Artikel 84 Mal eingetragen wurde. Mal davon abgesehen, dass sich mir der Sinn dahinter nicht erschließt, könnte das das Problem verursachen und v.a., welche Möglichkeit hätte man, es zu beheben? Gesetzt der Fall, man würde die Gutschrift stornieren, würden vmtl. noch mehr Posten erzeugt werden, über die die Lagerregulierung läuft.

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

Zuletzt geändert von FragenFrager am 11. März 2026 16:38, insgesamt 3-mal geändert.

Hallo,

es kann eigentlich nur sein, was nicht sein kann, dass ein Artikelposten sich mit sich selbst ausgleicht, oder ein Artikel sich als ein Bestandteil einer Stückliste sich selbst produziert.

Das muss nicht nur ein Artikel sein, das kann auch sein, das ein Artikel eine Stückliste hat, die einen Artikel enthält, der wiederum den Zielartikel als Komponente enthält, oder auch über noch mehr Ebenen.

Gruß Fiddi

Ich habe schon geguckt, ob es für den Artikel Posten gibt, bei denen Ausgleich mit laufender Nummer = laufende Nummer des Artikelpostens, kein Treffer.
Stücklisten verwendet der Kunde nicht.
Ich bin am Überlegen, ob ich den OnInsert-Trigger der Tabelle 339 abonniere und die während der nicht funktionierenden Lagerregulierung neu erstellten Datensätze in eine separate Tabelle kopiere, um mal zu schauen, wie viele Datesätze erzeugt werden, ob es Wiederholungen gibt, irgendwo Eingehender Artikelposten = Ausgehender Artikelposten usw.. Ob das nun allerdings so sinnvoll ist, keine Ahnung.

Hallo,

das ist keine schlechte idee.

Es gab da mal irgendwo eine Lösung um abgebrochene Fibu-Buchungen zu prüfen.

Die basiert auf einer temporären Tabelle in einer Single- Instance Codeunit. Die überlebt auch einen Error, und du kannst dir hinterher die gespeicherten Daten anschauen, indem du aus der Codeunit heraus eine Page mit der temporären Tabelle aufrufst . Das geht u.U. schneller als Stundenlang mit dem Debugger Ausgleichsfolgen hinterher zu rennen.

Gruß Fiddi

Hallo fiddi,
danke für den Hinweis. Ich habe als "Vorübung" eine Hook-Codeunit erstellt, die einfach den OnAfterInsert-Trigger der Tabelle 339 abonniert, einen entsprechenden Breaktpoint gesetzt und die Lagerregulierung zu fakturierten Einstandspreisen mit Debugger aufgerufen. Leider wird der Trigger nicht durchlaufen, vor dem Abbruch werden also anscheinend keine neuen Ausgleichsposten für diesen Vorgang erzeugt (kann das sein)?

Hallo,

er dürfte sich wahrscheinlich schon beim Finden der auszugleichenden Posten die Karten legen.

Schräge Idee, ich weiß auch im Moment nicht wo einzubauen:

Mach dir eine temporäre Variable mit der Integer Tabelle (ich glaube das funktioniert mit der Systemtabelle, ansonsten eigene Tabelle) dort fügst du für jeden Posten den er ausgleichen möchte, die Postennummer ein, und wenn er eine Postennummer ein zweites mal einfügen möchte, lässt du ihn beim Insert einfach auf den AlreadyExists- Fehler laufen, den du dann mit dem Debugger abfängst.

Gruß Fiddi

Hallo fiddi,
ich habe das OnForwardAppliedCostOnAfterSetAppliedQty-Event in der CU5895 abgegriffen und bin so verfahren, wie von Dir vorgeschlagen. Leider gab es da keine Doppelung. Trotzdem danke, die Idee hat schon Charme, vielleicht kann ich die ein anderes Mal brauchen (sofern ich nicht aus Frust über diesen Sch... auf Gänseblümchen-Züchter umschule )

Es gibt da in der Tabelle 339 die Funktion GetVisitedEntries. Ich habe mir mal eine Page gebastelt, welche die Tabelle 32 temporär als Sourcetable verwendet. Mit der als VAR-Parameter rufe ich diese Funktion auf und bekomme dann, ausgehend von einem Start-Artikelposten anscheinend alle Artikelposten, die über Ausgleiche mit diesem verknüpft sind (direkt oder transitiv).
Weiterhin gibt es da noch einige Funktionen in der Tabelle 339, die mit CheckCyclic bzw. CheckIsCyclical beginnen, die könnten in dem Zusammenhang auch interessant sein. Allerdings steige ich im Moment noch nicht so ganz durch, inwieweit über diese Funktionen verändernd auf die Postentabellen zugegriffen wird. Weiß das evtl. jemand so?