BAPI - Issue in fetching non-cumulative KF for Inventory

Hello All,
Would kindly require ur help urgently on the issue mentioned below:
We require the non-cumulative KF '0TOTALSTOCK' in the BW side for further processing. Now we are using BAPI to get the query executed and store the results in a table, so that we can fetch the value from the table.
The issue occuring is, if the Reciept Total Stock and the Issue Total Stock are same which means 0TOTALSTOCK will be '0', this gets stored in the table, but when the the values for Reciept Total Stock and Issue Total Stock are not same, the job for query execution fails giving NO ERROR.
Kindly share ur views on it, since it is critical.
Thank you.
PS: Transaction used for BAPI is RSCRM_BAPI, authorization is not an issue, query contains no formulas, and have performed basic checks with respect to BAPI query execution.
Regards,
Kunal Gandhi

Hi Kunal,
Check this links:
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b06c3f96-ed4f-2a10-1693-f2c76a39988f
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/90886731-21e4-2a10-2ebf-901c2c2b4e3d
Basically, what you do is:
- Define a source: in your case will be a query.
- Define a target: you'll need to create a transactional DSO to save information.
- Connect both: you can simply assign fields if the query is just what you need to download, or you can have routines.
Transaction for creating APD is RSANWB. It's pretty easy and it's a graphical interface, so you should find your way easily.
Hope this helps.
Regards,
Diego

Similar Messages

Non-Cumulative vs. Cumulative KeyFigures for Inventory Cube Implementation?

A non-cumulative is a non-aggregating key figure on the level of one or more objects, which is always displayed in relation to time. Generally speaking, in SAP BI data modeling, there are two options for non-cumulative management. First option is to use non-cumulative management with non-cumulative key figures. Second option is to use non-cumulative management with normal key figures (cumulative key figures). For SAP inventory management, 0IC_C03 is a standard business content cube based upon the option of non-cumulative management with non-Cumulative key figures. Due to specific business requirements (this cube is designed primarily for detailed inventory balance reconciliation, we have to enhance 0IC_C03 to add additional characteristics such as Doc Number, Movement type and so on. The original estimated size of the cube is about 100 million records since we are extracting all history records from ECC (inception to date). We spent a lot of time to debate on if we should use non-cumulative key figures based upon the standard business content of 0IC_C03 cube. We understand that, by using Non-Cumulative key figures, the fact table will be smaller (potentially). But, there are some disadvantages such as following:
(1) We cannot use the InfoCube together with another InfoCube with non-cumulative key figures in a MultiProvider.
(2) The query runtime can be affected by the calculation of the non-cumulative.
(3) The InfoCube cannot logically partition by time characteristics (e.g. fiscal year) which makes it difficult for future archiving.
(4) It is more difficult to maintain non-cumulative InfoCube since we have added more granularity (more characteristics) into the cube.
Thus, we have decided not to use the Cumulative key figures. Instead, we are using cumulative key figures such as Receipt Stock Quantity (0RECTOTSTCK) , Issue Stock Quantity(0ISSTOTSTCK)
, Receipt Valuated Stock Value (0RECVS_VAL) and Issue Valuated Stock Value (0ISSVS_VAL). All of those four key figures are available in the InfoCube and are calculated during the update process. Based upon the study of reporting requirements, those four key figures seems to be sufficient to meet all reporting requirements.
In addition, since we have decided not to use cumulative key figures, we have removed non-cumulative key figures from the 0IC_C03 InfoCube and logically partitioned the cube by fiscal year. Furthermore, those InfoCube are fiscally partitioned by fiscal year/period as well.
To a large extent, we are going away from the standard business content cube, and we have a pretty customized cube here. We'd like to use this opportunity to seek some guidance from SAP BI experts. Specifically, we want to understand what we are losing here by not using non-cumulative key figures as provided by original 0IC_C03 business content cube. Your honest suggestions and comment are greatly appreciated!

Hello Marc,
Thanks for the reply.
I work for Dongxin, and would like to add couple of points to the original question...
Based on the requirements, we decided to add Doc Number and Movement type along few other characteristics into the InfoCube (Custom InfoCube - article movements) as once we added these characteristics the Non Cumulative keyfigures even when the marker was properly set were not handling the stock values (balance) and the movements the right way causing data inconsistency issues.
So, we are just using the Cumulative keyfigures and have decided to do the logical partitioning on fiscal year (as posting period is used to derive the time characteristics and compared to MC.1 makes more sense for comparison between ECC and BI.
Also, I have gone through the How to manual for Inventory and in either case the reporting requirement is Inception to date (not just weekly or monthly snapshot).
We would like to confirm if there would be any long term issues doing so.
To optimize the performance we are planning to create aggregates at plant level.
Couple of other points we took into consideration for using cumulative keyfigures are:
1. Parallel processes possible if non-cumulative keyfigures are not used.
2. Aggregates on fixed Plant possible if non-cumulative keyfigures are not used. (This being as all plants are not active and some of them are not reported).
So, since we are not using the stock keyfigures (non cumulative) is it ok not to use 2LIS_03_BX as this is only to bring in the stock opening balance....
We would like to know if there would be any issue only using BF and UM and using the InfoCube as the one to capture article movements along with cumulative keyfigures.
Once again, thanks for your input on this issue.
Thanks
Dharma.

Issue due to Non Cumulative Keyfigures

Hi All,
I have created a ZCube that gets data from Purchasing and Stocks Cubes. This Zcube has got the Non cumulative Keyfigures 0TOTSTK and 0VALSTCKVAL that are mapped from the Stocks cube in the transformations.
Apart from standard cubes, I have got Transformations from a DSO to the ZCube, I defined these Keyfigures as No transformations.
Data loads are done and data comes into report with an error.
The Validity Interval has the inital value as lowerlimit.
Diagnosis
The initial value has been found as the lower limit of a validity area. This can lead to performance problems and cause queries to terminate, because potentially, non-cumulatives can be reconstructed at any point within the validity interval.
This error occurs if data is loaded to a non-cumulative cube, where the time-reference characteristic is intial (blank).
This error message can also appear when the non-cumulative cube is completely empty.
System Response
Procedure
Check the data in the InfoCube and if there is a request containing data records where the time-reference characteristic is initial (blank), delete this request and reload the request data, with the appropriate time, into the InfoCube.
Is there any chnge to be done in the transformations at DSO level for the non- cumulative keyfigures to overcome this error.
Plz Help.
Thanks in Advance
Regards,
Sudha

Hi all,
Thanks for the Info.
I have mapped all the fields from DSO to cube.Dso doent hold the non cumulative keyfigures.so they are left blank.
I have loade the data to zcube now by deleting the earlier requests. Data is loaded.
I can find entries now in RSDV.
I just have one question to be clarified.. I suspect the issue is with the time Reference char's.
When I do mappping from 0IC_C03 to ZIC_C03 i don't see the mapping for 0CALWEEK, 0CALMONTH, 0CALYEAR. I don't see these fields for doing a mapping though these fields are present in the cube.
Same is the issue wit the DSO also. I dont see the above fields to map in the target.
I don't understand why there are not displayed while creating transfformations though they are in the target.
Please let me know if you understand where I am going wrong.
Sudha

Any bapi avaialble to fetch component planned orders for header planned ord

Hi Experts,
                 We have a req where we need to fetch component planned orders for header planned order .
In Detail :
In MD4C tcode (select planned orders tab -> F8 ), when i pass the header planned order like 17474 .
I get two component planned orders like 16276 16277 and corresponding materials like 12025185 , 12025189.
We are using   BAPI_PLANNEDORDER_GET_DETAIL to fetch component materials for a planned order .
similarly any bapi or tables which have this data to fetch component planned orders.
Thanks in advance,
Mani.

Hope it would be helpful for you:
Check these user exits.
CO610001            User exits: Assembly processing
M61X0001            User exits PP-MRP materials planning
M61X0002            User Exits PP-MRP Material Requirements Planning Evaluations
Thanks

Coding for Non cumulative values

Hi
I have scenario like this. I have a objects called Work in progress(WIP) and cost of sales. ( COS) both are differentated by General Ledger.
Like 400025, 4000026, 400027 are WIP.
500000,5000001, 50006 are COS.
if working porgress is booked on 05/05/08 and for thatWIP order if COS is booked on 08/05/08, then we need to reverse the WIP on 08/05/08. means when COS is booked that time we need to reverse the WIP.
as a solution i am thing of using non cumulative keyfigures for WIP. when it is booked it is Inflow and when COS is entered it is Outflow.
logic is if
Confirmation item(CI),confirmation item number (CITN) of WIP GL is matching with CI,CITN of COS GL then it we need to write to OUTFLOW.
IFNOT
it is INFLOW.
now can some body give me a sample code to derive this Inflow and out flow.
Thanks

Hi Chandrakumar,
We are facing the same problem, how do you solve it?
Regards,

Non-Cumulative value Infoset will not work

Why doesn't an Infoset work with non-cumaltive values? Can I just use a multiprovider to get around this issue?

Hi,
Non cumulative values are not stored anywhere in the database. These are just definitions which are calculated at runtime. Consider the Stock cube. It has 2 key figures. Received stock and issued stock. It also has a Non cumulative Kf total stock which is defined as inflow : Received stock and outflow : issued stock.
At Query runtime, the total stock is calculated as inflow - outflow. No data is physically stored in your database.
Since an infoset joins values stored in a database, you will not be able to use it for Non cumulative values.
What you can do is find your Non cumulative KF definition, and map the input fields for this KF. You can then try and use these fields to calculate the value as a formula.
Hope this helps.
Regards.

Cumulative key figure and non cumulative key figure

Hi BW Expertz
Could any one give me the clarification about cumulative and non cumulative key figures .Why we go for cumulative key figure and non cumulative key figure.If any docs could u just mail to the following [email protected]
Thanx In advance
Best regards
sankar prasad

Cumulative values are those key figures (KF) that are cumulated using all characteristics, thus also using time.
Ex: Sales revenue, Quantity....
Non-cumulative values are those key figures that are measured in relation to a period in time; they cannot be meaningfully cumulated over time. Non-cumulative values are summarized over time using so called exception aggregation.
Ex: Number of employees, Inventory, Stock prices, Account balance,.....
AGGREGATION TAB
Non cumulatives are evaluated by non-cummulative values. Non-cummulative values are special key figures that are different from other key figures (cummulative values) in data transfers and saving as well as in aggregational behaviour. These are measured in relation to a period in time; that is to say, they cannot be meaningfully cumulated over time. Non-cumulative value are summaraized over-time using exception aggregation.
Non-cumulative values such as 'number of employess' are cumulated using characteristics such as 'cost center'. It does not make any sense, however, to cumulate the number of employees using different periods. The result at the end of any particular period would be the sum total of number of employees for each posting during the period. This would of course be wrong.
Instead, the aggregation of the KF can be defined as exception aggregation wherein an additional references characteristics is utilized to tell BW which value to use during the period, in this case, 0CALMONTH is used, in the above example, to indicate that only the last value of 0HEADCOUNT, updated by costcenter, is to be taken for any calender year and month.
Cummulative vs Non-Cumulatives
The purpose of non-cumulatives is to optimize the data transfer in BW, the data retention and the database access. The data transfer from OLTP to BW is minimized and only the meaningful data is saved and processed.
It is recommended that you use non-cumulative values for areas that dont change frequently such as warehouse stock or number of employees.
Non-cumulatives are modeled in BW using a non-cumulative value with the fields belonging to it for storing the non-cumulative or for inflows or outflows.
Non-cumulative values are stored with special KF that differ in terms of data transfers and aggregational behaviour.
Features of NON-Cumulative Values Transfering and Saving Data:
- NC values are mapped uisng one KF for NC changes or two KF for inflows and outflows.
-NC are transferred in an initialization run and the change runs that follow (initialization can also be omitted here)
- A non-cumulative value always has a time-related exception aggegation.
http://help.sap.com/saphelp_nw04/helpdata/en/80/1a62dee07211d2acb80000e829fbfe/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/82/f2dc37f0f12313e10000009b38f8cf/content.htm
http://help.sap.com/saphelp_bw31/helpdata/en/82/f2dc37f0f12313e10000009b38f8cf/content.htm
http://help.sap.com/saphelp_erp2004/helpdata/en/d2/e0173f5ff48443e10000000a114084/content.htm
with Example
Re: Non-Cumulative keyfigure example
Re: Types of non-cumulative keyfigures
/community [original link is broken]
/community [original link is broken]?forumID=131&threadID=29557&messageID=273049
/community [original link is broken]?forumID=131&threadID=111914&messageID=1248243
****Assign Points If Useful*********

Multicube with Cumulative and Non Cumulative Key Figures

Is there any problems if I build a Multicube which consists of InfoProviders which have non-cumulative key figures (Inventory cube) and those which do not
In the query I will be summing the key figure for example Stock Quantity across the InfoProviders? Thanks

Hi,
There is no problem if you do that only thing is when you assign key figures in the multiprovidesr you have to be careful in deciding the infoprovider from which the key figure comes.
Hope this helps
Assign points if useful
Regards,
venkat

Difference between Snapshot scenario and non cumulative scenario

Hi,
Can any one please tell me the difference between snapshot scenario and non cumulative scenario in
inventory management.
Also please give example. I read the pdf " how to handle inventroy management scenarios", but can any one please give some easy to understand examples.
full points guaranteed-

hi,
In Non-cummulative method your stock movements are stored in the cube (inflow and outflow of NC KF) and the Total stock is calculated during query execution. Hence if there are lot of movements in the stock for the period you want to report on, query will take long time to execute.
In case of Snap shot scenario Stock movements are not loaded to cube. you use ODS to load the status of the stock and then from ODS you can load to Cube once in a month. So only summarized data will be availabe in Cube. Reporting will be fast.
Check the below threads
Inventory Management - SnapShot model
snapshot scenario?
SNAP SHOT Scenario in IM

Non-cumulative and time dependence

We are using the Inventory Cube (0IC_C03) and would like to create a historical report that shows over the last months what inventory is active or discontinued. The discontinued flag on 0MATERIAL is only the current status. So if a material is discontinued now, it does not mean that it was discontinued last month.
We investigated using time dependant master data as a navigational attribute. But when reporting with time dependant data you have to specify a key date. This works fine for running the report for a single time period, but we would like to report the changes in multiple time periods.
We also investigated adding the status to 0IC_C03. But since it is non-cumulative I don't think that this would provide correct results. (i.e. if I have 100 in inventory for part A at active status, then the status changes to discontinued, there is no inventory transaction that is created because of the status change. BI will have no idea that the 100 is now discontinued.)
Can anyone recommend a modeling approach that might fit our need? Or do you see any false assumptions I made above?
Thanks,
Chris Robertson

Chris Robertson,
You can achive this using Monthly Snap Shot - Inventory management. Instead of using non-cumulative keyfigures.
[Inventory management with SnapShots and cumulative key figures|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328]
Hope it Helps
Srini

Non-cumulative Inflow and Outflow explanation

Hello Everyone,
We are just implementing Inventory reporting in BW and cannot understand query results. We have searched the forums and documenation, but cannot find an answer.
We have a Non-*** Key Figure that we have defined an Inflow and Outflow for (in the aggregation tab). Can someone please explain in detail how this Non-*** will be calculated with Inflow and Outflow.
The Non-*** has Aggregation of SUM and exception of LAST
Here are our results (and the Inflow and Outflow KF's are ***)
We have a test query showing the KF for Inflow, KF for Outflow and KF for the Non-*** value.
The Inflow KF shows 26320
The Outflow KF shows 12428
The Non-*** KF (with the 2 above Inflow/Outflow) shows 66002
We thought this Non-*** would be calculated as Inflow (minus) Outflow. So the total of the Non-*** we were expecting 13892.
How does this Non-*** work with Inflow/Outflow? We can't find anything on this.
Thanks so much,
CM

Hi CM,
this has been discussed so many number of times in SDN.. and please search the forum on the same..
Also for ur ref:
non-cumulative key figures
Inventory management: non-cumulatives VS. snapshots
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f83be790-0201-0010-4fb0-98bd7c01e328
http://help.sap.com/saphelp_nw70/helpdata/EN/7e/96cc373de44040e10000009b38f8cf/frameset.htm
How to implent inventory cube 0IC_C03 with Transformation & DTPs
Thanks
Assign points if this helps

Archive Stock Cube with non-cumulative nature

Hi All,
I have been trying to archive the Inventory (Stock) Infocube as we have more than couple of hundread million records in the cube and it is taking long time to execute query.
I know how to acrive the regular cubes and DSOs, but I couldn't find any helpful documentation where I can know how to archive the Infocube with non-cumulative nature or containing Marker update.
Can anyone pleaes post the link of document?
BTW, we are using BI7.0 SP15
Thanks,
Dhaval

Hi,
There are two ways of archiving data from a non-cumulative InfoCube - time slot archiving and archiving with selection characteristics.
Time slot archiving (recommended)
As an archiving method, you must choose for a non-cumulative InfoCube, time slot archiving for the time reference characteristic. When you recreate an archiving object for a non-cumulative InfoCube, this characteristic is also suggested by the system.
Only archive non-cumulative changes up to a specific point in the past. This reduces the volume of data in the InfoCube. The marker (= end non-cumulative) remains unchanged.
In the variants maintenance screen, in the archive administration, under Non-Cumulatives, choose the Movements Only option.
You are only able to archive the marker if you also archive all of the non-cumulative changes. Subsequently, the contents of the non-cumulative InfoCube are archived completely. In the variants maintenance screen, in the archive administration, under Non-Cumulatives, choose the Movements and End Non-cumulative option.
You must archive the non-cumulative changes (for all times) first, and then archive the marker in a separate archiving run, so that the non-cumulative changes and the marker are stored separately in the archive.
The advantage of time slot archiving is that archiving runs can be carried out periodically using a single variant with a relative time restriction. The alternative archiving method described below does not have this advantage.
Archiving with selection characteristics
In some cases, archiving based only on time slots does not have the required effect of reducing the volume of data in the InfoCube. This is the case, for example, if the non-cumulative bearing objects are subject to high fluctuations, meaning that data is constantly being loaded for new objects and old objects are made obsolete. With time slot archiving, the end non-cumulative remains for all objects until all of the data in the InfoCube is finally archived, even if all the non-cumulative changes for an object have been archived already.
In this case, you want to archive and delete completely any objects that are no longer active in the InfoCube. This means archiving the marker as well. For other objects that are still active, you only need to archive the non-cumulative changes from the past, which means the marker is retained.
When you define the archiving properties for a non-cumulative InfoCube, do not therefore choose the time slot archiving method. Instead, select individually the characteristics that are relevant to restricting archiving runs. The time reference characteristic should also be included in this selection whenever possible.
Using this archiving method, for each archiving run, you need to create selection conditions in a variant. In the variant for the archiving run, in addition to the selection conditions, you can also specify for the selected characteristics whether or not non-cumulative changes and marker data is archived. If you choose to archive marker data, be aware that the time selection contains the maximum value for time.
Please refer to the below link to archive the data for Stock Cube:
http://help.sap.com/saphelp_nw2004s/helpdata/en/3f/c219fe9a46194aa66d55254fdab182/frameset.htm
Hope this helps.
Regards
Tanuj

BI Accelerator - Non Cumulative cube

Experts,
I have to create BIA on inventory cubes which is non cumulative..will the performance work in case of non cumulative cubes for BI acceleraot indexes??

Check the latest...
https://www.sdn.sap.com/irj/sdn/developerareas/bi?rid=/library/uuid/11c4b71d-0a01-0010-5ca0-aadc2415b137
Question
Are there any restrictions for InfoCubes that are not appropriate for the BI Accelerator?
Answer
No. All InfoCubes can be used in conjunction with the BI Accelerator. The former restrictions for non-cumulative key figures do not exist anymore.
Hope it Helps
Chetan
@CP..

Concept of Non-cumulative KYF

Hi experts,
   We are using some non-cumulative KYFs in our FI customizing cubes. It really brings troubles for the project. Like:
   - Poor query performance
   - No special 0FISCPER value due to setting as 0CALDAY for the base time reference characteristic
   - No useful aggregates could be created as 0CALDAY can't be removed from any aggregate
    As so many troubles show up, I can't help wondering: where is the advantage?
    In our cube, Z1BALANCE is a non-cumulative KYF with inflow (0DEBIT) and outflow (0CREDIT). What is the difference if I set a general KYF Z2BALANCE to replace it and write code in update rules: result = 0DEBIT - 0CREDIT ?
    Would you please explain this in general words and examples instead of bunch of links?
Regards,
Aaron Wang

Hi,
At all this is link will help you understand non-cumulative better.
http://help.sap.com/saphelp_erp2005vp/helpdata/en/41/b987eb1443534ba78a793f4beed9d5/frameset.htm
Non cumulatives are calculated at the runtime of the that's why query performance is slow.
The option is to compress the cube at regular time interval in case od non- cumulative.This will help in query performance improvement.
I think you can give any time reference in the cube if you want other then 0calday that's you can do at the cube level.
Ya aggregates cannot be created.
you can use non- cumulative as well as cumulative key figure to the same.
depends upon the scenarion which you are working on.
If you data changes frequently then you should use cumulative key figures.
But if it changes non- frequently then should use non- cumulative.
The advantage is it gives you the values with reference to the time there are cartian scenarion which can only be modeled through non - cumulative.
Like inventory where at any point of time you can have just change in the values of the stock.
i.e. always a delta brings in the change in the values of the invenctory.
Inventory va;ues can be maintained in the form of inflows and outflows.That is waht is increasing the stocks and what is decreasing.
Now if you just subtract( inflow- outflow) it will just give you the value at that aprticular time.
This one page documnet explains everything.
In our cube, Z1BALANCE is a non-cumulative KYF with inflow (0DEBIT) and outflow (0CREDIT). What is the difference if I set a general KYF Z2BALANCE to replace it and write code in update rules: result = 0DEBIT - 0CREDIT ?
you can do it through cumulatives also.But that you will have to maintain at the ODS level and then subtract the key figures in the update rules it and maitain it in the cube.
That will get stored with refernce to the time and will work well.
http://help.sap.com/saphelp_erp2005vp/helpdata/en/8f/da1640dc88e769e10000000a155106/content.htm
Hope it helps
Thanks

Early warning system for inventory management,

Dear Friends,
I had an issue related to early warning system for inventory management, i.e, if the stock goes below the specified level the system should trigger the mail.
Pls. explain how to configure
regards
Suresh

Solved

BAPI - Issue in fetching non-cumulative KF for Inventory

Similar Messages

Maybe you are looking for