How to Handle Non_cumulatives_good

Non-cumulatives / Stock Handling

SAP AG

© SAP AG 2004, Non-cumulatives / Stock Handling, 2

Agenda

1. Definition

2. Creation

3. Loading and compression

4. Validity table

5. Query execution

6. Modeling guidelines

7. Information resources


Definition

Cumulative values are those key figures that are cumulated using all characteristics, thus also using time.

Example: sales revenue, weight, etc.

Non-cumulative values are those key figures that are measured in relation to a period in time; that is to say they cannot be meaningfully cumulated over time. Non-cumulative values are summarized over time using so-called exception aggregation.

Example: stock quantities/-values, number of employees, account balances, etc.


Agenda

1. Definition

2. Creation


4. Validity table

5. Query execution




Creation

Key figures

InfoCubes

Aggregates

MultiCubes


Creation of non-cumulative key figures

Two possibilities:• With delta handling• With separate in- and outflow

Specification of excpt. aggregat.:• MIN • MAX• FIRST• LAST• AVG (number of days)• AVG (number of working days)

corresponding objects have to:• be defined before• match the type / unit• have aggregation SUM / SUM• must not be used by other NCUM

key figures


Types of non-cumulative key figures

Different types of non-cumulative key figures

+ -+/-"Non-cumulative

key figure"= cumulative keyfigure with excep.

aggregation

Non-cumulativekey figure with

associated singledelta (cumulative)

Non-cumulativekey figure with

associated in- andoutflow

(cumulative)

.

The non-cumulative key figure is used in the definition of the InfoCube, but does NOT exist in the facttable. In thefact table only the delta or inflow/outflow key figuresexist.


Creation

Key figures

InfoCubes

Aggregates

MultiCubes


Creation of non-cumulative InfoCubes

• An InfoCube is called NCUM InfoCube if it contains at least one NCUM key figure

• NCUM key figure can be used exactly as a normal key figure

• corresponding CUM key figures are added automatically (these key figures must not be removed from the InfoCube)

Special treatment for NCUM InfoCubes:• time reference characteristic• validity objects


Time reference characteristic

A time reference characteristic is a time characteristic which determines the values of all other time characteristics

• An NCUM InfoCube can contain several time characteristics, but there must bea time reference characteristic (checked during InfoCube activation)

• time reference characteristic can be determined using the followinghierarchy:

• incomplete time characteristics like e.g. 0CALMONTH2, 0CALQUART1,...can be used but can not be time reference characteristic ("normal characteristics")

0CALDAY 0CALWEEK

0CALYEAR0CALMONTH

0FISCPER 0FISCYEAR


Update rules

InfoCube 0IC_C03

InfoSource 2LIS_03_BF (Movements)InfoSource 2LIS_03_BX (Stocks)

Example:Stock key figure:0BLOCKEDSTK (blocked stock)Assigned movement key figures:0ISSBLOSTCK (Issued quantity blocked stock) = outflow0RECBLOSTCK (Received quantity blocked stock) = inflow

0CPQUABU from 2LIS_03_BX updates 0RECBLOSTCKin 0IC_C03 (Receipt)

0CPQUABU from 2LIS_03_BF updates0RECBLOSTCK or 0ISSBLOCSTCK in 0IC_C03 (Receipt or Issue)

Stock key figures 0BLOCKEDSTK is not a InfoObject (field) on the InfoCube. During the creation of the opening balance the initial stock (0CPQUABU from 2LIS_03_BX) is updated into the inflow key figure (0RECBLOSTCK in 0IC_C03).So the stock key figure is never available in update rules!

Please note that the application examples in these slides are based on the R/3 Inventory Management use case! But all the technics are also deployable for other scenarios (accounts, headcounts, etc.).


Creation

Key figures

InfoCubes

Aggregates

MultiCubes


Aggregates

• It is possible to define aggregates on NCUM InfoCubes• Aggregates must include all the time characteristics • Expert-mode to define aggregates without the need to include all time characteristics. These aggregates are only used when cumulative key figures are read.

• NCUM Queries with several column-restrictions are not split into several “sub-queries” no optimal usage of aggregates

• Improvements in 3.0:* Splitting of query into several sub-queries possible * Aggregates which aggregate over time can be used for LAST- and FIRST-key figures* Aggregates without reference time characteristic may be used for non-cumulative query

BW 2.x

BW 3.0


Creation

Key figures

InfoCubes

Aggregates

MultiCubes


MultiCubes

NCUM InfoCubes can be used in a MultiCubeRestrictions:• the time-dimension of a MultiCube have to match exactly the

time-dimension of every NCUM InfoCube which is part of the MultiCube⇒ all NCUM InfoCubes which belong to the same MultiCube have

to have identical time-dimensions• the time-dimension of “normal” InfoCubes have to contain at least the

time-characteristics of the MultiCube

BW 2.x

Aggregation over multicubes / validity objects is “consistent”Time-dimension of NCUM-InfoCubes can differ, but there must be one reference time characteristic for the MultiCubeExample: C1 contains 0CALDAY, C2 contains 0CALWEEK and C3 contains 0CALMONTH as reference time characteristic.

M1 = C1 + C2 + C3 is allowed butM2 = C2 + C3 is not allowed

BW 3.x


MultiCubes and Inventory InfoCubes in BW 3.0

No limitation concerning the time dimensions of various InfoCubes that should be combined in a MultiCube.

Example I: (Week and Month)Week Year Material Inflow

51 2001 4711 1052 2001 4711 201 2002 4711 102 2002 4711 30

Month Year Material InflowDez 2001 4711 20Jan 2002 4711 50

Week in [51.2001 – 02.2002]Week Stock Stock Cube1 Stock Cube2

51 10 1052 30 301 40 402 70 70

Month Stock Stock Cube1 Stock Cube2Dez 20 20Jan 70 70

Month in [Dez.2001 – Jan.2002]Year Stock Stock Cube1 Stock Cube22001 50 30 202002 140 70 70

Year in [2001 – 2002]


Agenda

1. Definition

2. Creation


4. Validity table

5. Query execution




Loading and Compression

Data/InfoSources

InfoPackage

Update rules

Business Content Data/InfoSources

Compression

Upload scenario

Reference point (marker)


Data/InfoSources

Two Data/InfoSources possible:• Loading of initialization: Only ncum key figures (optional)• Loading of deltas: Only cum key figures

Remarks / Restrictions:• Initialization is not necessary• Initialization has to take place before loading of deltas• For every key combination only one initialization is possible• Loading of initialization via “delta DataSource” is possible


DataSources for initialization

R/3 DataSource:flag is loaded from OLTP

Flat-file DataSource:flag has to be set explicitly



Data/InfoSources

InfoPackage

Update rules


Compression

Upload scenario



InfoPackage for initialization

Special conversions:• value of the reference time characteristic is set to the maximum value (e. g. “99991231”)• value of all the other time characteristics are automatically derived from this• technical infoobject “0RECORDTP” is set to 1

Do not change these fields in the update rules by yourself!



Data/InfoSources

InfoPackage

Update rules


Compression

Upload scenario



Update rules

Recommendation:Because of the necessity to derive all other time characteristics from the reference time characteristic, only the reference time characteristic should be filled via the InfoSource and all other time characteristics should be computed via automatic time conversion.



Data/InfoSources

InfoPackage

Update rules


Compression

Upload scenario




BW 3.0- 2LIS_03_BX Material stocks

- 2LIS_03_BF Material movements

- 2LIS_03_UM Revaluations


Standard R/3 Inventory Management in BW

2LIS_03_BFMaterial Movements

(as of BW 2.0B)

2LIS_03_BXMaterial Stock

(as of BW 2.0B)

Initial Stock transfer

Material Movements

Revaluations

0IC_C03Material Movements

0IC_MC01MultiCube

Slow Movers

2LIS_03_UMRevaluations

(as of BW 2.0B)

0IC_MC02MultiCube

Days of Supplycomponents

0PP_C02Period-Specific

Order/Material View

0MATERIALMaterial Master Data

0IC_MC03MultiCube

Days of Supply WIP

0PP_C05Plan/Actual

Comparison Material Consumption

BW 3.0


Other BW Content Areas in Inventory Management

1. Consumer Products: 0CP_IC_C1

2. Retail: 0RT_C35-39

3. AFS: 0AFMM_C02

Old: InfoCubes 0IC_C01/02 and Data/InfoSource2LIS_40_S278



Data/InfoSources

InfoPackage

Update rules


Compression

Upload scenario



Compression

Reference point (marker)Start point for all calculations - when building an inventory scenario

the first reference point might be the opening balance.Technically, the reference point is the value per characteristic

combination after having compressed your Info Cube.When compressing an InfoCube containing non-cumulatives, the

reference point is (per default) updated.

"normal" compression, i.e. with update of reference pointRequests are moved to request 0Reference point is updatedIf all requests are compressed actual value can be computed by onlyreading the reference point

Compression without update of reference pointThe requests are only moved to request 0Useful to load historic data into an InfoCubeRequest(s) with historical data must be compressed, otherwise you getwrong query results


Where to define the type of compression?

Administrator Workbench InfoProvider (InfoCube) Manage



Data/InfoSources

InfoPackage

Update rules


Compression

Upload scenario



Overview: Steps for the upload

Activate extract structures MC03BF0/MC03UM0 for correspondingDataSources 2LIS_03_BF/2LIS_03_UM in the logistics cockpit.

Initialization of the opening balance in the R/3 source system(DataSource 2LIS_03_BX).

Setup of the historical material movements/revaluations in the R/3 source system (DataSources 2LIS_03_BF/2LIS_03_UM).

Loading the opening balance (InfoSource 2LIS_03_BX), compressionwith marker update (compression mandatory).

Loading the historical movements (InfoSource 2LIS_03_BF) and revaluations (InfoSource 2LIS_03_UM), compression without marker(compression mandatory).

Setup V3 update in R/3 system.

Upload deltas subsequently (InfoSources 2LIS_03_BF/2LIS_03_UM), compression with marker update (compression optional, butrecommended for performance reasons).


Activate extract structures in logistics cockpit

R/3 source system LO cockpit (transaction LBWE)


Initialization of the opening balance

R/3 source system transaction MCNBAlways currents stockNo postings during this run


Setup of the historical movements/revaluations

R/3 source system transactions OLI1BW (material movements) and OLIZBW (revaluations)By selections it has to be guaranteed that the values of the documents lie before the initialization run for the opening balance (if still no postings take place all documents can be selected).


Situation after these steps in the R/3 source system

2LIS_03_BXMC03BF0SETUP

MC03UM0SETUPVBDATA

TimePast Opening Actual

balance


Loading the opening balance (InfoSource 2LIS_03_BX)

BW system InfoPackage for InfoSource2LIS_03_BX


Generata Initial Status

Example II (PSA):Material 0CALDAY Initial stock4711 01 Jun 2002 10004712 01 Jun 2002 2000

Note:- For simplification without plant!- Initial stock will be updated into thereceipt movement key figure!

This mode is only available if it is a stock InfoCube. A stock InfoCube has a validity table. This is created by theaddition of a stock key figure in the InfoCube definition.

Validity table:0REQID || 0CALDAY FROM 0CALDAY TO-1 || 20020601 200206011234 || 20020601 20020601

/BI0/L<InfoCube> or

/BIC/L<InfoCube>

(transaction RSDV)

InfoCube:Material RT 0CALDAY Inflow kyf 0REQID4711 1 31.12.9999 1000 12344712 1 31.12.9999 2000 1234

Rt = Record type

Kyf = Key figure


Compression of this request with marker update

BW system Inventory InfoCube Manage


Loading the historical movements/revaluations(InfoSources 2LIS_03_BF/2LIS_03_UM)

BW system InfoPackages for InfoSources 2LIS_03_BF/2LIS_03_UM


Initialize delta process

Example II (PSA):Material 0CALDAY Inflow Outflow4711 04 Jun 2002 1004711 05 Jun 2002 504712 07 Jun 2002 200

Movements can be initialized and then provided with deltas.

Validity table :0REQID || 0CALDAY FROM 0CALDAY TO-1 || 20020601 200206071234 || 20020601 200206011235 || 20020604 20020607

InfoCube:Material RT 0CALDAY 0CALMONTH Inflow kyf Outflow kyf 0REQID4711 1 31.12.9999 0 1000 12344712 1 31.12.9999 0 2000 12344711 04.06.2002 06.2002 100 12354711 05.06.2002 06.2002 50 12354712 07.06.2002 06.2002 200 1235


Compression of these requests without markerupdate



Setup V3 control in R/3 source system

R/3 source system LO cockpit (transaction LBWE)Prerequisite: successful initialization of DataSources 2LIS_03_BF and 2LIS_03_UM (check with transaction RSA7 – after this new postings cantake place)


Upload deltas subsequently (InfoSources2LIS_03_BF and 2LIS_03_UM)

BW system InfoPackages for InfoSources 2LIS_03_BF/2LIS_03_UM


Compression of these requests with marker update




Data/InfoSources

InfoPackage

Update rules


Compression

Upload scenario



Reference point (marker): Scenario

Example III:

- 31.03.2002

- You have setup an opening balance of 100 units on 01.01.2002 and loaded it into the stock InfoCube.

- Historical material movements from the three previous months (October 2001:10 units; November 2001: 20 units; December 2001: 10 units) are loaded into the BW.

- Since this point, successive material movements have been transferred into the BW in the delta process. Delta requests transferred at the end of January (20 units) and February (10 units) were already compressed after successful validation, the last delta request from the end of March (10 units) is still in the InfoCube in uncompressed form.


After upload of the opening balance

Sample:last value = 20 + 10 + 5 = 35value in January = 35 - 5 = 30

Sample:last value = 35value in January = 35 - 5 = 30

100

Time

Referencepoint 1

Oct Nov Dec Jan Feb Mar Time


After upload of the previous material movements

+10+20

Time

100

Referencepoint 1


+10

Compressed requests

No marker update!


After upload of the deltas for material movements

Referencepoint 2

+10+20

Time

130


+10 +10+10+20

Compressed requests


Agenda

1. Definition

2. Creation


4. Validity table

5. Query execution




Motivation

For normal key figures: the query result only “contains” entries which have been loaded into the InfoCube before.

As the NCUM value of a key figure is computed by reading a reference point and then using a backward computation with the deltas, it is possible to compute a value for every point in time.⇒ Define an interval which limits the validity (by default the minimal and the maximal value of the time characteristic of all entries which have been loaded into the InfoCube)

Sometimes a single interval is not sufficient (besides the most detailed time characteristic, additional characteristics for the InfoCube can be included in the validity table):• plan/actual indicator (the plan values are valid for the whole year, actual values are loaded monthly) = add the plan-actual sign to the validity table)• plants, or branches which open resp. close at different points in time or• plants, or branches which deliver their data at different points in time (the values for different plants are loaded at different times) = add characteristic plant to the table

!! But validity objects are no workaround for termination !!


Definition

Validity-Determining Characteristics: Characteristics that determine the temporal validity period of the non-cumulative in an InfoCube.

SUM: 70 70 70 185 270 295 305 350 (with validity)SUM: 250 250 250 265 270 295 305 350 (without validity)

Jan. Feb. Mrc. Apr. Mai Jun. Jul. Aug. infinite time

plant A:70 [+10 +5 +10 +5 ] 100 plant B: 90 [ +10 +20 +30 ] 150plant C: 80 [ +5 +5 +10 ] 100

Example IV:"initial stock" "final stock"


Non-cumulative value parameters (maintenance in InfoCube definition)

- time reference characteristic is mandatory (determined in the InfoObject definition of the stock key figure)

- additionally besides the stock relevant characteristic 0MATERIAL an additional non-cumulative value parameter, like 0PLANT, can be defined (see example for the necessity one slide before)


Maintenance of user intervals I

(Transaction RSDV)• Normally the validity table is adapted when loading data (min. and max. time for

every combination of validity InfoObjects)• User defined specification of the interval for each combination possible:

Fix: absolute value for the time reference characteristic Relative: “convert” SY-DATUM into time reference characteristic and add / subtract specified value


Maintenance of user intervals II

• Request ≥ 0 correspond to requests in cube• Request -1 re-computed intervals for reporting• Request -2 user-specified intervals

SID_0REQUID SID_0VC_NUMC11 SID_0CALDAY_F SID_0CALDAY_T MODEFROM MODEFROM5 3 20000331 20000331 2 3 20000101 20000131 2 1 20000201 20000228 0 2 20000101 20000131 0 1 20000101 20000131 -1 1 20000101 20000228-1 2 20000101 20000131-1 3 20000101 20000131-2 2 20000101 20001231 F F-2 3 1 R

/BI0/L0BWVC_C04

Assumption: Requests with requid ≤ 2 are reporting relevant


Maintenance of the validity table

1.) Initial definition of the validity table during InfoCube definition

2.) If InfoCube is filled then adaptation of validity table (remove/addition of validity objects) possible with report RSDG_CUBE_VALT_MODIFY

3.) If validity table is wrong, then rebuild possible using the function module:RSDV_VALID_RECREATE

I_REBUILD_FROM_FACT = space : recomputation of the values for request -1 by aggregation of all

reporting relevant requests (only reading of validity table)= ‘ X‘ : recomputation of all non-user (complete facttable must be read)


Validity table in BW 3.0

Jan Feb Mar Apr May ref. point

Example V:

Plant A: +30 +20 +40 +10 100 Plant B: +10 +20 150Plant C: +20 +30 50

Without validity object: LASTPlant A: 30 30 50 90 100 | 100 Plant B: 120 120 130 150 150 | 150Plant C: 0 0 0 20 50 | 50--------------------------------------------SUM: 150 150 180 260 300 | 300

Validity interval

With validity object: LASTPlant A: 30 30 50 90 100 | 100 Plant B: [120][120] 130 150 [150] | 150Plant C: [0] [0] [0] 20 50 | 50--------------------------------------------SUM: 150 150 180 260 300 | 300

With validity object (filter on Plant B): LASTPlant A: 30 30 50 90 100 | 100Plant B: 130 150 | 150Plant C: 20 50 | 50

Drill-down according to a validity object is now well defined; that means the result is independent of the drilling history.

BW 3.0


Agenda

1. Definition

2. Creation


4. Validity table

5. Query execution




Query execution – calucation (Example III)

+10+20

Time

130

Referencepoint 2


+10

Compressed requests

+10+10+20

value (t) = Σ tupel + Σ tupel - Σ tupelRequid = 0 ANDRecordtp = 1 ANDref Time = ∞

Requid > 0 Ref Time > t

“last value”

Deltas for backwards calculation

Algorithm to compute inventory value:last value = ‘reference point’ + ‘non compressed requests’value in month x = ‘last value’ - ‘all months larger than x’

Ref. point Non-compressed deltas

Stock (End of Jan) = 130 + 10 – 10 – 10 = 120


Query execution – aggregation (Example II)

Material Month Stock kyf Inflow kyf Outflow kyf4711 06.2002 1050 1100 50

- normal aggregationalbehaviour (1000+100)

- stock key figure(Assumption: expeptionalaggregation "last value" in InfoObject definition)

- is calculated by OLAP processor by inflow and outflow key figures (key figure is not stored physically on the InfoCube)


Query execution – validity table (Example II)

Material Day Stock kyf Inflow kyf Outflow kyf4711 01 Jun 2002 1000 1000 04711 02 Jun 2002 1000 0 04711 03 Jun 2002 1000 0 04711 04 Jun 2002 1100 100 04711 05 Jun 2002 1050 0 50

- Such a report is possible although there are only three data recordsstored in the InfoCube for Material 4711 (if you do not use thistechnology calculating stocks you would need to keep the stock on a daily basis in the InfoCube this would mean five data records here).

- The time slice in the validity table determines the time range wherestocks can be calucated (see chapter before how this validity table works).


Query execution – BW 3.0

• Performance improvements …

• in backward calculation and OLAP processing• optimization of the reconstruction algorithm• preventing memory overflow by portion wise reconstruction


Agenda

1. Definition

2. Creation


4. Validity table

5. Query execution




Modelling Guidelines

Aggregation and exceptional aggregation

InfoCubes

Queries

Performance


Non-cumulative key figures

... have ...

- always aggregation behavior SUM

- to be set with an exceptional aggregation (see chapter 5, example II how this works)

- no possibility for an aggregation reference characteristic, because it is determined by the standard reference time characteristic in the validity table


Cumulative key figures

… have …

- the possibility to enter aggregation SUM, MAX or MIN that has impact on update rules, roll up and compression

- the option to define an exceptional aggregation behavior (see chapter 5, example II how this works)

- usually then an aggregation time reference characteristic (see next when it can makes sense to name here characteristic that are not of type time)


Aggregation reference characteristic not of typetime

Example VI: Reference characteristic that is not a time characteristic

InfoCube:

Employee no Type of appraisal Year No of employee appraisals

4711 Potential assesment 1999 1

4711 Target achievement 1999 0

4711 Performance appraisal 1999 1

4712 Potential assesment 1999 1

4712 Target achievement 1999 0

Query:

Employee no Year No of employee appraisals

4711 1999 2

4712 1999 1

Query new:

Employee no Year No of employee appraisals

4711 1999 1

4712 1999 1

Double counting!!!

Solution: keyfigure No of employeeappraisalsgetsexceptionalaggr. AVG forvalues notequal 0 overcharacteristictype of appraisal(aggregationreferencecharacteristic)


Using another exception aggregation

With a new caluclated key figure many execption aggregation typesare possible for the same basis key figure


FIRST and LAST aggregation

FIRST is using opening values while all other aggregations still use closing values.

Example VII: Date Month Material Inflow29.01.02 Jan 4711 3030.01.02 Jan 4711 1031.01.02 Jan 4711 2001.02.02 Feb 4711 3002.02.02 Feb 4711 20

Facttable:

Query:

Date Stock (LAST) Stock (FIRST)28.01.02 0 029.01.02 30 030.01.02 40 3031.01.02 60 4001.02.02 90 6002.02.02 110 9003.02.02 110 110

BW 3.0




InfoCubes

Queries

Performance


InfoCubes

Compression

Update rules

Validity table

Data Model


Compression

General rule: Creation of opening balance has to becompressed with marker update, movements that havelead to this stock have to be compressed with no markerupdate, new movements can be compressed, if they arecompressed then mandatory with marker update. If this isnot considered, query results get wrong (see exampleVIII).

Combination of characteristics values in the historicalmovements have to match the combination of characteristics values in the opening balance. Otherwhisesome stock markers are missing. Then stock values cannot be caluclated (with this combination in query drill down). As requests with historical movements can only becompressed without stock marker update it is notpossible to produce them automatically (see example IX).


Example VIII: Results of wrong compression (I)

PSA 2LIS_03_BX -> compression with marker update

Date Quantity

22 Mrc 2003 6050

PSA 2LIS_03_BF INIT -> compression with no marker update

Date Quantity +/-

21 Jan 2003 100 -

PSA 2LIS_03_BF Delta -> compression with marker update

Date Quantity +/-

2 Apr 2003 6050 -


Example VIII: Results of wrong compression (II)

InfoCube Result after compression WRONG

Date Quantity ISS Quantity REC RecordType

2 Apr 2003 6050 0 0

21 Jan 2003 100 0 0

31129999 0 -100 1

InfoCube Result after compression RIGHT

Date Quantity ISS Quantity REC RecordType

2 Apr 2003 6050 0 0

21 Jan 2003 100 0 0

31129999 0 0 1


Example VIII: Results of wrong compression (III)

Query Result WRONG

Month Stock Issue Receipt

12/2002 6050 - -

01/2003 5950 100 0

02/2003 5950 0 0

03/2003 5950 0 0

04/2003 -100 6050 0

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

Result -100 6150 0

Query Result RIGHT

Month Stock Issue Receipt

12/2002 6150 - -

01/2003 6050 100 0

02/2003 6050 0 0

03/2003 6050 0 0

04/2003 0 6050 0---------------------------------------------------------------------------------------------------------------------------------------------------------------------Result 0 6150 0

The historical stock gets wrong by the amount of the historical movement !!!

The error of all calculated stocks has the value of the wrong compressed

historical movements (in this case 100) !!


Example IX: Missing stock markersStock init

Material Plant Storage Location Date Value

4711 1000 0001 1st Jan 2004 +1000

Historical movement

Material Plant Storage location Date Value

4711 1000 1st Dec 2003 +1000

Compression withmarker update

As these request can only be compressed with no marker update, marker procuctionincl. storage location is not possible!

Compression with no marker update

Cannot be handled!

Solution: make sure thatthe char. value combinationof the movements fits to the stock init char. Valuecombination!

Drill down by storagelocation!


Special Case: Backdating

Let's assume the initial stock is loaded with on January 1st 2004.

You are setting up then the normal procedure with initializing the historical movements (historical request with movements < January 1st 2004, compression with no marker update).

Now new movements (> January 1st 2004) are coming in with a delta request .

This request contains a record that has a posting date with 31st December 2003 and a recording date with 2nd January 2004 (note that the posting date is the relevant date in most of such scenarios).

When compressing this delta request with marker update, does the values get wrong (because we have learned that historical movements (< January 1st 2004) have to be compressed with no marker update)?

The answer is no because at the time the initialization took place (January 1st

2004) the stock init extractor has to fit with the movement extractor.

If the movement extractor is delta enabled he adds this new posting into a delta request. As such delta requests can be compressed with marker update the stock marker gets adjusted accordingly and the stock calculation algorithm can work correctly.

You also need to avoid that such documents are covered by the setup report of the historical movements (possible if no posting block exists during this run or report runs with selections on the date).


Special Case: Future Postings

Future postings have similar issues like backdatings.

If you try to cover the historical movements that have build up the initial stock in a setup report by date selection and there are movements that relevant (posting) date is higher then the stock init date you won't cover them (if theupper bound corresponds to the stock init date).

They will also not be covered by the delta request.

In such cases you need to enlarge the upper bound accordingly or you select all documents. In both cases keeping the posting block is mandatory.


InfoCubes

Compression

Update rules

Validity table

Data Model


Update rules

- calculate all other time characteristicsautomatically from the reference time characteristic


InfoCubes

Compression

Update rules

Validity table

Data Model


Validity table

• Use validity objects only if you really need them

• Do never use fine granular objects like e.g. material, customer, ... as validity object (No Termination!)

• Do never aggregate over validity objects

60 or 45 ?45 SUM: 40 50

AVG30 = (10 + 50) / 2 30

Jan. Feb.

Plant A: [ 10 50 ] Plant B: [ 30 ]

Example X:


InfoCubes

Compression

Update rules

Validity table

Data Model


Data Model

If you want to look at reference points with transaction LISTCUBE , you

have to include the technical characteristic 0RECORDTP into the list of

fields for selection and you have to add a restriction of 0RECORDTP=1.

Sometimes it might be more feasible to use a snapshot scenario than the non-cumulative values approach. Please follow the guideline in the how to paper mentioned in the last chapter to decide on this.No ODS support for non-cumulative values, only with a snapshot scenario ODS usage makes sense.

If the amount of data is very huge think about a "logical" partitioning to spread data over several InfoCubes (but don't use time characteristics, this is not supported due to the stock marker logic). Use therefore ideally an additional non-cumulative value parameter of the validity table like 0PLANT.




InfoCubes

Queries

Performance


Query definition

• No difference between normal key figures and NCUM key figures• If a query contains normal and NCUM key figures both parts are processedseparately by the OLAP-processor but this is transparent for the user.⇒ virtual key figures (OLAP BADI) can only use key figures which have the

same type (normal or NCUM)




InfoCubes

Queries

Performance


Performance guidelines

• All requests or at least most of the requests should be compressed.• Use as few validity objects as possible.• Use tight restrictions on the time characteristics. If possible do only request the actual value.• If you have a drill down by time, key figures with First/Last aggregation can be processed more efficiently than key figures with AVG aggregation if possible use different queries for key figures with First/Last resp. AVG aggregation (separate First/Last/etc. key figures from other key figures intoseparate queries if semantically possible).• Do not misuse validity objects for termination.• Do not use partial times (like e.g. 0FISCPER3) if not needed.• If not needed suppress the lines with the sum.


Agenda

1. Definition

2. Creation


4. Validity table

5. Query execution




Online Documentation NetWeaver BW I

Non-CumulativesBI Platform OLAP

Performance Optimization

Non-cumulatives

Validity tableData Warehousing Administrator Workbench Modeling

InfoCube

Additional Functions in InfoCube Maintenance

Non-Cumulative Value Parameter Maintenance

Compression Data Warehousing Data Warehouse Management Process Management

Managing Data Targets Managing InfoCubes

Compressing InfoCubes

AggregationData Warehousing Administrator Workbench Modeling InfoObject

Creating InfoObjects: Key Figures

Tab Page: Aggregation


Online Documentation NetWeaver BW II

Exceptional AggregationBI Platform OLAP

Special OLAP Functions and Services

Aggregation

Scenarios for the Use of an Exception Aggregation


CSN Note

586163 - Composite SAP Note on SAP R/3 inventory management in SAP BW

Central entry point, from there all relevant notes are mentioned!!!


How to paper

http://service.sap.com

alias BW

in the right navigation area: SAP BW InfoIndex click: (N) Non-cumulatives How to… Handle inventory management scenarios in SAP BW 3.x (pdf)

http://service.sap.com/


Copyright 2004 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation.

UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

JAVA® is a registered trademark of Sun Microsystems, Inc.

JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.

SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are trademarks of their respective companies.


Copyright 2004 SAP AG. Alle Rechte vorbehalten

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden.

Die von SAP AG oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer Softwarehersteller enthalten.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® und SQL Server® sind eingetragene Marken der Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informixund Informix® Dynamic ServerTM sind Marken der IBM Corporation in den USA und/oder anderen Ländern.

ORACLE® ist eine eingetragene Marke der ORACLE Corporation.

UNIX®, X/Open®, OSF/1® und Motif® sind eingetragene Marken der Open Group.

Citrix®, das Citrix-Logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® und andere hier erwähnte Namen von Citrix-Produkten sind Marken von Citrix Systems, Inc.

HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

JAVA® ist eine eingetragene Marke der Sun Microsystems, Inc.

JAVASCRIPT® ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape entwickelten und implementierten Technologie.

MarketSet und Enterprise Buyer sind gemeinsame Marken von SAP AG und Commerce One.

SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com und weitere im Text erwähnte SAP-Produkte und -Dienst-leistungensowie die entsprechenden Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen Ländern weltweit. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen.

Documents

How to Handle Non_cumulatives_good