Skip to end of metadata
Go to start of metadata


This page was created to clarify the application logic of PR XML transfer (PurchaseRequestERPSourcingRequest_Out).


This Debugging Guide can help understanding how the PR is transferred via XML, and what is the logic behind it. This page can be useful for identifying the root cause of an undesired behavior of system.

Before debugging the scenario, it is worth verifying the relevant customizing and functionality first. You can do this according to the following KBA 1968555.

Debugging Guide

Data preparing and processing

To start debugging set a breakpoint in:

  • Method POST of Include LMEREQF06,
  • Method POST of class CL_MMPUR_EXT_SOURCING.

When the PR is saved or released, the breakpoint will stop. Here after processing the PR data, system calls the BAdI FM MEREQBADI_POST. This BAdI calls the method POST of class CL_MMPUR_EXT_SOURCING.

You can press F8, so that the second breakpoint stops. If the second breakpoint is not stopped that means that the Implementation MMPUR_UI_EXT_SOURCING is not active in BAdI ME_PROCESS_REQ, which is necessary to trigger the XML.

Continuing the logic from the second breakpoint, system collects the items.

Then system loops at the item to:

  • Gather the item data,
  • Perform some checks,
  • To fill the XML item table.

Firstly, system gathers the item data.

Then it verifies if the PR is already in central sourcing.

  • If the PR is not yet in central sourcing:
    System checks if PR is valid to transfer (based on item types, statuses, release status, item deletion etc.). If PR is valid, system fills LV_EXT_SEND. If this variable remains blank the item won't be filled in the XML. In the next debugging session go into this Method to find the root cause.

    If variable was filled, system appends the item into table LT_SEND_SOA. Only those items will be transferred that are filled into this table.
  • If the PR is already in central sourcing:
    System checks the status of PR.

    If the status is valid, system appends the item into table LT_SEND_SOA. Only those items will be transferred that are filled into this table.

At this point, the processing of the items has been completed.

Afterwards, system checks if there are any items in table LT_SEND_SOA.

If yes, system triggers the XML process.

If everything is correct until this point and the desired items are in the LT_SEND_SOA table, it is necessary to debug the scenario further in Update debugging.

Update task debugging

 To perform the update debugging, in the debugging session:

  1. Go to menu Settings → Change Debugger Profile/ Settings.
  2. Tick Update debugging.
  3. Click button Save Settings in the bottom left corner of the window next to the green check mark.

  4. Press F8 to let the program run.

  5. The debugging session window will be closed for a couple of seconds and then a new debugging window should appear. 

  6. Press button F9.

  7. In the popup window, choose tab Function Module and fill ME_REQ_TRIGGER_EVENT.

  8. Press Enter.
  9. Press F8.

The breakpoint should stop in FM ME_REQ_TRIGGER_EVENT. Here you can continue the debugging.

Firstly, system sets the necessary data into LT_CONTAINER.

Afterwards system verifies if qRFC or Workflow event should trigger the XML. This depends on customizing set in table T175ESOA_TRIG_C.

In case the qRFC is not set, system will use the Workflow event to trigger the XML. This event is created by the FM SWE_EVENT_CREATE.

In case the qRFC is set, system sets the queue name, which is MMPUR_BUS2105_[document number].

Then it triggers the message in the background.

If everything is correct until this point, it is necessary to debug the queue process further. This only applies for qRFC scenario.

Queue debugging

To perform the queue debugging, you can let the current debugging finish.

Then, it is necessary to deregister the queue, so that the system doesn't process it:

  1. Execute transaction SMQR

  2. In the list search for entry that start with MMPUR.

  3. Highlight the entry and click button Deregistration.

    Note that this will stop the queue processing in the system for the whole MM queue, so perform this only in development or test system, or off business hours.

  4. Click the green check mark.

  5. After deregistering the queue, delete the previously set breakpoints and perform the steps to trigger a PR transfer again (change and save the PR or release it again).

  6. Go to transaction SMQ2 and press F8.

  7. In the list double-click queue MMPUR_BUS2105_[document number].

  8. Double-click the entry again.
  9. Click button Debug LUW.

A new debugging session will be created. Here perform the following steps:

  1. Press button F9.

  2. In the popup window choose tab Function Module and fill MMPUR_TRIGGER_MESSAGE.

  3. Press Enter.

  4. Press F8.

The breakpoint should stop in FM MMPUR_TRIGGER_MESSAGE. System calls Method EXECUTE, and inside that Method EXECUTE of class CL_SE_PUR_PR_WF_OUT.

In this method system gathers the header and item data into LS_PREQ_BAPI_HEADER and LT_PREQ_BAPI_ITEM.

Afterwards, system executes the outbound service processing using Method PROCESS_OUT.

In this method occurs the mapping of data from purchasing structures into SOA structure.

After MAPPING_OUT ran, check whether the data in LR_SOA_PR->* is correct. 

Then system calls BAdI PUR_SE_RFQREQSUITE (Method OUTBOUND_PROCESSING), where it is possible to maintain custom mapping logic. After the BAdI ran, verify if the data is still correct in LR_SOA_PR->*.

Finally, system calls the XML interface to trigger the XML creation.

Here check if it runs without any exception in CATCH block. If an error occurs after the Method ran, it is necessary to debug the logic further into the Method.

At the end of the debugging, do not forget to register the queue again, so that system can process the queues.

Related Content

Related SAP Notes/KBAs

KBA: 1968555 Purchase requisition is not sent for external sourcing via XML