Skip to Content
Author's profile photo Jessica Li

Some Problems Caused by Buffer When Executing PP-SFC BAPIs

Customers can call BAPIs in custom program. Sometimes, unexpected problems can occur due to buffer is not cleared. I summarize what I have come acrossed here. Hope it is helpful.

Problem 1:

Delivered quantity of a production order/process order doesn’t match the actual material documents.

Customer tries to execute confirmations for multiple production orders/process orders in ONE loop call. BAPI_PRODORDCONF_CREATE_TT(sometimes, BAPI_GOODSMVT_CREATE too) is used.

SOLUTION:

Call function module CO_ZF_DATA_RESET_COMPLETE before BAPI_PRODORDCONF_CREATE_TT or BAPI_GOODSMVT_CREATE.

KBA 2122706 (Delivered quantity of production ordder is not updated correctly if BAPI is called several times in a custom program) describes this.

Problem 2:

Production order has 4 external operations and all of them are with same purchase requisition. When custom program tries to execute confirmations for all 4 operations in ONE call,  unexpected problem may occur for the purchase requisition, e.g. old value in change history always keeps as the first value.

SOLUTION:

Call function module ME_REFRESH_REQUISITION_EXT before BAPI_PRODORDCONF_CREATE_TT.

Problem 3:

Custom program calls BAPI_PRODORDCONF_GET_TT_PROP continuously in ONE call. The proposed batch in second run is different from the proposed run in first run.

As reason, the batches proposed in first run is locked, so they will not be the object for second run. The batch determination keeps the locks, because the goods movements are supposed to be posted and the batches are required for that.

SOLUTION:

Call function module L_PPIM_BATCH_DETERMIN_INIT_INT in between separate calls of BAPI_PRODORDCONF_GET_TT_PROP to initialize the held batches.

Problem 4:

Custom program calls BAPI_PRODORD_CREATE to create order 1, then calls CSAP_MAT_BOM_MAINTAIN to update BOM, and then calls BAPI_PRODORD_CREATE to create order 2 in ONE structure, but the order 2 is still with same BOM component as order 1 without considering new BOM updated by CSAP_MAT_BOM_MAINTAIN.

The standard BOM function modules GET_STPO and other function modules should get executed based on the MMORY value passed to CS_BOM_EXPL_MAT_V2. Normally, the explosion of BOM will determined based on STLNR number and thus repeation will be avoided within the structure.

SOLUTION:
Enhance FM CS_BOM_EXPL_MAT_V2 of BAPI_PRODORD_CREATE to make MMORY = 0 to suit for your enhancement. MMORY=0, means BOM explosion is executed every time. MMORY=1, means if STLNR is same, the BOM from buffer is used.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Pablo Casamayor
      Pablo Casamayor

      Good one!

      Long ago i did something similar thanks to this OSS Note:

      672750 - BAPI material component: Initialization problem


      and the original idea i found it here in this thread by Abhishek Modi:

      BAPI works individually but not inside a function module


      Best regards

      Pablo

      Author's profile photo Nic Teunckens
      Nic Teunckens

      Thanks for this informative Blog :

      Good explanation, clearly Structured, no Fluff just Stuff (from Personal Eperience as you indicated).

      Just as a Reference, some of the EAM-BAPI’s suffer from the same issues with Buffered Internal Tables and Global data when processing for Multiple records (also taken from Personnal Experience). Maybe something for a Similar Blog some day ...

      Anyway, PM/CS Order-related BAPI’s can benifit from similar approaches, as explained in SAP-KBA 1986562 "Missing initialization in BAPI_ALM_ORDER_MAINTAIN / BAPI_ALM_ORDER_GET_DETAIL".

       

      Kind regards

      Nic T.