Corey Warawa Hitachi Solutions Architect

Currently, when a purchase order is created from an approved purchase requisition line, the Approval status on the PO is set to "Approved" even when the Activate change management parameter is set to "Active" and an active Purchase order workflow configuration exists.

This is incorrect as the purchase order Approval status should be set to "Draft" awaiting submission and review via the configured Purchase order workflow.

This design could result in purchase orders being confirmed and sent to vendors without ever being approved. Below is ascenario where this could happen.

1. Purchase requisition is created. The Vendor account and unit pricing is entered by the requester without confirmation with the vendor (based on previous purchases, estimate, etc.).
2. Purchase requisition is reviewed and approved by operations staff (e.g. Project Foreman or Project Superintendent). Their focus is determining whether or not the items are required, not how much they cost.
3. The approved purchase requisition lines are transferred to a purchase order either manually or automatically based on the Purchasing policies.
4. Since the purchase order is "Approved", Purchasing assumes that the details have been vetted with the vendor and the necessary reviewers have approved. Accordingly, they confirm the purchase order and send it out.

This is extremely risky as the reviewers in the Purchase order workflow who are responsible for approving financial commitments never even looked at the purchase order. Consequently, the organization now has a legally binding agreement with the vendor without proper internal approvals.

Currently, all of the purchase order lines list page/inquiries are filtered for "Open" lines.  These are useful, however there is also a need to have an "All purchase order lines" list page or inquiry.

This list page/inquiry would give users the capability to meet various requirements such as:

1. Determining from which vendor(s) products were purchased in the past and for how much.
2. Determining the frequency and most recent purchase of products in the past and analyzing purchasing patterns.
3. Performing analyses on purchased quantities and unit prices (i.e. min/max, average, total, etc.).
4. Vendor delivery performance.
5. Accessing documents that were attached to PO lines in the past for reference (i.e. spec sheets, quotes, etc.).

At minimum, users should have the ability to filter and sort on the following fields to increase flexibility:

1. PO #
2. Line status
3. Item
4. Procurement category
5. Vendor
6. Purchase requisition
7. Delivery date
8. Confirmed delivery date
9. Project ID
10. Project category
11. Site
12. Warehouse
13. Quantity
14. Unit price

It would be extremely useful to have an "All purchase requisition lines" list page where the user can view related purchase orders and product receipts.

At a managerial/supervisory level, it is necessary to monitor the status of all product requests for a department, project, etc.  Accordingly, a list of all purchase requisition lines would increase efficiency as the user does not have to access individual purchase requisitions to view the lines.  Additionally, allowing the user to sort and filter as required will enable them to meet many requirements.

At minimum, the following fields should be available for sorting and filtering:

1. Purchase requisition ID
2. Line status
3. Item
4. Procurement category
5. Quantity
6. Site
7. Warehouse
8. Project ID
9. Project category
10. Product name
11. Requested date
12. Purchase order

Finally, allowing the user to navigate to related purchase orders and product receipts (where they exist) will enhance their capability to understand the complete picture from one location rather than having to navigate to multiple areas to view this information.

All system generated workflow notifications should be configurable and be able to be activated and inactivated with parameters in System Administration.

In most implementations clients like to tailor the workflow notifications that are created when actions occur (i.e. reject, approve, reassign, etc.) in the workflow configuration.  This is done to provide the users who are receiving the notifications - both in the client and via email - with details regarding the item (i.e. PO #, Project ID, Journal batch, etc.).

Unfortunately, the system also creates generic emails in some instances.  An example of this is when an item is rejected.  Consequently, the workflow originator (user who submitted) receives two notifications - the first is the message configured in the workflow and the second is: "The current record has been returned to you, or you have been asked to make a change.  Perform any required actions and choose resubmit to resume processing."

This causes frustration for users as they can become overwhelmed with D365 notifications and emails.