Non-Cumulatives - Stock Handling

Non-cumulatives / Stock Handling
SAP AG
Agenda
1. Definition 2. Creation 3. Loading and compression 4. Validity table 5. Query execution 6. Modeling guidelines 7. Information resources
SAP AG 2004, Non-cumulatives / Stock Handling, 2
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
Creation
Key figures InfoCubes Aggregates MultiCubes
Creation of non-cumulative key figures

Two possibilities: With delta handling With separate in- and outflow corresponding objects have to: be defined before match the type / unit have aggregation SUM / SUM must not be used by other NCUM key figures Specification of excpt. aggregat.: MIN MAX FIRST LAST AVG (number of days) AVG (number of working days)
Types of non-cumulative key figures

Different types of non-cumulative key figures
+/"Non-cumulative Non-cumulative key figure" key figure with = cumulative key associated single figure with excep. delta (cumulative) aggregation
Non-cumulative key figure with associated in- and outflow (cumulative) .
The non-cumulative key figure is used in the definition of the InfoCube, but does NOT exist in the facttable. In the fact table only the delta or inflow/outflow key figures exist.
Creation
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 be a time reference characteristic (checked during InfoCube activation) time reference characteristic can be determined using the following hierarchy: 0CALMONTH 0CALYEAR 0CALDAY 0CALWEEK
0FISCPER
0FISCYEAR
incomplete time characteristics like e.g. 0CALMONTH2, 0CALQUART1,... can be used but can not be time reference characteristic ("normal characteristics")
Update rules
Example: Stock key figure: 0BLOCKEDSTK (blocked stock) Assigned movement key figures: 0ISSBLOSTCK (Issued quantity blocked stock) = outflow 0RECBLOSTCK (Received quantity blocked stock) = inflow
InfoCube 0IC_C03
InfoSource 2LIS_03_BX (Stocks)

0CPQUABU from 2LIS_03_BX updates 0RECBLOSTCK in 0IC_C03 (Receipt)
InfoSource 2LIS_03_BF (Movements)

0CPQUABU from 2LIS_03_BF updates 0RECBLOSTCK 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
Aggregates
It is possible to define aggregates on NCUM InfoCubes BW 2.x 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: BW 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
Creation
MultiCubes
NCUM InfoCubes can be used in a MultiCube Restrictions: 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 BW 2.x to have identical time-dimensions the time-dimension of normal InfoCubes have to contain at least the time-characteristics of the MultiCube
Aggregation over multicubes / validity objects is consistent Time-dimension of NCUM-InfoCubes can differ, but there must be one reference time characteristic for the MultiCube Example: C1 contains 0CALDAY, C2 contains 0CALWEEK and C3 contains 0CALMONTH as reference time characteristic. BW 3.x M1 = C1 + C2 + C3 is allowed but M2 = C2 + C3 is not allowed
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 51 52 1 2 Year 2001 2001 2002 2002 Material 4711 4711 4711 4711 Inflow 10 20 10 30
Month Dez Jan Year 2001 2002 Material 4711 4711 Inflow 20 50
Week [Dez.2001 Jan.2002] Year [51.2001 02.2002] Month ininin [2001 2002]
Week Month Year 51 Dez 2001 52 Jan 2002 1 2 Stock Stock 10 20 50 30 70 140 40 70 Stock Cube1 Stock Cube2 Stock Cube1 Stock Cube2 10 20 30 30 70 70 70 40 70
Agenda
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
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!
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.
Business Content Data/InfoSources

2LIS_03_BX 2LIS_03_BF 2LIS_03_UM Material stocks Material movements Revaluations
BW 3.0
Standard R/3 Inventory Management in BW

Initial Stock transfer
2LIS_03_BX
Material Stock (as of BW 2.0B)
0MATERIAL
Material Master Data
0IC_MC01
MultiCube Slow Movers
Material Movements
2LIS_03_BF
Material Movements (as of BW 2.0B)
0IC_C03
Material Movements
0IC_MC02 0PP_C05
Plan/Actual Comparison Material Consumption MultiCube Days of Supply components
Revaluations
2LIS_03_UM
Revaluations (as of BW 2.0B)
0IC_MC03
BW 3.0
0PP_C02
Period-Specific Order/Material View
MultiCube Days of Supply WIP
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/InfoSource 2LIS_40_S278
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 point

Requests are moved to request 0 Reference point is updated If all requests are compressed actual value can be computed by only reading the reference point
Compression without update of reference point

The requests are only moved to request 0 Useful to load historic data into an InfoCube Request(s) with historical data must be compressed, otherwise you get wrong query results
Where to define the type of compression?
Administrator Workbench
InfoProvider (InfoCube)
Manage
Overview: Steps for the upload

Activate extract structures MC03BF0/MC03UM0 for corresponding DataSources 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), compression with 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, but recommended 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 MCNB Always currents stock No 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_BX MC03BF0SETUP MC03UM0SETUP VBDATA
Time Past Opening balance Actual
Loading the opening balance (InfoSource 2LIS_03_BX)
BW system
InfoPackage for InfoSource 2LIS_03_BX
Generata Initial Status

Example II (PSA): Material 0CALDAY 4711 01 Jun 2002 4712 01 Jun 2002 Initial stock 1000 2000
Note: - For simplification without plant! - Initial stock will be updated into the receipt 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 the addition of a stock key figure in the InfoCube definition.
Validity table: 0REQID || -1 || 1234 ||
0CALDAY FROM 20020601 20020601
0CALDAY TO 20020601 20020601
/BI0/L<InfoCube> or /BIC/L<InfoCube> (transaction RSDV)
InfoCube: Material RT 4711 1 4712 1
0CALDAY 31.12.9999 31.12.9999
Inflow kyf 1000 2000
0REQID 1234 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 4711 04 Jun 2002 4711 05 Jun 2002 4712 07 Jun 2002 Inflow 100 200 Outflow 50
Movements can be initialized and then provided with deltas.
Validity table : 0REQID || -1 || 1234 || 1235 || InfoCube: Material RT 4711 1 4712 1 4711 4711 4712
0CALDAY FROM 20020601 20020601 20020604
0CALDAY TO 20020607 20020601 20020607
0CALDAY 31.12.9999 31.12.9999 04.06.2002 05.06.2002 07.06.2002
0CALMONTH 0 0 06.2002 06.2002 06.2002
Inflow kyf Outflow kyf 1000 2000 100 50 200
0REQID 1234 1234 1235 1235 1235
Compression of these requests without marker update
BW system
Inventory InfoCube
Manage
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 can take place)
Upload deltas subsequently (InfoSources 2LIS_03_BF and 2LIS_03_UM)
BW system
InfoPackages for InfoSources 2LIS_03_BF/2LIS_03_UM
Compression of these requests with marker update
BW system
Inventory InfoCube
Manage
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 value in January
Reference point 1
20 = 35 + 10 + 5 = 35 = 35 - 5 = 30
100
Oct
Nov
Dec
Jan
Feb
Mar
Time
After upload of the previous material movements
Reference point 1
100
No marker update!
+20 +10 +10
Oct
Nov
Dec
Jan
Feb
Mar
Time
Compressed requests
After upload of the deltas for material movements
Reference point 2
130
+20 +10 +10
+20 +10 +10
Oct
Nov
Dec
Jan
Feb
Mar
Time
Compressed requests
Agenda
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.
"initial stock"
"final stock"
Example IV:
plant A:70 [+10 plant B: plant C: SUM: SUM: +5 90 [ +10 80 [ +5 265 185 +10 +20 +5 +5 ] +30 ] +10 ] 100 150 100 (without validity) (with validity) infinite time
250 250 250 70 70 70
270 295 270 295
305 350 305 350
Jan. Feb. Mrc. Apr. Mai Jun. Jul. Aug.
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 Request -1 Request -2 correspond to requests in cube re-computed intervals for reporting user-specified intervals
/BI0/L0BWVC_C04
SID_0REQUID SID_0VC_NUMC11 SID_0CALDAY_F SID_0CALDAY_T MODEFROM MODEFROM
5 2 2 0 0 -1 -1 -1 -2 -2
3 3 1 2 1 1 2 3 2 3
20000331 20000101 20000201 20000101 20000101 20000101 20000101 20000101 20000101
20000331 20000131 20000228 20000131 20000131 20000228 20000131 20000131 20001231 1
F R
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

Drill-down according to a validity object is now well defined; that means the result is independent of the drilling history.
Validity interval
Example V:
Jan Plant A: Plant B: Plant C: +30 Feb Mar +20 +10 Apr +40 +20 +20 May +10 +30
ref. point 100 150 50
With validity object (filter on Plant B): object: LAST Without validity object: LAST Plant A: 30 30 50 90 100 | 100 Plant B: [120][120] 130 150 [150] | 150 120 120 150 Plant C: [0] [0] [0] 20 50 | 50 0 0 0 -------------------------------------------SUM: 150 150 180 260 300 | 300
BW 3.0
Agenda
Query execution calucation (Example III)

value (t) =
Requid = 0 AND Recordtp = 1 AND ref Time =
tupel +
Requid > 0
tupel -
Ref Time > t
tupel
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
Deltas for Noncompressed backwards calculation deltas
Reference point 2
130
last value
Stock (End of Jan) = 130 + 10 10 10 = 120
+20 +10 +10
+20 +10 +10
Oct
Nov
Dec
Jan
Feb
Mar
Time
Compressed requests
Query execution aggregation (Example II)

Material 4711 Month 06.2002 Stock kyf Inflow kyf Outflow kyf 1050 1100 50
- stock key figure (Assumption: expeptional aggregation "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)
- normal aggregational behaviour (1000+100)
Query execution validity table (Example II)

Material 4711 4711 4711 4711 4711 Day 01 Jun 2002 02 Jun 2002 03 Jun 2002 04 Jun 2002 05 Jun 2002 Stock kyf 1000 1000 1000 1100 1050 Inflow kyf 1000 0 0 100 0 Outflow kyf 0 0 0 0 50
- Such a report is possible although there are only three data records stored in the InfoCube for Material 4711 (if you do not use this technology 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 where stocks 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
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 type time

Example VI: Reference characteristic that is not a time characteristic InfoCube: Employee no 4711 4711 4711 4712 4712 Query: Employee no 4711 4712 Query new: Employee no 4711 4712 Year 1999 1999 No of employee appraisals 1 1 Year 1999 1999 No of employee appraisals 2 1 Double counting!!! Type of appraisal Potential assesment Target achievement Performance appraisal Potential assesment Target achievement Year 1999 1999 1999 1999 1999 No of employee appraisals 1 0 1 1 0 Solution: key figure No of employee appraisals gets exceptional aggr. AVG for values not equal 0 over characteristic type of appraisal (aggregation reference characteristic)
Using another exception aggregation

With a new caluclated key figure many execption aggregation types are 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: Facttable:
Date 29.01.02 30.01.02 31.01.02 01.02.02 02.02.02
Date 28.01.02 29.01.02 30.01.02 31.01.02 01.02.02 02.02.02 03.02.02
Month Jan Jan Jan Feb Feb
Material 4711 4711 4711 4711 4711
Inflow 30 10 20 30 20
Query:
Stock (LAST) Stock (FIRST) 0 0 30 0 40 30 60 40 90 60 110 90 110 110
BW 3.0
InfoCubes
Compression Update rules Validity table Data Model
Compression
General rule: Creation of opening balance has to be compressed with marker update, movements that have lead to this stock have to be compressed with no marker update, new movements can be compressed, if they are compressed then mandatory with marker update. If this is not considered, query results get wrong (see example VIII). Combination of characteristics values in the historical movements have to match the combination of characteristics values in the opening balance. Otherwhise some stock markers are missing. Then stock values can not be caluclated (with this combination in query drill down). As requests with historical movements can only be compressed without stock marker update it is not possible 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 0 0 -100 RecordType 0 0 1
2 Apr 2003 6050 21 Jan 2003 100 31129999 0
InfoCube Result after compression RIGHT Date Quantity ISS Quantity REC 0 0 0 RecordType 0 0 1
2 Apr 2003 6050 21 Jan 2003 100 31129999 0
Example VIII: Results of wrong compression (III)

Query Result WRONG Month 12/2002 01/2003 02/2003 03/2003 04/2003 Stock 6050 5950 5950 5950 -100 Issue 100 0 0 6050 Receipt 0 0 0 0
--------------------------------------------------------------------------------------------------------------------------------------------------------------------Result -100 6150 0
Query Result RIGHT
Month 12/2002 01/2003 02/2003 03/2003
Stock 6150 6050 6050 6050
Issue 100 0 0
Receipt 0 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 markers

Stock init Material 4711 Plant 1000 Storage Location 0001 Date 1st Jan 2004 Value +1000
Compression with marker update
Historical movement Material 4711 Plant 1000 Storage location
As these request can only be compressed with no marker update, marker procuction incl. storage location is not possible!
Date 1st Dec 2003
Value +1000
Compression with no marker update
Cannot be handled! Solution: make sure that the char. value combination of the movements fits to the stock init char. Value combination!
Drill down by storage location!

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 the upper 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
Update rules
- calculate all other time characteristics automatically from the reference time characteristic
InfoCubes
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
Example X:
Plant A: Plant B: SUM: [ 10 [ 30 ] 40 Jan.
50 ]
AVG 30 = (10 + 50) / 2 30 45 60 or 45 ?
50 Feb.
InfoCubes
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.
Query definition
No difference between normal key figures and NCUM key figures If a query contains normal and NCUM key figures both parts are processed separately 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)
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 into separate 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
Online Documentation NetWeaver BW I

Non-Cumulatives
BI Platform OLAP Performance Optimization Non-cumulatives
Validity table
Data Warehousing InfoCube Additional Functions in InfoCube Maintenance Non-Cumulative Value Parameter Maintenance Administrator Workbench Modeling
Compression
Data Warehousing Data Warehouse Management Managing InfoCubes Process Management Managing Data Targets Compressing InfoCubes
Aggregation
Data Warehousing Administrator Workbench Modeling InfoObject Creating InfoObjects: Key Figures Tab Page: Aggregation
Online Documentation NetWeaver BW II

Exceptional Aggregation
BI Platform Aggregation Scenarios for the Use of an Exception Aggregation OLAP Special OLAP Functions and Services
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 (N) Non-cumulatives How to Handle inventory management scenarios in SAP BW 3.x (pdf)
click:
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 Vervielfltigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrckliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen knnen ohne vorherige Ankndigung gendert werden. Die von SAP AG oder deren Vertriebsfirmen angebotenen Softwareprodukte knnen 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, Informix und Informix Dynamic ServerTM sind Marken der IBM Corporation in den USA und/oder anderen Lndern. 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 erwhnte 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 erwhnte SAP-Produkte und -Dienst-leistungen sowie die entsprechenden Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen Lndern weltweit. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen.

Non-Cumulatives - Stock Handling

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Non-Cumulatives - Stock Handling

Hochgeladen von

Copyright:

Verfügbare Formate

Non-cumulatives / Stock Handling

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

SAP AG 2004, Non-cumulatives / Stock Handling, 3

SAP AG 2004, Non-cumulatives / Stock Handling, 4

Key figures InfoCubes Aggregates MultiCubes

SAP AG 2004, Non-cumulatives / Stock Handling, 5

Creation of non-cumulative key figures

Types of non-cumulative key figures

Non-cumulative key figure with associated in- and outflow (cumulative) .

Key figures InfoCubes Aggregates MultiCubes

SAP AG 2004, Non-cumulatives / Stock Handling, 8

Creation of non-cumulative InfoCubes

Time reference characteristic

InfoSource 2LIS_03_BX (Stocks)

InfoSource 2LIS_03_BF (Movements)

Key figures InfoCubes Aggregates MultiCubes

SAP AG 2004, Non-cumulatives / Stock Handling, 12

Key figures InfoCubes Aggregates MultiCubes

SAP AG 2004, Non-cumulatives / Stock Handling, 14

MultiCubes and Inventory InfoCubes in BW 3.0

SAP AG 2004, Non-cumulatives / Stock Handling, 16

SAP AG 2004, Non-cumulatives / Stock Handling, 17

Loading and Compression

SAP AG 2004, Non-cumulatives / Stock Handling, 18

SAP AG 2004, Non-cumulatives / Stock Handling, 19

DataSources for initialization

SAP AG 2004, Non-cumulatives / Stock Handling, 20

Loading and Compression

SAP AG 2004, Non-cumulatives / Stock Handling, 21

InfoPackage for initialization

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

SAP AG 2004, Non-cumulatives / Stock Handling, 22

Loading and Compression

SAP AG 2004, Non-cumulatives / Stock Handling, 23

SAP AG 2004, Non-cumulatives / Stock Handling, 24

Loading and Compression

SAP AG 2004, Non-cumulatives / Stock Handling, 25

Business Content Data/InfoSources

SAP AG 2004, Non-cumulatives / Stock Handling, 26

Standard R/3 Inventory Management in BW

MultiCube Days of Supply WIP

Other BW Content Areas in Inventory Management

SAP AG 2004, Non-cumulatives / Stock Handling, 28

Loading and Compression

SAP AG 2004, Non-cumulatives / Stock Handling, 29

"normal" compression, i.e. with update of reference point

Compression without update of reference point

Where to define the type of compression?

SAP AG 2004, Non-cumulatives / Stock Handling, 31

Loading and Compression

SAP AG 2004, Non-cumulatives / Stock Handling, 32

Overview: Steps for the upload

SAP AG 2004, Non-cumulatives / Stock Handling, 33

Activate extract structures in logistics cockpit

R/3 source system

LO cockpit (transaction LBWE)

Initialization of the opening balance

Setup of the historical movements/revaluations

SAP AG 2004, Non-cumulatives / Stock Handling, 36

Situation after these steps in the R/3 source system

2LIS_03_BX MC03BF0SETUP MC03UM0SETUP VBDATA

Time Past Opening balance Actual

SAP AG 2004, Non-cumulatives / Stock Handling, 37