cancel
Showing results for 
Search instead for 
Did you mean: 

0 records in generic delta

Former Member
0 Kudos

Hi All,

I am creating generic data source on table CDHDR & DFKKCRH using view but delta is not working.

I have choosed UTIME from table CDHDR as delta specific field (Time stamp) & Safety Interval Upper Limit=1800.

But still it is extracting 0 records in delta & in RSA7 also no data but I can see status as below

DataSource ZTEST_V

Delta-Relevant Field UTIME

Time changed

Current Status 13.04.2009 12:01:32

Anybody has idea is there a problem in delta specific field? becoz this is the only time field in my view.

Regards,

Sonal

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Sonal,

You are right in saying that UTIME and UDATE are the delta relevant fields for CDHDR. However, my take on the requirement necessiates a different solution to using BI.

- As I can sense, the requirement is about who / when changed manually, the creditworthiness of a business partner. This is clearly an ABAP report and we should steer away from accessing CDHDR, following the same logic as you have applied to first access CDHDR and then for DFKKCRH.

- Also there is some standard content for the history of movement for creditworthiness in the newly repackaged financial supply chain management --> Credit management area.

- If these options have already been explored and because of constraints you need to proceed with access to CDHDR, I'd suggest writing the code to look up DFKKCRH in 0BPARTNER_ATTR datasource. That way, you need not worry about accessing CDHDR explicitly. Also, changed by / changed on fields are available on 0BPARTNER_ATTR datasource. You may need to check that 0BPARTNER is changed so often through different routes. To be able to ascertain that teh change is down to creditworthiness is critical to identify.

Hope this helps.

Regards,

Ashu

Former Member
0 Kudos

Hi Ashutosh,

Thanks for the information.

Could you plz elaborate 3rd option "writing the code to look up DFKKCRH in 0BPARTNER_ATTR datasource"?

Because I checked DS 0BPARTNER_ATTR, it contain changed by field but it is not related

with the manual changes done by transaction FPCR2 or FPCR1.

I need to capture the manual creditworthiness changes done by Tran FPCR2 or FPCR1.

These changes are only captured in table CDHDR.

It will be very helpful for me if you can provide detail steps for 3rd option.

Also is there any other table which I can use in place of CDHDR? Why we should not use CDHDR table?

Right now I have created view on CDHDR & DFKKCRH 7 delta specific field as UTIME.

Join conditions is

DFKKCRH MANDT = CDHDR MANDANT

DFKKCRH GPART = CDHDR OBJECTID

DFKKCRH BMADT = CDHDR UDATE

selection condition

CDHDR OBJECTCLAS EQ 'FKK_CRDRT'

But still I do not understand why delta mechanism is not working?

I am not sure whether I should use view or FM plz suggest.

Regards,

sonal

Edited by: sonal kokil on Apr 15, 2009 7:57 AM

Edited by: sonal kokil on Apr 15, 2009 8:05 AM

Former Member
0 Kudos

Sonal,

Like I said for option 3, its critical to identify if BP change is specifcally for manual creditworthiness change. As you have confirmed, BP (BUT000) does not change with FPCR1 / FPCR2, this option is ruled out.

Concerning CDHDR, its a HUGE table (ABAP Resources on the team) would confirm and never considered a good practice to access this.

I'd still recommend a generic BI report to users with equivalent info object for BMADT in the selection and a RRI to FPCR3 transaction and let them check who changed the creditworthiness of BP manually.

If however, they are adamant to see the user on the same screen, go for ABAP. Its not MI reporting in anyway: How often a BP creditworthiness has changed is MI, but not who changed it.

But to answer your question technically, you could do with some changes of selections on CDHDR:

put in selection for transaction codes as you know them (FPCR1/2).

The delta can be based on change document number (CDHDR-CHANGENR) as well.

Also, please remove the join condition for DFKKCRH BMADT = CDHDR UDATE.

If everything fails, you can always have UDATE in the selection of info-pacakage and use OLAP variable of yesterday to get changes only.

However, I cannot emphasize enough that generic DS is not the way to go.

Hope this helps.

Regards,

Ashu