SC save badi - how to understand which item position has been updated?

[matteo_montalto]

Hi all gurus,

my requirement seemed quite easy, but revealed to be tricky instead. Basically, I'd need to know in the SAVE badi for shopping cart which position(s) of the SC has/have been updated. Better to explain it with an example:

suppose we have a Purchase Requisition on the backend made up of 3 item position, say item1, item2 and item3. Once the PR has been transferred to SRM (= the SC has been created), the user decides to add into the work area item1 and item3, and to "unlock" item2 because this position needs a modification on the R3 backend.

Item2 is then modified on the backend (say, the description is changed) and then re-transferred to SRM.

Here's the point.

During this transfer, the SC is retrieved and updated; I need to know in the DOC_SAVE_BADI for SC, called during the transfer, which position has been updated/added, but all I obtain from the BBP_PD_SC_GETDETAIL is the UPDATED shopping cart, without any indicator about which positions have been modified/added.

The only reference for the task seems to be the timestamp contained in the CHANGED_AT field, but this isn't surely a precise way to identify modified positions. Moreover, the CHANGED_AT field in the header is always greater than the same field @ item level (otherwise, I'd could easily conclude that all the items with CHANGED_AT greater or equal header's CHANGED_AT have been modified.... but this is not the case, unfortunately).

So I ask to you gurus, is there any way/FM to retrieve such informations at BADI level?

Thank you so much for all your help and suggestions

[Former Member]

Unfortunately, there is no good way. SCs are non version relevant and there is no change document concept for SRM documents. I might suggest to add a custom field for this purpose at item level in SRM in include structures INCL_EEW_PD_ITEM_CSF_SC & INCL_EEW_PD_HEADER_CSF. Populate this field on the ECC side with current date at the time of transfer to SRM (There should be a badi in FM BBP_EXTREQ_TRANSFER but need to appendthe structure on ECC side as well as append the BAPI structure on SRM side too to include the custom field) or could use BBP_PD_BADI_DOC_SAVE in SRM to update the field with current date.

[matteo_montalto]

First of all, thanks for your help

I found two alternative ways to accomplish the task, now I have to check if these are feasible and have no drawbacks....

First one: I could check for diffs from what I have after a BBP_PD_SC_GETDETAIL (the updated SC) and what I have in both CRMD_ORDERADM_I and BBP_PDIGP -> the items which presents differences are the one that have been updated.

Second alternative: I could base a comparison on the CHANGED_AT field, between what I have after a BBP_PD_SC_GETDETAIL and what's stored in CRMD_ORDERADM_I / BBP_PDIGP. If the dates are equal -> no changes, else the item has been changed. This would work perfectly but unfortunately there's a gap between SRM system time and R3 system time, so I should evaluate a delta from SRM with every backend to achieve this solution.

I'll keep the forum informed... maybe could interest someone

[matteo_montalto]

Okie, got it but another - related - problem arised then I'm again here to ask you for a check.

This is the way I used to check for updated items during a PR transfer in SRM:

- getdetail of the SC -> returns an itab containing all the positions of the updated shopping cart;

- BBP_PDVIEW_IAP -> a view that merges infos from BBP_PDIGP and CRMD_ORDERADM_I tables.

The idea is simple: just compare the CHANGED_AT field from the itab returned from the SC_GETDETAIL with the same field extracted from the view. If they're equal -> no changes for that position. If they're not, and tipically wa_item-CHANGED_AT > view_item-CHANGED_AT, then the object has been updated and - at this point - not yet written on the DB tables.

It would work but I noticed a strange behaviour on the system I'm working on. Seems that every time a PR is transferred to SRM, the SAVE BADI for the related Shopping Cart is executed THREE (!!!!!) times. Can't understand why, can anyone confirm it's a standard behaviour?

In such conditions my check fail because it's strictly dependent on the basilar assumption that, in the SAVE BADI, the GETDETAIL method returns details about the SC that hasn't been already written in DB tables (and so, we could say that in CRMD_ORDERADM_I and in BBP_PDIGP we get details on the position BEFORE the transfer is done).

This is merely true only if the BADI is executed once.

Actually, the second time the SAVE BADI is executed a COMMIT WORK has been done, so the above assumption is not true anymore -> this causes my checks to be not valid.

Can anyone confirm it's a standard behaviour that the SC SAVE BADI is executed 3 times each time a PR is transferred to SRM? I'm working on BBPCRM 400 (yep, an old release).

Thanks in advance

[dhinesh_thirugnanam]

Hello Matteo,

I am having quite a similar kind of issue related to bbp_pd not getting updated properly from R3.

Kindly look at my link and throw some light