Data Mismatching between R3 and BI Costs and Allocations

[kamalkishorepurohit]

Dear BI Masters,

I have small enqry regarding the data pulling from SAP R3 to BI. We have a Info-provider *CO-OM-CCA: Costs and Allocations* (ZCCAC11)_ , scheduled every night. It is observed that some the records of back dated are not showing in Info provider where as available in SAP R/3. ( we can say its mismatching ) now i want to pull this unique data without duplication.

there is option to pull data ie delet complete record and re-fill setup table , but i want to pull only specific date data in BI.

your valuable suggestion will be highly appreciated.

With Regards

Kamal Purohit

INDIA

[Former Member]

hi

run repair full request for particular time

thx

vij

[kamalkishorepurohit]

Hi vijay,

can you give me more detail on this.

Thanks

Kamal

[Former Member]

Hi Rohit,

Detail steps to be followed during repair full request:

First you need to understand why REPAIR FULL REQUEST. In general once ODS will not allow you to activate full load ( if contains intialization and delta load through daily loads). By mentioning as an infopackage as repair full request system would allow you to load data & activates loads (though initializations done for ODS). Let's take an example you have ODS1, ODS2.

And ODS2 gets daily delta loads from ODS1.

So your flow like this R/3 -> ODS1->ODS2. By chance you could miss either delta from R/3 to ODS1 / ODS1 to ODS2.

If delta missed between ODS1 - ODS2 we need not to fill Set up tables again as data already available in ODD1.

Scenarion 1 (Delta missing from R/3 to ODS1) :-

1. In RSA7 (Delta queue) holds replica of last delta for "Delta repetition" along with "Delta update" you could see data in both tables (I hope these tables) by switching you selection between these two.

2. First time when you run Delta infopackage from ODS1 data fetches from "Delta queue" from RSA7 and same data will store for "repeat delta" for back-up purpose.

3. If your delta loads fails you would get repeat delta option, once you choose this option now data comes from "Delta repetition" (Back- up purpose).

4. Hence it is always suggest to run Delta info package two times to ensure you emptied "delta queue" and delta "repitition".

5. By chance even repeat delta also will not suffice to fetch delta, then we need to fill step tables get all data.

6. For repair full request, please follow the step by step.

1. Ensure above level data providers require delta from ODS1 and run all delta infopackages on 8ODS1 (info source) two times to ensure you have not missed any delta from ODS1 to above data targets.

2. Then delete data target contents (for ODS1) and delete setup tables and fill set-up table for that specif application areas (T-code OLI*BW) and fill set up tables again.

3. Goto your your Infosource connected with ODS1 and create a info package and go to scheduler tab mention this request as repair full request and goto data target contents and please pick ODS1 not any others (unless if required). This leads to data duplication if you don't uncheck other data targets.

4. Update mode must be full update, by default. And run info pacagke(of course prior to this step you need to run delta initialization without data transfer).

5. Now your ODS1 consists two requests (1 for Intialization 2nd one for Full repair request). Activate both requests and start executing your delta load from next loads.

6. The major advantage you could unlock users immediately once initialization done and ODS will allow you to activate full repair load.

Now take second scenario - Delta missing from ODS1 to ODS2...in this flow as well you could follow same logic (Step 1,3,4,5). As BW (ODS1) hold missing delta information need not to worry about set up tables deletion and fill..

Let me know if any clarifications required.

Best regards,

Venkat

[Former Member]

You are in a bit of a bind as the CCA9 only extracts new records

Note - there is no concept of a set up table for this extractor (or another finance extractor) - the extract is based on the cpu date of the record on cobk and is extracted via a run timestamp

In bwom_settings - what setting do you have for this extractor with the mostrecen flag?

Do you currently have a changelog DSO between this datasource and the cube - if so you will have to rerun a full repair load for the entire period and pass through the DSO to reget the records (that is if they are not in the repeat delta queue mentioned above in a different post)

If you do not have a DSO then you will have to selectively delete that period from the cube before reloading to avoid duplicates