Customer Message Notification - 981138/2008
MIT Lincoln Laboratory is currently upgrading R/3 to ECC 6.0 and we are performing integration testing with our SRM 5.0 test machine. We have been experiencing consistent problems on purchase order creation, whereby purchase order information (inclusive of packed decimal custom data) is created on SRM 5.0 (our ED1 system) and is sent over to R/3 (our RD1 system) and the purchase order is automatically put on hold. A record in table EKKO is created and has an 'X' in the EKKO-MEMORY field. A record entry in the application log table, BALHDR, also is created. When a subsequent edit on a P/O to make it a P/O CV (purchase order change version) takes place, the pertinent record in table EKKO has the MEMORY field initialized and the BALHDR entry is deleted.
In SRM 5,0, we implemented class ZCL_IM_MLL_BBP_EXC_PO_OUT in method IF_EX_BBP_ECS_PO_OUT_BADI~BBP_B46B_PO_OUTBOUND to package all the purchase order data (including custom fields) to R/3. All of the appropriate mapping took place prior to a RFC to R/3.
Within backend debug sessions, we have seen the behavior of our custom BADI (implementation of ME_BAPI_PO_CUST) on the R/3 side to get our customer information into the purchase order header, item and accounting structures. The following structures are filled appropriately:
CI_EKKODB (Header data)
CI_EKKODBX (Header X data)
CI_EKPODB (Line Item data which contains a packed decimal field)
CI_EDPODBX (Line Item X data
CI_COBL (Accounting data which contains a packed decimal field)
CI_COBLX (Accounting X data)
In R/3, we employ IF_EX_ME_BAPI_PO_CREATE_02~MAP2I_EXTENSIONIN (as seen in the one of the attachments). Considering we have used ASSIGN statements with FIELD SYMBOLS involving the CASTING clause, we have done everything we can to assure we avoid data type problems in matters related to the item and accounting data.
In program SAPL2012/L2012F06 in form MOVE_HEADER_DATA_IN,there is the call to the aforementioned custom BADI and table L-PAREX has all the data it needs to execute successfully. Subsequently, in a call to SAP's function module, BAPI_PO_CREATE1 (program SAPL2012/L2012U02), there is an internal table, RETURN, which will eventually contain messages that includes warning versions of ME 887 (Error transferring ExtensionIn data for enhancement &1) - relating only to the item data (structure CI_EKPODB) and accounting data (structure CI_COBL). Again, these structures contain packed decimal fields.
As you continue processing and eventually go to class interface CL_MESSAGE_HANDLER_MM in method GET_LIST_FOR_BAPI, the EVENTS table has data and a message table, RE_MESSAGES, will be populated and used to identify in SAP's code that there is a reason to put the P/O on hold. It is actually function B46B_DPO_TRANSFER in program SAPLBBP_PD_DRIVE_46A that does final error table storage prior to the database commit using function BAPI_TRANSACTION_COMMIT. There will be some post-processing in R/3 which will record the P/O on hold and some post-processing when returning to SRM.
Please provide us with some insight for our system and release that would fix this. I have been on SAP's SDN site, that SAP has had numerous notes to work involving this particular situation for P/O, contracts, P/O requisitions, etc.. For example, we know that the solution for SAP OSS note 1124803 is installed in our R/3 system and it does not work. It is our conclusion that this requires a follow-up adjustment to SAP's code to accommodate packed decimal field for the creation of a purchase order. Please get back to us as soon as possible. If anyone has any insight on this problem, please let me know.
Thanks,
Philip M. Mooradian