Procurement workflow in Dynamics AX 2012 – Love and hardship in an implementation

Procurement workflow in Dynamics AX 2012 – Love and hardship in an implementation

A while back I was implementing AX 2012 (R2 I believe – but I will illustrate the learnings in R3) in a Project heavy organization.

I must admit that we underestimated the requirements in terms of the quite advanced requirements the customer had on the process of approving purchase orders. So the first take away I had is to ensure the level of the requirements and challenge complex requirements based on both the cost of setup, test and maintenance.

The workflow requirements were based on purchase orders made towards different projects. The projects were subdivided into different business areas (with area managers) and had different project managers which together with normal hierarchical approval and different signing limits led to little hardship.

On creating a new Purchase order workflow (Under Procurement and sourcing>Setup>Procurement) and sourcing workflows there are quite a few available procurement area workflows. For just the purchase order itself there are both a “header” and a “line” workflow, I have before experimented with line approval but the number of individual approvals where just too overwhelming for the customer so I will focus on the “Header” workflow.

The Purchase order workflow is one that fortunately have a lot of the (toolbox) available workflow elements enabled:

An initial question you should ask yourself on creating an advanced workflow is whether or not to use the Subworkflow option. This allows for having a main workflow that calls (perhaps) multiple subworkflows. Initially it is more difficult to setup (more forms/entities in play) however going forward it may save the organization time and make for a faster rollout of changes. Remember that on changing a workflow all preexisting workflow instances will continue to be on the older workflow while only new instances will be on the new version.

So a simple use of subworkflows is the below where a conditional decision (True/False) sends the workflow down to one or the other subworkflow:

Because the subworkflows do not have the “condition” option of the approval step the conditional decision is likely going to be the way forward for most, typically actually quite a few conditional decisions, just remember to clearly name the decisions for maintenance going forward, “Conditional decision 17” is a poor choice:

An important element to working with workflow is to understand the query that a given workflow is based on – and not least to understand that this is a (developer) editable query. The Purchase order workflow for example out of the box allows for querying on four inter-related tables: The PurchTable (The purchase order header), the PurchLine, the Reason references and the Source document lines (related to the lines)

The query is named in the getQueryName method of the workflow document, so for the Purchase order workflow we are looking for a query called PurchTableDocument:

Here we ought to recognize the same table structure as was seen in the workflow:

Because the requirement from the customer were also on querying on data from the Project table this table then needs to be included in the query:

The details of the above is skipped here (joins, relationships, CIL etc.)

The outcome is an additional data source that can be queried on within the context of the Purchase order (header) workflow:

This allows for saying that for example all the projects with this [project group for example] should be handled by the respective area managers of those projects.

Note: this is one option, a second option is to use the Expenditure participants framework setup under Procurement and sourcing>Setup>Policies>Purchase order expenditure reviewers:

Combined with a named manager on for example the cost center financial dimension. Read more about this option in the Public sector procurement and accounts payable training material:

Second part is getting approval from your manager this is straight forward with the built in Managerial hierarchy option, read more about managerial hierarchy here.

Remember to handle leadership and employees who for one reason or another do not currently have a named manager, empty position, faulty hierarchy setup or perhaps because we are talking about the CEO. Workflows submission unfortunately fail for a number of reason, the listed reasons are some of the most frequent plus that a manager do not have security rights to the entity that is being approved remember the: Home>Inquiries>Workflow>Workflow history for your everyday problem solving.:

A last requirement, which we were unable to deliver on, was that some managers received quite a few “double” approvals – this was the case when a manager for example is both an area manager, a project manager and a hierarchy manager. Unfortunately workflows in AX does not allow for querying on data within the running workflow entity.