BAPI_PO_CHANGE debug question (on a 470)

[matteo_montalto]

Hello experts,

I'm facing a problem in distribution from an SRM system. It deals with deletion flag for service lines ... Fortunately I have an alternative system in which distribution goes smoothly, so after a first glance, I tried to debug both system in parallel since they're both 470 and with similar support package (L2012* includes are pratically identical).

Now... I found a difference in the stack execution in L2012F25 (form SET_OBJECT_ATTRIBUTES_LOEKZ); here's a snippet of the code:

* get current data
    lo_item = im_po->lookup( <item>-ebelp ).
    CHECK NOT lo_item IS INITIAL.
    CALL METHOD lo_item->get_data( IMPORTING  ex_data = ls_item_data
                                   EXCEPTIONS failure = 1 ).
    CHECK sy-subrc IS INITIAL.
    CALL METHOD lo_item->get_datax( IMPORTING ex_data = ls_item_datax ).
* update deletion indicator
    CHECK ls_item_data-loekz NE <item>-loekz.
    ls_item_data-loekz = <item>-loekz.
    ls_item_datax-loekz = mmpur_yes.
    CALL METHOD lo_item->set_datax( ls_item_datax ).
    CALL METHOD lo_item->set_data( ls_item_data ).

Here, ls_item_data-loekz assumes value 'L' on the backend affected by the problem, while the same field has a blank value on the other system in which things are going ok. Test cases for these systems are substancially identical.

Since I'm quite unexperienced with abap obj and class methods, can any BAPI_PO_CHANGE expert help me finding where the lo_item object is created/populated in the execution and what should represent? As far as I understood, it should get the instance of the item as on DB (data persistent on the backend), but if that's the case I'm a bit confused since the item is deleted on EKPO (and so its service lines in ESLL).

[mvoros]

Hi,

that code is pretty straightforward and I think you understand it correctly. It gets reference to PO item (method LOOKUP) and then it gets data and update indicatos (methods GET_DATA and GET_DATAX). After that it updates PO item deletion indicator if CHECK ls_item_data-loekz NE <item>-loekz.

Maybe onr comment. The deleted items are not removed from DB. They are just flagged as deleted with field LOEKZ.

Cheers

[matteo_montalto]

Hello Martin and thanks for your useful help.

If my interpretation is correct, then there's something I didn't understand, maybe you could help me once again.

This is the test sequence I did, for both the system; the first (A) goes wrong while the second (B) is fine:

- creation of a simple purchase order in SRM: 1 service item with two service lines(outlines); distribution on the 470 backend: everything's fine.

- deletion of the service item on SRM and distribution; again, everything's fine on both backends.

- fictitious modification on the PO (e.g., change text description) and distribution: here's the critical situation.

On backend (A), the service position is shown as DELETED (EKPO-LOEKZ = 'L') while service lines referring to it are not deleted (ESSL-DEL blank).

That's the problem I tried to investigate debugging. On that

CHECK ls_item_data-loekz NE <item>-loekz

this is the situation:

backend A (wrong):

ls_item_data-loekz = L

<item>-loekz = L

backend B (ok):

ls_item_data-loekz = "blank"

<item>-loekz = L

So, the interpretation we gave to the first sketch of code doesn't match exactly with the trace of execution. Input, for BAPI_PO_CHANGE, are identical for both cases, same data on EKPO and ESLL for both backends.

Do you have any hint?

A good point for the analysis should be the point in which ESLL deletion indicators are set; I think these ops are done in the PROCESS_NON_INTEGRATED_COMP form (L2012F28), could anyone please provide a feedback on these assumptions?

I'm having a hard time debugging this 😛

[mvoros]

Hi,

one way how you can try to find a difference is to use SE30. You can set it up to record full stack trace. So there is a chance that you will spot a difference in stack trace.

Have you searched for OSS notes? It looks like it might be an error in SAP. You mentioned that both system are 4.7 but there still can be difference in patch level.

Cheers

[matteo_montalto]

> one way how you can try to find a difference is to use SE30. You can set it up to record full stack trace. So there is a chance that you will spot a difference in stack trace. 

That's a useful transaction I didn't knew of, thanks. Unfortunately, I probably traced wrongly both the variants for BAPI_PO_CHANGE on the two systems, since the tracestack is quite different even though includes and FM seems identical in the two backends.

Can you provide a link to an howto, or instructions to trace the execution? Please note I'm actually working on two variants, basically identical, for BAPI_PO_CHANGE, on both systems.

> Have you searched for OSS notes? It looks like it might be an error in SAP. You mentioned that both system are 4.7 but there still can be difference in patch level. 

This sounded immediately as a "known" problem, or better, a problem I faced times ago (and don't remember how I solved it ).

Anyway I doubt it's a matter of note because we worked a lot to patch these two systems in order to support at best service items in PO. That's the reason why, even though the systems are currently at different Sp level, I'm almost sure that concerning BAPI_PO_CREATE1/BAPI_PO_CHANGE and service-related issue, they're substancially identical.

EDIT: I didn't understand how to trace via SE30 in this particular case. I have a saved input variant for BAPI_PO_CHANGE, but if I track from SE30 for BAPI_PO_CHANGE... then also the dynpro load and the pathway for loading the variant is logged.

I'd like instead to get only the trace from the moment i execute the BAPI using the saved variant.

Edited by: Matteo Montalto on Jun 15, 2010 2:36 PM

[mvoros]

This [blog|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/17050] [original link is broken] [original link is broken] [original link is broken]; is really good.

Cheers

[matteo_montalto]

Got it. A missing note on a method of a class Thanks again for your help and support