habe eine Frage zur Stützstellenfortschreibung im Bestandscube 0IC_C03 (habe OSS und Google schon ausgiebig durchforstet):

Bei uns wird in dem besagtem Cube 0IC_C03 zu jeder Materialbewegung scheinbar eine Stützstelle angelegt (0RECORDTP = 1 und CALDAY = 31.13.9999) sowie jede Materialbewegung als „richtiger“ Bewegungssatz (0RECORDTP = 0 und CALDAY = Datum des Materialbelegs).

Ist das so korrekt bzw. das gedachte Konzept der Stützstellenfortschreibung?

Die Initialbeladung indes ist korrekt, die ist je Material und Werk und Lager (aber OHNE Materialbeleg) abgelegt und stimmt von der Menge auch mit dem Bestand aus dem Quellsystem vom Tag der Beladung in die PSA überein.

Frage: Sollte diese Initialbeladung nicht als Stützstelle für die zukünftigen Bewegungen immer wieder aktualisiert werden, so dass man immer den aktuellen Bestand (nach der Komprimierung) hat und davon lediglich die Bewegungen der Vergangenheit abziehen, falls der Bestand der Vergangenheit gewünscht ist?

Aufgefallen ist es uns, da die Performance der Queries recht schlecht ist. Ich vermute, dass beim Query-Aufruf nun alle Stützstellen, die wie gesagt bei jeder Materialbewegung angelegt werden, aufaddiert werden und daher die Performance recht schlecht ist.

Würde es Sinn machen, falls die bei uns vorhandene Logik doch korrekt ist, Aggregate für den Cube zu erstellen um die Zugriffszeiten der Queries zu verbessern?

Vielen Dank vorab für jegliche Hilfe! :)

VG

Arnold

die Initialbeladung wird ja durch das Delta automatisch aktualisiert oder nicht?

http://www.denisreis.com/how-to-sap-bi-aggregate/ 

http://www.denisreis.com/how-to-sap-bi-infocube-modellierung/ 

Viele Grüße

Denis

vielen Dank für Deine Unterstützung!

Die Initialbeladung wurde und wird eben leider nicht aktualisiert nach Delta bzw. Komprimierung (das hatte ich im ersten Beitrag nicht ganz eindeutig formuliert, sorry).

Das scheint der springende Punkt zu sein, oder? Aber wie kann das passieren? Die Stützstellenfortschreibung bei der Komprimierung ist aktiviert (kein Haken gesetzt) und in der Prozesskette ist diese Einstellung auch richtig gesetzt.

Statt die Initialbeladung (bzw. also die Stützstelle) zu aktualisieren, wird für jede Materialbewegung eine separate Stützstelle angelegt (0RECORDTP = 1 und CALDAY = 31.13.9999), wo dann auch die Nummer des Materialbelegs hinterlegt ist (zusätzlich wird jede Materialbewegung mit Datum der Bewegung abgelegt, was m.E. das korrekte Vorgehen ist).

Hast das jemand schon mal gehabt? Oder eine Idee, woran das liegen könnte?

Bin dankbar für jeden Tipp :)

Viele Grüße

Arnold

fällt mir leider spontan nichts ein.

Wie schaut es denn im Quellsystem aus? Wäre vllt einen Versuch Wert sich das Delta im Quellsystem anzuschauen.

Viele Grüße

Denis

Viele Grüße

Denis

Es kann ja richtig sein, weil es als Bestandskennzahl modelliert ist.

Was meinst Du damit, es kann richtig sein? In welchen Fällen denn?

Für Bestandskennzahlen habe ich das so verstanden, dass die Stützstelle nach dem Komprimieren den aktuellen Bestand darstellt und die Bewegungen dann zur Berechnung vergangener Bestände genutzt wird. Wann kann es richtig sein, dass jede Bewegung als Stützstelle abgelegt wird? Oder habe ich Dich da missverstanden? ;)

Bei uns sind die Bestandskennzahlen als "Bestandsgröße mit Zugang/Abgang" definiert.

Aber entspricht es nicht dem hier beschriebenen Verhalten?

https://help.sap.com/saphelp_nw73ehp1/helpdata/de/4a/8fc05a63e138dce10000000a42189b/frameset.htm 

Aber die Performance ist sehr schlecht, auch (oder besonders) wenn man auf den Bestand des aktuellen Tages auswertet. Das liegt daran, dass die Initialbeladung (also die Stützstellen) nie aktualisiert wurden. Um dann den aktuellen Bestand zu berechnen, nimmt das System eben diese Initialbeladung und addiert alle Bewegungen (die ja auch ALLE als Stützstellen abgelegt wurden, also mit 31.12.9999 und 0RECORDTP = 1) dazu. Richtig aber wäre, dass die Stützstellen der Initialbeladung nach dem Komprimieren immer den aktuellen Bestand abbilden, richtig?

Ich hoffe, ich habe es jetzt etwas verständlicher erklärt? 🙂

sorry, dachte es liegen noch Zweifel an der Logik vor.

http://www.denisreis.com/how-to-sap-bi-aggregate/ 

Brauchst du denn die Stützstellen im irgendeinen anderen Bericht?

Viele Grüße

Denis

Und Zweifel an der Logik sind leider doch noch ein wenig vorhanden, denn das System verhält sich einfach nicht so, wie ich es erwarten würde gemäß unserer Einstellungen. Denn: so wie unser System eingestellt ist ("Bestandsgröße mit Zugang/Abgang"), ist das Ablegen jeder Materialbewegung als Stützstelle falsch, oder?

Dass die Werte am Ende stimmen ist zwar positiv, aber wir wundern uns natürlich schon, wieso das so bei uns abläuft und nicht nach dem "regulärem" Weg.

Ich hoffe, ich vergrößere nicht die Verwirrung mit jedem Beitrag ;-)

VG

Arnold

(Hinweis vorab: bei den Stützstellen (Sätze mit Datum 31.12.9999) wird die Menge immer unter "Zugang" mit dem entsprechendem Vorzeichen abgelegt)

Initialbeladung Material 4711 mit 500 ST Bestand zum 01.01.18.

Komprimierung der Initialbeladung, Datensatz in 0IC_C03:

MATNR----Materialbeleg----Kalendertag----Abgangsmenge----Zugangsmenge

4711-------- - --------------------31.12.9999-----0----------------------500

Bewegungen von Material 4711:

200 ST Abgang am 02.01.18

100 ST Zugang am 03.01.18

Datenbeladung in den Cube. Datensätze vor dem Komprimieren:

MATNR----Materialbeleg----Kalendertag----Abgangsmenge.----Zugangsmenge.

4711-------- - ---------------------31.12.9999------0----------------------500

4711--------123------------------02.01.2018-----200-------------------0

4711--------456------------------03.01.2018-----0----------------------100

Komprimierung der Bewegungen. Datensätze nach dem Komprimieren im Cube:

MATNR----Materialbeleg----Kalendertag----Abgangsmenge----Zugangsmenge

4711-------- - -------------------31.12.9999------0---------------------500

4711--------123------------------02.01.2018-----200------------------0

4711--------456------------------03.01.2018-----0---------------------100

4711--------123------------------31.12.9999-----0-------------------- -200

4711--------456------------------31.12.9999-----0---------------------100

Um jetzt z.B. den Bestand vom 04.01.18 zu berechnen, werden anscheinend alle Stützstellen addiert und es kommt der richtige Wert raus:

500 + (-200) + 100 = 400

Um den Bestand vom 02.01.18 zu berechnen werden vermutlich auch erst die Stützstellen aufaddiert (siehe oben), und dann noch der Zugang vom 03.01.18 (100 ST) abgezogen. Und man hat auch den richtigen Wert von 300 ST für den 02.01. So ist das ja auch von SAP beschrieben.

Aber bei sehr vielen Material-Bewegungen führt das einfach zu langen Query-Laufzeiten, da alle Materialbewegungen (da sie ja als Stützstellen abgelegt wurden) aufaddiert werden müssen. Das sollte ja eigentlich während der Komprimierung passieren, oder? Nach Komprimierung der der Material-Bewegungen sollte der Cube eigentlich so aussehen:

MATNR----Materialbeleg----Kalendertag----Abgangsmenge----Zugangsmenge

4711-------- - -------------------31.12.9999------0----------------------400

4711--------123------------------02.01.2018-----200-------------------0

4711--------456------------------03.01.2018-----0-----------------------100

Der aktuelle Bestand ist als Stützstelle abgelegt und errechnet sich aus dem Initialbestand (500) und den Bewegungen (-200 +100), zusammen also 400. Die Bewegungen mit Belegdatum sind zur Berechnung vergangener Bestände vorhanden.

Oder habe ich das Konzept doch falsch verstanden?

Ich hoffe, das Beispiel hilft etwas :)

Beim Komprimieren wird ja auf jede Merkmalskombination verdichtet, oder?

Und da wir den Materialbeleg im Cube mitaufgenommen haben, wird also auch für jeden Materialbeleg eine "verdichtete" Stützstelle angelegt...

Mit Aggregaten haben wir jetzt eine gute Lösung gefunden, so haben wir die Materialbelege einfach verdichtet.