Page tree
Skip to end of metadata
Go to start of metadata


This page was created to clarify the application logic that is used to import release orders from connected system.


As the distributed contract is in a different system, creating a release order for such contract doesn’t update the release order documentation of the central contract automatically. To update the release documentation of the central contract, it is necessary to schedule the import job based on SAP Help page Schedule Import of Release Orders.

The job calls the connected system and gathers the release order number intervals for the contract. Then it calls the connected system again to fetch the details of the previously determined release orders, which will be updated in central system in the release documentation table MMPRC_CCTR_RELOR.

Debugging Guide

Set a breakpoint in the following logic:


Execute the job manually using the desired parameters by executing report MMPUR_CCTR_CALLOFF_SCHEDULER in SE38. Upon executing it, the first breakpoint will stop in Method IF_MMPUR_CCTR_CALLOFF_UTIL~EXTRACT_DATA_FROM_BACKEND.

Here system selects the relevant logical systems in which the import will occur. In case of Ad-Hoc load with contract number, system selects the logical systems into which the distribution occurred (based on table EKPO_DISTR). In other cases, system selects the configured connected systems (table MMPUR_C_BE_SYREG).

System loops at the found systems.

In the loop system checks if this is a local scenario or not. In case of local scenario, system doesn’t need to call the connected system, it just performs a select from EKAB table using Method EXTRACT_CALLOFF_GR_DATA_LOCAL of class CL_MMPUR_CCTR_CALLOFF_UTIL.

In non-local scenario, system calls Method GET_PACKET_DETAILS, which will call the connected system.

In Method GET_PACKET_DETAILS system selects the logical system of the relevant connected system ID.

Then, it calls method SEND.

In Method SEND, system gathers the relevant driver class based on Operation 2RD and the logical system of the connected system (based on table MMPUR_HUB_API_CT).

Afterwards, system calls Method SEND of the determine driver class.

In that Method, system calls Method RELEASE_ORDER_INFO.

In that Method system populates the request URI that will be sent to the connected system and that can be used to continue the debugging in connected system, so make sure you copy that value.

Finally, system triggers the oData service MM_PUR_CCTR_CALLOFF_SRV.

If you don’t receive status code 200 OK in importing parameter LT_RESP_HEADER, it means that the issue is with the connection between the two systems. In case the response is OK, continue to Method PARSE_RESPONSE_TO_TABLE and check, whether the method provides PO numbers (TAG_NAME Purchaseorderfrom, Purchaseorderto) in table ET_RESPONSE_DATA.

If you cannot find the PO numbers in the response, it it necessary to continue the analysis in the connected system. For that, refer to section Debugging the connected system.

If you can find the PO numbers and it is correct, you can continue in this section.

Press F7 and check, if Method PARSE_PACKET_LIMIT populates correct PO numbers (from to intervals) into table <LS_CCTR_RESPONSE>-RELEASE_ORDERS-RELEASE_ORDER_INFO.

Then press F8 to reach the second breakpoint.

The breakpoint should stop in Method FETCH_AND_UPDATE_CALLOFF_DATA. This method is responsible to fetch the details of the POs that are in the previously determined PO number interval.

The logic loops at the found intervals (internal table MT_REL_ORD_PACKETS) and calls Method SEND to initiate the call into connected system.

System gathers the driver class similarly to the previous call and calls Method SEND of the driver class.

In Method SEND, system calls Method RELEASE_ORDER_DETAILS.

The call to the connected system will be a batch request, so system creates a batch payload that will be sent to the connected system.

Finally, system calls the oData service MM_PUR_CCTR_CALLOFF_SRV with the generated payload.

If there is no connection issue and response was received, continue to Method PARSE_RESPONSE_TO_TABLE and verify the PO data in table LT_DATA.

Press F7 until you return into Method FETCH_AND_UPDATE_CALLOFF_DATA. Continue in this Method until you reach Method MAP_ENTITY_TO_HUB_DATA. This method is maps the fetch PO details into the "Calloff" structure that will be saved into DB (internal table LT_CALLOFF_DATA).

Finally, system stores the mapped entries into DB MMPRC_CCTR_RELOR.

Debugging the connected system

  1. Log into connected system.
  2. Set an external breakpoint into Method GET_CCTR_PACKETS of class CL_MM_PUR_CCTR_CALLOFF_DPC_EXT.
  3. Execute transaction /n/IWFND/GW_CLIENT.
  4. In Request URI fill /sap/opu/odata/sap/ + the copied URI value from previous debugging. It should look like /sap/opu/odata/sap/MM_PUR_CCTR_CALLOFF_SRV/GetBEPurchaseOrderPackets...
  5. Make sure that HTTP Method is GET and that the correct Protocol is chosen.
  6. Press Execute.
  7. The breakpoint will stop in Method GET_CCTR_PACKETS.

First system maps the oData parameters into internal variables, then it calls Method GET_CCTR_DELTA_PACKET_SPLIT.

In this Method, system performs the DB select. The screenshot is about Purchase Orders, but there are similar logic for GR and Scheduling Agreements.

The final result can be found in internal table ET_SPLIT. This contains the document number interval that will be sent to the central system.

Related Content

Related Documents

SAP Help - Schedule Import of Release Orders

Related SAP Notes/KBAs

KBA: 3157713 Release Documentation is not updated for Central Contract, when PO is created in connected system for the distributed contract

  • No labels