Rep. Lagerbew.-Einst.-Pr.-Ermittl. - seltsames Verhalten

hi, ich hatte jetzt mal mit dem report 5801 (Lagerbew.-Einst.-Pr.-Ermittl.) zu tun und folgendes festgestellt: bin in einem navision 5.0sp1, wobei der report bei mir noch die versionsnummer NAVW14.00.02 aufweist.

setze ich keinen artikelfilter, dann hat lediglich der erste artikel bei lagerwert pro einheit und bei betrag etwas stehen (bei genauerer forschung steht dort der letzte tatsächliche einstandspreis von den zeilen des ersten artikels, die der sortierung/filterung entsprechen; müsste da nicht wenn auch eine summe aus den zeilen stehen?).

alle weiteren artikel bekommen bei lagerwert pro einheit eine 0 und bei betrag auch. filter ich nun explizit auf einen artikel, der bei dem lauf ohne filterung 0 drin stehen hatte, hat nun dieser wert beträge, und zwar wiederum exakt die aus der letzten zeile der filterung wie oben beschrieben.

schaue ich mir den report in einer 5.0sp1 cronus db an, steht bei version auch noch eine 4er... und auch dort hat nur der erste artikel einen wert!
wobei.. wenn man etwas runterscrollt erscheinen noch seltsame zeilen mit abweichung, die dann plötzlich doch auch einen wert haben, aber der großteil hat alle beträge 0, bis auf die erste zeile.


was ist hier los? funktioniert das bei jemandem? wie müsste der report funktionieren?


grüße,
daniel

Die Postenart "Abweichung" gibt es nur bei Artikeln mit Lagerabgangsmethode "Standard", das ist die Differenz zwischen dem angesetzten "Einstandspreis (fest)" und dem tatsächlichen Einkaufspreis. Bei den anderen Lagerabgangsmethoden gibt es diese Wertpostenart nicht.

Ob ein Wertposten im Lagerwert im Report berücksichtigt wird, hängt von dessem Bewertungsdatum ab. Dieses taucht auch als "Buchungsdatum" bei den Artikelausgleichsposten auf, die bei den Artikelbewegungen erzeugt wurden. Diese werden beim Reportlauf ermittelt und die Werte der dazugehörigen Wertposten saldiert. Alle Posten, die ein Datum nach dem Bewertungsdatum haben, das unter "Optionen" eingeben wird, werden nicht mehr berücksichtigt.
Dadurch lässt sich die Entwicklung des durchschnittlichen Einstandspreises für jeden Tag in der Vergangenheit nachvollziehen. Das war eine wichtige Neuerung ab Version 3. In Version 2 war das nicht möglich, da hier nur die Posten mit Restmenge für die Ermittlung des Durchschnitts herangezogen wurden. Ab Version 3 wird immer alles ab dem ersten Posten saldiert. Es bedeutet aber auch, dass u.U. uralte Fehlbuchungen im Gegensatz zu früher den aktuellen Durchschnitt beeinflussen können.

Die Versionsnummer ist richtig, die wird nur normalerweise nur aktualisiert, wenn das Objekt eine Änderung erfährt (so sollte das zumindest sein, beim Mergen merkt man , dass sich der Standard nicht immer daran hält).

alle weiteren artikel bekommen bei lagerwert pro einheit eine 0 und bei betrag auch. filter ich nun explizit auf einen artikel, der bei dem lauf ohne filterung 0 drin stehen hatte, hat nun dieser wert beträge, und zwar wiederum exakt die aus der letzten zeile der filterung wie oben beschrieben.

Nach der Theorie aus meinem letzten Beitrag nun noch etwas Praxis .
Der Report mit Version 4.00.02 hat mehrere Bugs,ist so wie ausgeliefert völlig unbrauchbar . Der Filter auf "Entry Type" muss in der Funktion CalcUnitCost am Ende wieder entfernt werden (entdeckt von unserem Forumsmitglied fiddi), dann verschwinden die Null- und Falschwerte. Außerdem sind noch weitere Korrekturen erforderlich, siehe KB927354 und KB950366.

Code:

  PROCEDURE CalcUnitCost@2();
    .....
              NoOfEntries["Entry Type" + 1] := 1;
            END;
          END;
        SETRANGE("Entry Type"); // Filter lösen !
      END;
    END;