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


Purpose

The purpose of this page is to provide users with a guide on how the central procurement system calls the connected system to create an employee self-service requisition.

Overview 

With the Employee Self Service SSP Fiori Purchase Requisition an Employee can send purchase requisitions to a connected system, if the Workflow, SOA Interface and the Employee are configured. 


This process can be split to the following steps: 

  1. An OData call which will call the service. This service does a test call to the BAPI: BAPI_PR_CREATE and in case it returns errors the creator must correct them to proceed.
  2. Once the OData call is successful the central system will post a PR in the local system and the workflow will determine the approvals. 
  3. Only when the workflow is successful in releasing the document will the system map and create an XML message PurchaseRequisitionReplicationRequest_Out. This XML message will be processed on the connected system side to create the Purchase Requisition.

OData

When the order button is pressed, the logic calls the Method: IF_MMPUR_CENTRAL_PROC_API_DRV~SEND of the Class: CL_MMPUR_SSP_REQ_DRIVER.

This will map an OData call and calls the method: check_pr which will trigger a call to the connected system service: /MM_PUR_REQ_CHECK_SRV/PurchaseRequisitionHeaderTypeSet.

This has the whole purchase requisition data as payload.


In connected side the RFC HTTP user maintained in the SM59 will call the method:  CHECK_PR and then the SIMULATE_PR  of the class: CL_ODATA_MMPUR_REQ_CHECK.

This is the method which calls the BAPI_PR_CREATE in test run, to see if a PR could be created in the connected based on the data given by the user.

If the test is unsuccessful then the user will get the response as an error. This is the same as creating a purchase requisition with the enjoy transaction (ME51N) in the connected system.

Workflow /SOAP/ XML

Once the successful response comes back from the check, the local PR posting starts.

The flexible workflow starts with the function module: APPL_MM_PUR_WFL_PR_START in update task.

Only when this is successful, and the local requisition has the (05 release successful) does the XML processing starts.

The workflow user SAP_WFRT will call the function module MMPUR_HUB_SCENARIO_PR_REPLI in the class CL_MM_PUR_APPROVAL method SET_WF_DECISION_RELEASE.

This will call the classes CL_MMPUR_HUB_PR_REPLI_OUT and CL_MMPUR_HUB_PR_REPLI_MAP_OUT to map and create the XML message: PurchaseRequisitionReplicationRequest_Out of the namespace http://sap.com/xi/APPL/sProc.

It is important to note that this process is run by the system user SAP_WFRT and Flexible Workflow hence the user must be customized according to the SAP Documents: 3246759 and 2568271


Related Content

Related Documents

SAP Help  PurchaseRequisitionReplicationRequest_Out

Related SAP Notes/KBAs

SAP Note 2721368 - Issue with Network & Activity fields in Central SSP Purchase Requisition Fiori App

SAP Note 2773848 - Issue with WBS element field in Central SSP Purchase Requisition Fiori App

SAP Note 2683221 - Central Procurement: Supplier Part Number is not transferred from SSP PR to connected Backend System

SAP Note 2615805 - Issue with Account assignment mapping during replication of SPP PR: Central Procurement

SAP Note 3063486 - Implementation Note to Include Tax Code in the Replication Logic of Hub System for Central Requisitioning

SAP Note 2788796 - Central Procurement: PR replication and Multiple Account assignment issues

SAP Note 2673285 - External WBS Element in the active table

SAP Note 3155672 - Central Requisitioning: Supplier Material Number incorrectly mapped in Purchase requisition

SAP Note 3098502 - Line breaks in text of PR are lost in connected system

SAP Note 2568271 - Change of workflow system user and workflow system jobs with S/4HANA On-Premise 1709

KBA 3246759 - Authorisation required for SAP_WFRT user using the flexible workflow


  • No labels