BAPI_PO_CHANGE not updating condition values no errors

[prince_isaac]

Hi guys

We are trying to use BAPI_PO_CHANGE to update values on PO however in some instances it updates correctly and in some instances it does not.   We have tried looking at SAP notes and none of them seem to address our issue and we have also looked at the coding, config and data of the PO's and we cannot seem to find the issue.   We are able to update the PO's manually in ME22N but in coding it refuses.  Everything seems to check out, can anyone suggest something we could be overlooking?

Message S023 is issued as well but no actual changes are done.

Any suggestions?

regards

Prince Isaac

[prince_isaac]

Hi guys

We are trying to use BAPI_PO_CHANGE to update values on PO however in some instances it updates correctly and in some instances it does not.   We have tried looking at SAP notes and none of them seem to address our issue and we have also looked at the coding, config and data of the PO's and we cannot seem to find the issue.   We are able to update the PO's manually in ME22N but in coding it refuses.  Everything seems to check out, can anyone suggest something we could be overlooking?

Message S023 is issued as well but no actual changes are done.

Any suggestions?

regards

Prince Isaac

[prince_isaac]

just to add more information to my post

POITEMX-PO_ITEMX = SPACE. "we have changed this to X with no change

POITEM-CALTYPE = 'C'. "we have changed this to B with no change

regards

Prince Isaac

[jayanthi_jayaraman]

Hi,

Did you passed the below as well?

POITEMX-CALCTYPEX = 'X'.

change_id is passed correctly in pocond table?

[prince_isaac]

Hi Jayathi

Yes POITEMX-CALCTYPEX = 'X' is filled and so is the CHANGE_ID = 'U' in GT_POCOND as well as  GT_POCONDX-CHANGE_ID = 'X'.

regards

Prince Isaac

[Former Member]

Dear

Maybe u should check BADI ME_PROCESS_PO_CUST.

There u can loop over both header and item data.

Maybe the update works in this BADI?

Can you tell me the code you implement in the BAPI_PO_CHANGE?

Best regards

Thomas Bretonnet

[prince_isaac]

Hi Thomas

Here is a snippet of the code of the tables we filled in

*     Update Purchase Order

         CALL FUNCTION 'BAPI_PO_CHANGE'

           EXPORTING

             purchaseorder     = gs_po-ebeln

             poheader          = gs_poheader

             poheaderx         = gs_poheaderx

             poexpimpheader    = gs_exppoexpimpheader  

             poexpimpheaderx   = gs_exppoexpimpheaderx  

           IMPORTING

             expheader         = gs_expheader

             exppoexpimpheader = gs_exppoexpimpheader_out

           TABLES

             return            = gt_return

             poitem            = gt_poitem

             poitemx           = gt_poitemx

             pocond            = gt_pocond

             pocondx           = gt_pocondx

             poexpimpitem      = gt_exppoexpimpitem     

             poexpimpitemx     = gt_exppoexpimpitemx.  

regards

Prince Isaac

[RaymondGiuseppi]

Which values do you use for

• NO_PRICE_FROM_PO
• POITEM-PO_PRICE
• POITEM-CALCTYPE
• POCOND-CHANGE_ID
• POCONDHEADER-CHANGE_ID

Regards,

Raymond

[prince_isaac]

NO_PRICE_FROM_PO is not used

POITEM-PO_PRICE is not filled

POITEM-CALCTYPE = 'C'.

POCOND-CHANGE_ID = 'U'.

POCONDHEADER-CHANGE_ID not used.

We have noticed that the problematic PO's have two records for condition PBXX and that the additional PBXX record was inserted through an interface with difference between the two records being that it has a "per 1000" price.  Manually removing that in ME22N ad running VL71 with our bespoke code to update the PO called within Vl71 will work.

Also noted that the entry is created with KONV entry for KHERK is set to C(Manual Posting) if changed to A(Automatic) it also works.

regards

Prince Isaac

[prince_isaac]

Hi guys

This issue has now been resolved.

All the new entries for additional conditions have been modified to use CHANGE_ID = 'I'.  Additionally also changed the Calculation type to automatic, POITEM-CALTYPE = 'A' this however creates an anomaly where multiple conditions are added to the PO although the last entry of which will be the correct and relevant one.  That is not an issue..for now..so we will live with that and create a utilty to clean up those additional entries.

regards

Prince Isaac