.png)
Situation: Client "Segurado Industries" has 100+ Legal Entities with 8 managerial levels (DOA) and currently approvals are processed through email and manual business processes. This leads evidently to inefficiency in usage of time. Additionally, it happens quite often that approvals are queued up as of an approver's PTO as well as that approvals are wrongly routed. The high turnover in personnel is a reason herefore. Lastly, there is no visibility where the approval work item is actually “stuck”.
Requirements: A user requires the ability to process a purchase requisition workflow approval in alignment with the DOA (=Delegation of authority) and spending limits. The PR workflow approval request needs to be send via mail. In case of PTO, the workflow approval the user will need the capability to be reroute the approvals for a certain amount of time. A user will need to have visibility in the progress of the workflow approval process.
Solution approach - Brainstorming: Purchase requisition workflow with multi-tier delegation of authority by spending limits: Usage of signing limit policy; PR workflow with automatic action that auto approves PRs within signing limits; Automatic work item assignment to direct manager in case of exceeding signing limit; Routing of approval work items to direct manager (managerial hierarchy); Usage of User Options to route workflow to another user in PTO situations, No user specific approval workflows; Position specific approval workflow, Email template and email notification via email setup.
Configuration: The following step-by-step instructions with additional clarifications will guide you through the configurations for the solution above and aid your understanding.
1. System Administration - Workflow infrastructure configuration
Navigation path: System administration > Setup > Workflow > Workflow infrastructure configuration
The workflow infrastructure is a necessary setup for the workflow to run. In general, it consists of two components that are both hosted on Application Object Server (AOS) - the managed workflow runtime as well as the X++ workflow runtime. And, the X++ workflow runtime itself consists of workflow runtime API, a messaging batch job and a message queue. The workflow infrastructure uses batch processing on the AOS and .NET Interop to integrate both subsystems and to pass messages from one subsystem to another.
In the below example, I selected the "empty batch group" as workflow messaging batch job, as the workflow due date processing batch job as well as as the line item workflow notification batch job. The "run as" execution account is specified as Admin. The repeat job after the specified number is populated with 1 as well as the repeat job after the specified number is specified with 30.
A batch group is an attribute of a batch task and lets an Admin specify which AOS instance runs the task.
2. System Administration - Users
Navigation path: System administration > Users > Users
Create a user manually or import a user from AAD - Users are internal employees of your organization, or sometimes also external customers and vendors, who require access to the system. Here, we imported my userID.
After the userID is imported, we need to assign the correct security role that allows to approve purchase requisitions. Running security analysis under System administration > Security > Security configuration, we can see that the purchasing manager has the "approve PRs" duty assigned.
Thus, we assign the purchasing manager role to my imported userID and every userID higher in the DOA that may need to approve a PR.
3. Human Resources - Worker, Positions, Jobs and Employees
Navigation path: Human Resources/Workers/Workers
Navigation path: Human Resources/Workers/Employees
Navigation path: Human Resources/Positions/Positions
Navigation path: Human Resources/Jobs/Jobs
We create a worker record for my userID first. After creating the worker record, we add the worker record under System administration > Users > Users to the Person field for my imported UserID.
As a next step, we create a job and a position. We assign the job to the position. A position is an individual instance of a job. For example, the position, “Sales manager (West),” is one of the positions that is associated with the job, “Sales manager.” A position exists in a department and has only one worker associated. Note: the job will be later referenced in the job rule in the spending/signing limit policy.
Worker record:
Job record:
On the Positions form, we add additional details such as the worker assignment - means which worker is holding this specific position - as well as reports to position - means the direct manager that will be approving PRs outside my signing/spending limit.
Position record with job record and worker assignment:
To be able to create PRs, we additionally need an employee record for our worker above. We can add an employee record for a specific or all LEs from the Worker form under "Employment history".
3. Organization administration - Signing limit policy
Navigation path: Organization administration/Signing limits/Signing limit polices.
The signing limit defines the largest financial commitment that a worker is authorized to make on behalf of the employer. All commitments outside a worker's spending limit require an approval by a worker's manager. Also, there is a difference between spending limits and approval limits. A spending limit described the maximum amount that a worker is authorized to spend while the approval limit is the maximum amount that a worker is authorized to approve. The signing limit policy also allows you to specify a specific signing limit/approval limit per transaction type such as purchase requisition and purchase orders.
Under job rule we assign which job is associated to the selected signing limit. As we learned prior jobs are assigned to positions and positions are assigned to workers with a reports to position.
3. Procurement and Sourcing - Purchase requisition workflow
Navigation path: Procurement and sourcing/Setup/Procurement and Sourcing workflows
The workflow process moves purchase requisitions through the review process, from an initial status of Draft over in Review to a final status of Approved. After a PR is created and submitted for approval, the workflow kicks off and either auto-approves when automatic actions are set up or creates approval work items and routes the approval work items through the right channels depending on workflow setup. After a PR is approved, it can be released to a purchase order.
See below the workflow setup for PR approvals by spending limit and based on DOA.
The above automatic action auto-approves the PR when the approval amount is in the preparer's spending limit and thus do not require a manager approval.
When the email template/parameters are set up, the above will send an email with the PR number and a link that guides an preparer directly to the PR that was approved.
The above specifies what action are allowed for this workflow - here, we e.g. allow delegation and allow requesting changes in addition to simple approval and rejections.
When the email template/parameters are set up, the above will send an email with the PR number, LE name, Requester and a link that guides an approver directly to the PR to be approved. See full work item instructions below:
"Purchase Requisition # %Purchase requisitions.PurchReqId% is waiting for your action.
Alert details
Link to web: %Workflow.Link to web%
Legal entity: %Purchase requisitions.Purchase requisition lines.Source document line.Accounting distributions.AccountingLegalEntity%
Purchase requisition number: %Purchase requisitions.PurchReqId%
Workflow originator: %Workflow.Workflow originator%
Requester: %Purchase requisitions.Requester%
Thank you!"
We specify the hierarchy which the workflow will consider when routing approvals. The conditions specify the criteria herefore - means here we specified to route an approval item to employees' managers if the employees spending limit is not sufficient and end the workflow as soon as that condition is met.
The below describes the condition when this approval step is ran - means always when the employee's spending limit is not sufficient.
We can also add an escalation path if no approval action has been taken for X amount of time.
3. Result
As a result when the employee submits a PR within its spending limit, the workflow will auto-approve. When the employee submits a PR outside its spending limits, the workflow will create an approval work item for the employee's manager (based on reports to position specified on position). If the approval amount is also outside the manager's approval limit, the workflow will create another approval work item for the manager's manager. (based on reports to position specified on position) This process continues till the condition is met that the approver's spending limit is higher than the PR amount.
Note: Make sure all approver have the correct security rights to approve the PR.