Issue with load from livecache

[Former Member]

Dear all

In our APO system we have encountered a strange issue with data loaded from livecache into the infocube.

Problem is in the infocube, where there are two requests with a forecast version data with the same amount of data.

When I look in my infocube in APO I see e.g. the two following request IDs for a given product:

REQU_4CZ4SQ5PSM9V5PHJCHTIS24GK is the most recent load from Livecache (replacing any previous livecache loads).

APO_R43U3KZLM0V3WVK112YEK3KKLE cannot be located. It is not available on the infocube manage section

Ultimately this results in double data for this given product.

Do any of you have an idea as to what this APO_* request could be triggered from?

This is the input from the BW-team:

This indicates that an APO program has modified the infocube data without updating the request tab of the manage infocube. But it has updated the request id of the data which is transformed. With subsequent loads into the infocube, these records are split based on different request idu2019s, and loaded collectively into BI.

I hope you can help me out.

Best regards,

Anders Thinggaard

[Former Member]

addition/update:

It seems that the issue appears when realignment is run overnight for livecache and infocube. The source combination gets loaded into the infocube with a request ID starting with APO_. Meanwhile the combination is created in livecache. When data is then loaded from livecache into infocube it happens with another request ID called REQU_ resulting in two separat XXX.

The issue was discovered in BW, where data was doubled for a given product/cust. combination (which was at some point realigned as a destination combination).

The mystery is however, that sales in livecache (which is loaded daily from Infocube) is not doubled. I cannot see that we filter on req. IDs in the load from infocube into livecache. Weird right?

1. Have any of you experienced anything similar?

2. Would it make sense to only realign in livecache (will the source combinations then be deleted in the infocube, if that it meant to be?)

Regards, Anders

[Former Member]

Hi Anders,

The requests starting with APO* is from realignment and the request starting with REQ* is from live cache to BW load through a infoPackage.

It seems in your case you are loading data from livecache through IP and then running a realignment on the infocube with a copy logic "Add" instead of "overwrite" and so the record is doubling up.

Example:

Load through IP:

Plant________Location_______Qty_____request id

P1____________L1__________100______REQU8723492842

Then you do a realignment on the infocube with realignment table having copy and realign L1 to L2

Plant________Location_______Qty_____request id

P1____________L1__________100______REQU8723492842

P1____________L2__________100______REQU8723492842

If your table has realignment from L1 to L1, then it doubles the record! If it is overwrite it changes the same record from L1 to L2.

Please check if this is your case.

[Former Member]

Hi Visu

It seems I made a typing error in my description of the problem. It is of course the DESTINATION combination, not the SOURCE combination, that is written into the infocube when realigning on the infocube.

This, of course, creates the request ID starting with APO. Besides that I get the request starting with REQU when I load from livecache using an infopackage. So far so good.

What confuses me though is that when I load back into livecache (load my planning area) is seems to pick up the correct amount of data (not taking the APO* request into account) whereas my load to my external BW out of my APO infocube seems to pick up both the REQU* and the APO* requests, resulting in dublicate data.

Have you had this challenge as well?

My first idea is to make the BW team make some ABAP coding leaving out any request ID starting with APO*. However it seems to me that this is a stardard functionality of APO, and I'd like to get to the bottom of this...

Best regards,

Anders

P.S. As I understand, the copy logic only dertermines whether data from source combination is added to or overwriting the data for the destination combination.

[Former Member]

Just curious, why can't you load directly from the planning area into your cube in BI?