Purchase Order Re-approval in Dynamics 365 Finance and Operations

 

PURCHASE ORDER RE-APPROVAL IN DYNAMICS 365 FINANCE AND OPERATIONS

This article provides detailed information about purchase order re-approval process in Dynamics 365 Finance and Operations. Re-approval logic triggers additional approval process in case changing selected field values on the purchase orders.

Let's get started.

CONTENT Introduction Solution components Demo Conclusion

INTRODUCTION

The purchase order (PO) workflow is a widely used IT Application Control (ITAC) in Dynamics 365 Finance & Operations (D365FO), especially for SOX-compliant organizations. Its primary purpose is to ensure internal approval before processing purchase orders. 

This article examines whether purchase orders must go through workflow approval when created under specific scenarios, such as:

• Firming a planned purchase order
• Releasing an approved purchase requisition (PR)

The answer is no. If the purchase orders are already required, additional approval is unnecessary.

Planned purchase orders are system-generated based on demand signals, reviewed, and approved before being converted into actual POs. If no further procurement team approval is needed after PO is created, then the firming process should be designed accordingly.

Purchase requisitions (PRs) must go through a workflow approval process, typically starting with a department manager and continuing through additional levels based on total cost and signing limits. If the resulting POs do not require additional approval, the PR approval process should be configured with this in mind.

However, if a created PO is touched and changed, it should be subject to a re-approval process. This article explains how to configure the system to bypass PO approval when originating from PRs or planned orders while ensuring re-approval when modifications occur.

SOLUTION COMPONENTS

Change management activation: Enable change management for POs by setting the Activate change management option on the Procurement and sourcing parameters. When change management is enabled, POs must go through an approval workflow after they've been completed.

Navigate to Procurement and sourcing >> Setup >> Procurement and sourcing parameters.

Activate the change management.

When change management is enabled, POs move through six approval statuses, from Draft to Finalized. After an order has been approved, users who want to modify it must use the Request change action. In this case, the approval status is changed back to Draft, and PO can be modified. After changes are done, PO can be submitted for re-approval. The field changes subject to re-approval is configured using a Re-approval rule for purchase orders policy on the Purchasing policies.

Purchasing policy setup: The re-approval rule within purchasing policies is an optional rule that defines the criteria for requiring re-approval when a purchase order is changed. The selected fields are evaluated in the purchase order workflow when the "Requires purchase order re-approval" condition is set up in the workflow.

Navigate to Procurement and sourcing >> Setup >> Policies >> Purchasing policies.

Select the policy and click on it.

Select 'Reapproval rule for purchase orders' under the policy rules.

Then select the most recent policy on the right side of the screen.

The next screen is the most important one. This is where re-approval triggers are configured. The example below shows that when the total amount of any line is changed, the order will be routed to the approval process.

Workflow configuration: The final and crucial step in the purchase order re-approval process is configuring the workflow itself. To ensure that re-approval is triggered when necessary, the workflow must include a conditional decision to evaluate whether changes require additional approval.

Navigate to Procurement and sourcing >> Setup >> Procurement and sourcing workflows.

You can see a very basic workflow configuration for re-approval as below.

This workflow says that:

If re-approval is not needed (reapproval = no), follow the left path. In this case, the workflow is automatically approved upon submission.

If re-approval is needed, follow the right path. This triggers the actual approval process that the system follows.

The final step in the workflow configuration is to set this workflow as the default for purchase orders.

With the necessary solution components in place, the next step is to see how these configurations work in action. In the following demo, we will walk through the purchase order re-approval process in Dynamics 365 Finance and Operations, demonstrating how change management, purchasing policies, and workflow configurations come together to enforce re-approval when necessary.

DEMO

Scenario 1: Firming a Planned Purchase Order

• Firm a planned purchase order and confirm that no additional approval is required.
• Modify the purchase order by changing the total price via a change request and confirm that additional approval is triggered.

Scenario 2: Converting an Approved Purchase Requisition to a Purchase Order

• Convert an approved purchase requisition (PR) into a purchase order and confirm that no additional approval is required.
• Modify the purchase order by changing the total price via a change request and confirm that additional approval is triggered.

Scenario 3: Creating a Purchase Order Directly

• Create a purchase order manually and confirm that approval is required.
• Modify the purchase order by changing the total price via a change request and confirm that additional approval is triggered.

This articles demonstrates Scenario 2 and Scenario 3.

Scenario 2: Converting an Approved Purchase Requisition to a Purchase Order

Navigate to Procurement and sourcing >> Purchase requisitions >> Approved purchase requisition processing >> Release approved purchase requisitions.

Select the PR line that will be converted to PO.

Note that PR price is $900.

Convert PR to PO.

Note that created PO is in Approved status that doesn't require PO approval.

The second part of the scenario is making a change on the order that doesn't impact pricing.

Unlock the PO by requesting a change.

Assign a warehouse to the PO header.

Submit the order for workflow approval.

Note that order is automatically approved since the requested change doesn't impact the pricing.

The workflow approval history of the order is as below:

The workflow assesses "no need for re-approval" as 'True' and completes the process automatically.

Scenario 3: Creating a Purchase Order Directly

A brand new purchase order is created and click Submit to initiate the workflow approval process.

The system evaluates the "No need for re-approval" condition. Since this is a new PO, the system determines it as 'False', meaning the approval process must be completed.

The PO routes through the designated approval hierarchy. Once all approval steps are completed, the PO status updates to "Approved.

Open the approved purchase order.

Click Request Change to modify the document.

Add a new line.

Re-submit the PO to workflow.

The workflow is triggered again and routes the PO for approval.

The PO arrives in my approval queue for review.

Upon approval, the PO status updates to "Approved" again.

Let's make a small change that doesn't impact pricing.

Since this change does not affect the item price, quantity, or financial impact, the workflow automatically completes without requiring additional approval.

Let's also change the warehouse on the PO from 11 to 12.

Since this change does not affect the item price, quantity, or financial impact, the workflow automatically completes without requiring additional approval.

CONCLUSION

In conclusion, the purchase order change workflow is a key control for SOX compliance in Dynamics 365 Finance and Operations. Properly configuring change management, purchasing policies, and workflow conditions ensures that modifications to approved POs are subject to re-approval when they impact financial or operational integrity. This structured approach helps enforce accountability, prevent unauthorized changes, and maintain an auditable procurement process while aligning with compliance requirements.

Security Role Assignments in Dynamics 365 Finance and Operations

SECURITY ROLE ASSIGNMENTS IN DYNAMICS 365 FINANCE AND OPERATIONS

This article provides detailed information about the user security role assignment methods available in Dynamics 365 Finance and Operations. These methods are essential for managing user access and ensuring secure system operations.

Let's get started.

CONTENT Introduction Role assignment levels Role assignment methods - auto Role assignment methods - manual Demo Conclusion

INTRODUCTION

Role assignments can be automated through query-based rules or handled manually using data management tools or direct assignments at various levels, including global, organizational hierarchy, and company-specific scopes.

By exploring these methods, you can gain a better understanding of how to effectively manage security roles to align with organizational policies and compliance requirements.

Let’s explore these details. 

In Microsoft Dynamics AX and Dynamics 365 Finance and Operations (D365FO), security roles are always assigned to users, as every user has a different function in maintaining a Segregation of Duties (SOD)-compliant environment. This critical function underlines why security roles are often referred to as role-based security roles, emphasizing their alignment with user responsibilities and access needs.

ROLE ASSIGNMENT LEVELS

Security roles can be assigned to users manually at different levels, depending on the scope of their responsibilities and the organization's structure.

Global

At the global level, role assignments apply across all legal entities in the system. This method is straightforward and requires minimal maintenance. Once a user is assigned to a role globally, they gain access to all legal entities within Dynamics 365 Finance and Operations (D365FO) permitted by their role. Users can seamlessly navigate and interact across all entities, as long as their assigned role grants the necessary permissions.

Organization Hierarchy

This level of assignment is ideal for environments with many legal entities, as it leverages the organizational hierarchy to streamline role management. By assigning a user to a role at a higher node within the hierarchy (e.g., a main branch), the role is automatically inherited by all subordinate nodes. This approach significantly reduces administrative effort while ensuring consistency across organizational levels.

Company

At the company level, role assignments are specific to individual legal entities. This allows for precise control over user permissions within a particular entity but comes with a higher maintenance overhead. This method is beneficial when users require distinct roles or access restrictions tailored to specific legal entities.

ROLE ASSIGNMENT METHODS - AUTO

This feature uses query-based rules to automatically assign security roles to users based on specific criteria.

Navigate to System administration >> Security >> Assign users to roles

The screen is used for both automatic and manual security role assignments for users. Let's talk about automatic role assignments first.

Click Add rules.

This blog serves as a trusted resource and provides additional information on various topics. In line with this purpose, please find the query details listed below:

FMDynamicRoleAssignmentWorkerPosition

• Purpose: Assigns roles to users based on their worker position.
• Primary Table Used: HcmPosition and related worker position records in HcmWorker.
• Use Case: Automatically assign a specific role to users in a defined position (e.g., HR Manager, Procurement Specialist).

FMDynamicRoleAssignmentWorkerTitle

• Purpose: Assigns roles to users based on their worker title.
• Primary Table Used: HcmTitle and HcmWorker.
• Use Case: Automatically assign roles based on titles such as "Senior Accountant" or "Operations Manager" to enforce position-based security.

LedgerJournalPostControl

• Purpose: Assigns roles to users responsible for posting ledger journals.
• Primary Table Used: LedgerJournalTable and related configurations.
• Use Case: Ensures users who are part of a posting process receive appropriate permissions, like "Ledger Clerk" or "General Accountant."

Select All Users

• Purpose: A query that selects all users in the system.
• Primary Table Used: SysUserInfo.
• Use Case: Assigns roles universally to every user in the system, often used for roles like "Employee Self-Service" where access is granted to all employees.

SysUserInfoDataset

• Purpose: Provides user information for queries.
• Primary Table Used: UserInfo.
• Use Case: Assign roles based on specific user attributes, such as email, user ID, or company association.

SysUserSecurity

• Purpose: Assigns roles based on existing user security setup.
• Primary Table Used: UserInfo or similar security configuration tables.
• Use Case: Dynamically assign roles based on users' existing security roles or privileges.

TrvExpMobileMasterDataQuery

• Purpose: Assigns roles to users based on travel and expense management data.
• Primary Table Used: TrvExpTable or related travel and expense data tables.
• Use Case: Automatically assign roles like "Expense Approver" or "Expense Submitter" for users involved in expense workflows.

UserInfoPartitions

• Purpose: Assigns roles to users based on their data partition association.
• Primary Table Used: UserInfo and partition configurations.
• Use Case: Helps manage access across partitions in multi-tenant environments by assigning roles specific to a data partition.

VendVendorPortalUsers

• Purpose: Assigns roles to vendor portal users.
• Primary Table Used: VendUserSetup or VendTable for vendor records.
• Use Case: Automatically grants roles like "Vendor Portal User" or "Vendor Approver" to users associated with vendor accounts.

ROLE ASSIGNMENT METHODS - MANUAL

Security roles can be manually assigned to users using two different ways.

• Data management
• Manual assignment 

Data management: Data management method gives you ability to import user & role assignments in bulk. This approach allows  for assigning roles to users at all levels, including global, organizational hierarchy, and company levels.

Manual assignment: This is the most commonly used method for assigning security roles. You can navigate to the specific user record and assign a security role directly at all levels (global, organizational hierarchy, and company levels).

Now, let's discuss the combination of role assignment levels and role assignment methods.

DEMO: User & Security role assignment at organizational hierarchy level - Manual assignment

The following example demonstrates how to a assign security role at the organizational hierarchy level.

Navigate to System administration >> Users >> Users and select a user and assign a role to the user.

The next step is to assign this role to an organizational hierarchy.

Highlight the role and click Assign organizations.

This screen shows that current selection is valid for all legal entities. 

Click 'Grant access to specific organizations individually' to assign access to a specific legal entity or an organization hierarchy. 

This selection gives you two options in the Select organization hierarchy field:

(All legal entities): If this option is selected, the role chosen on the previous screen can be assigned to specific legal entities here. There is no need to select an organization hierarchy. Simply select the legal entity or entities where the role will apply.

• (All legal entities): If this option is selected, the role chosen on the previous screen can be assigned to specific legal entities here. There is no need to select an organization hierarchy. Simply select the legal entity or entities where the role will apply.
• The list of Organization hierarchies. In our case, there is only one: Security hierarchy.

Select the organization hierarchy that is Security hierarchy.

Note that 'Available organization nodes' now shows selected hierarchy's components.

Select the main Retail node, Contoso Retail and click Grant.

The role assignment should have been valid only for Contoso Retail GLRT since I didn't select Grant with children.

Is that really the case?

Actually, it's not. The selected user was able to perform all (RSM) Accountant role duties in any of the retail companies.

I conducted further investigation and realized that selected hierarchy node, along with all its subordinate levels, had been assigned to the same role.

As result, it really doesn't matter whether you click Grant or Grant with children. The system will behave the same way: Assigning selected hierarchy node, along with all its subordinate levels.

CONCLUSION

Managing security roles in Dynamics 365 Finance and Operations doesn't have to be a complicated or time-consuming process. Among all the methods available, assigning roles at the organizational hierarchy level stands out for its efficiency. It not only saves a lot of time by automatically applying roles to all subordinate nodes but also makes ongoing maintenance much simpler. Instead of juggling multiple assignments at the company or global level, you can rely on the hierarchy to handle most of the heavy lifting.