What is it for?
In Central Procurement, purchase requisitions are replicated from connected systems. Without an automation process in place, these requisitions land on the operational purchaser’s desk—specifically in the “Process Purchase Requisitions Centrally” app. Here, the purchaser must manually decide on the next steps, which typically include:
- Converting the requisition into a Purchase Order (PO), Central Contract, or Sourcing Request
- Adding it to an existing PO, Central Contract, or Sourcing Request
- Assigning a Source of Supply
- Closing or forwarding the requisition
Each decision and subsequent action takes time. While the effort per requisition may be minimal, in large organizations, the sheer volume of transactions leads to significant operational overhead.
Automation with SAP’s Automation Framework
To address this challenge, SAP provides the Automation Framework within Central Procurement—a powerful tool designed to fully or semi-automate the purchase requisition process. By leveraging this framework, organizations can:
- Reduce manual workload for operational purchasers
- Accelerate procurement processes by eliminating repetitive decision-making
- Enhance process consistency through predefined automation rules
- Optimize sourcing and procurement efficiency at scale
Like any software solution, the Automation Framework requires proper configuration and governance to ensure optimal performance. Organizations must carefully define automation rules and workflows to align with their procurement strategy and compliance requirements.
How to use it
Basic Customizing
Before setting up automation, the automation process itself must be defined. This includes specifying the steps that should be executed during automation. Typical steps include:
- Purchasing Group redetermination
- Field defaulting
- Consistency checks (validating data integrity)
- Checks for exclusion or inclusion lists
- C-Part management(low value) processes
- Search and assign source of supply
- Trigger integrations with other systems
- …
Since the framework offers enhancement possibilities in the form of BAdis, basically everything can be done.
Once the steps within the automation process are defined, the so-called actions within the automation framework can be created. As a start you can consider an action as a step within the automation process.
The definition of the actions happens old school in SPRO under
SAP Customizing Implementation Guide à Materials Management à Purchasing à Central Procurement – Settings in Hub System à Define Actions for Configuring the Automation of Business Processes
Within this customizing we have the following fields:
- Action Definition
Choose a wonderful ID, of course limited to 10 characters
- SAP Object Type
Currently the only object the framework works on isPrmtHbRpldPurchaseRequisitionOther business objects might follow, but currently this it the one to choose
- Action Type
Here you have three options- Check Action
The action(or automation step) is meant for a check only. As result, such an action only returns FAILED or PASSED - Modify Action
With a modify action you want to change the fields of a replicated purchase requisition - Complex Action
A complex action could be the creation of a purchase order, or the trigger of an interface
- Check Action
So when choosing the action type, it needs to be clear what the action is actually for.
- Action Sub Type
Here you have the two options- Simple
A simple action is basically an action for which no additional code is required.
Later, when we discuss the apps with which to set up the process, you will see, what can be done within “standard” and what are the limitations. So for now let’s leave it like this. - BAdi
This speaks for itself. Actions with this subtype are referring to a BAdi implementation with custom logic.
- Simple
- Grouping enabled
Used in general for follow-on document creation actions to signal, if a grouping of different PRs into one follow-on document is possible.
So let’s assume one step within the automation process is a check against an exclusion list for suppliers. If a PR item is replicated with a supplier that is contained on the exclusion list, you don’t want to automate. To apply such a logic, some custom code is required. An action for this could look like the following:
Now let’s make it more complicated: If the supplier is excluded, you want to fill a certain field with the value ‘X’. Changing the field value can be done with a simple modify action, no coding is required.
You might ask, why use two actions here, one BAdi check and one simple modifier? Well, you also could have set up one modify action of type BAdi and then within the BAdi implementation execute the check and set the field value.
Which actions to set up, how to implement them etc. needs to be decided by the IT team, depending on the exact requirements and software architecture.
Important: There are already three standard complex actions available:
- CREATE_PO: Configure predefined complex actions for the creation of purchase orders from purchase requisition items. The complex action to create a purchase order from purchase requisitions is grouping enabled by default. The grouping is enabled based on the suppliers and purchasing organization assigned to purchase requisitions. You can also add additional grouping criteria based on your requirements.
- ASSIGN_SOS: Assign unique source of supply. The assignment works only if there is a single unique source of supply for the purchase requisition.
- CREATECCTR: Configure predefined complex actions for the automatic creation of central purchase contracts from purchase requisition items. The complex action to automatically create central purchase contracts is grouping enabled. As a result, you can configure the grouping criteria while creating central purchase contracts for the purchase requisition items. If you have not mentioned any grouping criteria, then a single central purchase contract is created per purchase requisition item.
Once all the actions are created in customizing, you can start defining the process within the app “Manage rules for automation of business processes”.
For the app itself and also for everything related to it, the documentation can be found here.
Upon opening the app, the list of rules which have already been created are displayed.
A rule hereby is a set of actions which within the rule can be set in dependency to each other if required. In addition, for each rule selection criteria can be added to determine if a rule should be carried out or not. All the fields available for the general rule creation are well described in the app documentation and therefore shouldn’t need further explanation.
Let’s instead start looking at the following hypothetical automation process with the following steps:
- If no source of supply is assigned to the PR item, try to find one using standard action ASSIGN_SOS
- If a supplier is assigned to the PR item, check if the supplier is contained on the exclusion list
- If the supplier is not contained on the exclusion list, try and create a PO using standard action CREATE_PO
So let’s set it up in the app.
First create a rule named AUTO_PO, which then looks the following:
As a selection criteria I used the document type in order to apply the rule only to PRs of document type “NB”. Then I also set up two automation rule activities. Rule activities can be used to structure the rule. In this case I created one activity for the actions that are related to the processing of PR data, and one activity for the actions related to the PO creation. As mentioned, this has only a structural effect, you also might use the activity information in your code to perform a certain logic for all actions within this activity, but in general there is no need to use multiple activity areas if you don’t want to.
Next, within each activity ID the actions need to be defined and since actions can depend on each other, always start with the action that comes first in the process. In our example, this is the source of supply action.
The setup of the action is straightforward for this one, but now we have some new fields and options. Also see the help page to get the up to date information.
- Automation Status
With these two dropdowns you can influence the automation status of the PR item depending on the outcome of the action. The automation status will be displayed in the “Process Purchase Requisitions Centrally” app and hence signals the purchaser, if the automation worked or not.
The values you can set here are “Automation Failed”, “Automated”, “No Influence” and “Not to be automated”.
Depending on what your action does, you can set this custom specific. We will talk more about it later.
- Prerequisite
This we will use later when we set up dependencies between the actions. Here you can add the actions that should be executed before.
- Input
You can specify the input and input sets for the actions based on your requirements. If you have maintained an action as a prerequisite, you can mention if the documents that successfully executed in the prerequisite or the execution failed in the prerequisite or all the documents processed in the perquisite needs to be considered for this action.
- Parameters
You can provide the field names that are required to define the parameters at the action level. The values that can be maintained here are:
-
- Maintain the grouping criteria for complex actions enabled for grouping
- Maintain the fields and values for simple modifier actions
- Maintain the fields that need to be changed for complex actions and BAdI modifier actions
- Maintain the fields and values for simple check actions
- Maintain the fields that need to be changed for complex actions and BAdI-based check actions
In our first action I only set the automation status outcome to “No Influence”. So no matter if a source if supply was assigned with the action, the automation status doesn’t change.
Let’s continue with the next step, our check for the vendor exclusion list.
You can see that for this action, I chose to set the automation status to “Not to be automated” in case the action fails and if it passes, to “No Influence”.
What I want to achieve is that in case the vendor is on the exclusion list, this PR item is not to be automated, the purchaser needs to take action! And if the vendor is not contained, then simply keep going.
I also set the source of supply action as a prerequisite, which means, that before the vendor check is executed, we first try to find one in case there wasn’t already one assigned.
Next comes step 3, the creation of the PO. For this, we simply want to use the standard action and of course, we need to ensure, that the vendor check was executed before. To do this, the action is set up like this:
In case the PO creation fails, the automation fails, in case the PO creation succeeds, the PR item is marked as “Automated”.
The supplier check was set as a prerequisite action and in addition, under “Input” I specified that the check action needs to pass in order for the PO action to be executed. We only want to create a PO, if the supplier is not on the exclusion list…
Under rules parameters I added the plant. For the standard PO creation action, the rule parameter influences the grouping for the PO creation. Since multiple PR items can be grouped in one PO, this parameter let’s us influence the conditions for the grouping apart from the usual fields like supplier, company code, purchasing org and purchasing group.
So from a setup point of view we’re already done. We created a rule and added three actions to it. Now the only thing left is to run the automation framework.
This is done by running the report MM_PUR_AUTOMATION_SCHEDULER. The report can be scheduled as a job using the app “Schedule Automation of Business Processes”, but of course, especially for testing, you can also run it directly in SE38.
The report executes all active rules that have been created in the app and for each rule applies the following logic(high level description):
- Select all PR items that match the selection criteria of the rule
- Check for each PR item, if it has been automated before.
- If yes, don’t execute the actions
- If no, execute themThe check is done by looking at the entries in table MMPUR_AUTO_STAT. Within this table the standard remembers which actions have been executed for a PR item.
- Save automation status for each item for which actions have been executed
When the report is finished, all PR items that matched the selection criteria of the rule have been processed by the automation framework which means, that each PR item has now an automation status, in our example this should be either, “AUTOMATED”, “AUTOMATION FAILED” or “NOT TO BE AUTOMATED”.
This status gives a clear indication for the purchaser, if he needs to take action on a PR item or not and is visualized within the PPRC app as seen on the following screenshot:
Since the automation status is a standard filter criteria, a purchase would naturally filter in the PPRC app for all PR items, which have either status “Automation Failed” or “Not to be automated” since only these ones need to be worked on.
In addition to the status, the purchaser is able to display automation errors and also can retrigger the framework for a PR item if needed. To do this, he needs to mark the PR items which have failed and click on “Display automation errors”.
In the upcoming screen, the marked items are displayed an here the purchase also have the options to retrigger the framework for a selected PR, or delete the automation status in order to include the PR again in the next run.
If for example, the connection failed during the PO creation, the purchaser could simply run the framework for the PR again. In other cases, an adjustment on the PR might be necessary because a custom check failed and so on.
The tight integration of the framework into the PPRC app allows us to design a process that tries to automate as much as possible and in case our automation fails, let’s us visualize the reason to the purchaser. Of course at then end the purchaser has to touch the PR, but giving a status and also a message, speeds up the process and also helps to tune the framework for the future.
About the author
Markus is leading ASAPIO’s S/4HANA Consulting. He became an ASAPIO partner in 2008, guiding global organizations through complex SAP S/4HANA transformation and integration projects with his ample experience and deep technological knowledge.
His expertise includes but is not limited to SAP Ariba Central Procurement, SAP MM, and custom development with ABAP and BAdI enhancements.
