Hi All,
I encountered the scenario requiring the creation of a purchase order in draft status after firming the planned order
As per standard, when a purchase order is created from a
planned order, the purchase order workflow is automatically submitted and
approved.
Customization is required to modify this behaviour, so that
the PO is created in draft status, allowing users to review and submit it manually.
Code change:
Create a extension for a class ‘ReqTransPoMarkFirm’ and
create a COC for the method ‘shouldSkipWorkflowSubmissionAndApproval()’.
Returning True from this method based on your specified
conditions will set the PO status to draft instead of approved.
Technical Note: This method will be available from V39 (10.0.39 onwards).
Furthermore, I've investigated why purchase orders are created in Approved status as part of the standard process.
I found
interesting blog written by Ali Danish on linked-in, where it's clearly
mentioned the reason of creating the Approved PO and impact of customizing this
behaviour.
Please take a look at the post for a more detailed understanding,
(5) D365 SCM | The Magic of Planning Optimization | Purchase Trade Agreements | Part 2 | LinkedIn
As mentioned in the above blog, there is a possibility of creating duplicate planned orders when a user runs MRP with purchase orders in draft status.
However, we can
avoid the creation of duplicate entry by following the below steps.
- The PO workflow should be approved with-in one
day.
- The planner has to make sure, no open purchase
orders are exists in a system for a particular item before firm.
- The MRP process should be executed Weekly or two
weeks once.
Note: Please
double-check with your respective functional before implementing this
customization.
Additional information about PO creation from purchase requisition
Customization is not required when a purchase order is
created from purchase requisition, it will be handled based on the below standard
check box.
Disclaimer: Please note that these
suggestions are based on my personal experience and may not be the only
solution. As always, thoroughly test any changes in your test environment
before moving them to Production.