Corey Warawa Hitachi Solutions Architect

During the procurement process it is quite common to acquire the requested goods from different vendors - either external or intercompany.  In these situations, it would be very useful to be able to take a single approved purchase requisition line and create purchase orders for multiple vendors to fulfill the requirement.

For example, a quantity of 100 items is requested in rush fashion using a purchase requisition.  During sourcing, the Buyer determines that a single vendor cannot supply all 100 items in a timely fashion.  Accordingly, they will source the goods from multiple vendors.

Currently, the only options to handle this using standard D365 functionality are:

1. Create a PO for one vendor from the approved requisition line; adjust the line amount; and manually create additional POs for the other vendors and quantities.
   • This makes it very difficult to trace the items from the purchase requisition to the PO for follow-up and audit purposes.
2. Cancel the approved requisition line and ask the requester to create a new requisition with multiple lines representing the number of vendors that POs will be created for.
   • This is extremely inefficient and very frustrating for the requester as they have already followed the process to request the items and should not have to create another requisition simply to address the fact that the items need to be procured from multiple sources.

All PO lines created for procurement categories set the underdelivery and overdelivery percentages to zero since these cannot be defined on procurement categories.  Accordingly, the PO line for a procurement category must be edited each time it needs to be overdelivered or cancelled (underdelivered).

Providing this configuration ability will allow organizations to improve PO receiving efficiency within their defined company tolerances.

In many instances, multiple approved purchase requisition lines (from different purchase requisitions) can be procured from the same vendor.  However, it is highly unlikely that the requisition lines from the different requisitions have the same accounting date (which can be defaulted from the requested date via Purchasing policies).

A parameter should be added to the Purchase order creation and demand consolidation rule in Purchasing policies to “Allow consolidation of requisition lines with different accounting dates”.  This will allow flexibility for organizations where the accounting date provided by the requester is not critical.

D365 would do the following when the parameter is set to “Yes” and the user attempts to create a PO for multiple requisition lines where the accounting dates differ.

1. Indicate to the user that the requisition lines have different accounting dates and ask if they would like to proceed with creating a single PO (from the Release approved purchase requisitions list page or the Consolidation opportunities form).
2. Ask the user to provide the accounting date for the PO header.
3. Create the purchase order.

Adding an approved purchase requisition line to an existing unconfirmed PO would address the following scenarios:

1. The Buyer overlooked the approved requisition line when the PO was created.
2. A minimum PO amount is required to receive a discount with the vendor.

The addition of this functionality would eliminate potential confusion with vendors as it would reduce the number of POs directed to them.  Furthermore, it would reduce internal effort required to receive the goods, process invoices and follow-up on any issues that arise.

This function should be added to the Release approved purchase requisitions list page.  During the process, D365 would need to compare the accounting date on the requisition line to the PO.  If these differ, the user should be asked if they wish to proceed using the accounting date already on the PO header.

Similarly, it would make sense to be able to “pull” an approved purchase requisition line into a PO.  The PO would have a function where the Buyer would see all the approved purchase requisition lines available to add to the PO.  The accounting date comparison and notification would be performed as identified above.

Create one PO from a Consolidation Opportunity when the Requested dates are updated on the lines using the Bulk Edit function.

The consolidation opportunity is often used to group purchase requisition lines for similar products to streamline the procurement process with a vendor.  However, current functionality does not support this when multiple lines with different requested dates and accounting dates have been added to the opportunity.

The process is as follows:

1. Set the Use requested date as accounting date parameter in the Purchase requisition control rule policy is set to "Yes".
2. Create and approve requisition lines with different requested dates (accounting dates will match the requested dates based on the parameter in step 1).
3. Create a consolidation opportunity and add the lines created in step 2 to the opportunity.
4. Update the requested date and vendor on the opportunity lines using the Bulk edit function.  The accounting date will automatically update to match.
5. Close the consolidation opportunity.
6. Multi-select the consolidation opportunity lines and click the Create purchase order button.

Current functionality will result in multiple purchase orders being created (corresponding with the lines that originally had different dates).

This is not intuitive or productive.  Now, the procurement department needs to either:

1. Manage several purchase orders for the same vendor instead of having all the consolidation opportunity lines appear on one purchase order; or
2. Manually delete the "extra" purchase orders and add the lines to one of the POs that was generated.  This will result in the reference being lost between the requisition and the purchase order.

When a user has been given a security role with read-only access, there is a message at the top of the form that says "Click the Edit button to make changes" even though the user does not have access to do this.

This is often confusing and frustrating for users as they don't know what they should or should not have access to.

Subsequently, the "Click the edit button to make changes" Infolog should be removed if a user has read-only access to a form.

Dynamics should have the capability to make the Purchase Requisition workflow legal entity specific.

The recommended solution is as follows:

1. Still allow for an organization-wide Purchase Requisition workflow to be created.
2. Enable legal entity specific Purchase Requisition workflow configurations.
3. Create a parameter in Procurement and Sourcing to identify which Purchase Requisition workflow should be used for the legal entity.

This recommendation will create configuration flexibility to allow organizations to make Dynamics work for their business.

Currently, workflow for purchase requisitions is associated to the organization - meaning that it is used for all legal entities.  This is very limiting and challenging for organizations with multiple legal entities as the approval routing is rarely the same.

Accordingly, this results in either:

1. The workflow configuration becoming extremely complex and difficult to maintain due to multiple layers of conditions and task assignments.
2. The business having to compromise and adjust their processes to fit with the system limitation.

When using the Purchase requisition > Copy lines function, the current logic attempts to copy the "Requester" from the source lines into the new lines on the destination purchase requisition.

This is very problematic and limiting for an end-user as it prevents them from being able to copy lines where others were the "Requester" unless they have been assigned as a requester on behalf of those individuals via the Purchase requisition permissions configuration (Procurement and sourcing > Setup > Policies > Purchase requisition permissions).

Instead, the logic for the Purchase requisition > Copy lines function should be changed so that the "Requester" on the new lines in the destination purchase requisition is defaulted to the user performing the copy function.  The "Requester" from the source lines should not be referenced at all.

A purchase order cannot be linked to a purchase agreement once the PO header has been created.

This is problematic as a Buyer may not always know or remember that there is a purchase agreement in place with a vendor for certain items/procurement categories.  This is complicated even further when purchase agreements have been created for specific projects.  When this happens the Buyer needs to delete the existing PO and create a new one, ensuring that the purchase agreement is referenced.  This is very inefficient.

It would be extremely beneficial to be able to link a PO to a purchase agreement after the PO has been created.  The function could filter the active purchase agreements based on the following criteria when attempting to create the link:

1. Vendor account
2. Project ID (if a Project PO)
3. Item/Procurement Category

Once the purchase agreement has been selected the user would then be able to update the PO lines to create the link as needed.

The Project Category should be able to be edited on a Purchase Order line created from a Purchase Requisition.

In many cases the individuals who are creating purchase requisitions are not familiar with project accounting.  Accordingly, they may not know - or care about -  the Project Category that they are selecting.  

Subsequently, once the PO is created from the purchase requisition the Project Category cannot be adjusted.  This would result in the PO needing to be deleted and a new purchase requisition having to be created (an approved requisition line cannot be revised).

The probability of this happening is quite high.  When PO approvals are required (as this is where the vendor and pricing have been finalized), instead of purchase requisition approval, the Project Category errors would be recognized.  At this point the problem cannot be fixed and a new purchase requisition and PO must be created.