Defining business process workflows for purchase requisitions
Defining business process workflows for purchase requisitions
Table of Contents
Overview of purchase requisition review workflow
Purchase requisition workflow in
Microsoft Dynamics AX
Scenarios of purchase requisition
review processes with Microsoft Dynamics AX
Importing
predefined purchase requisition workflows
Example: Leverage Microsoft Dynamics
AX sample workflows
Example: Reuse proprietary workflows
Defining
a purchase requisition workflow from scratch
Example: Demonstrate workflow
authoring
Automatic
purchase requisition approval
Example: Bypass purchase requisition
review during initial implementation phase
Example: Bypass purchase requisition
review based on spending limits
Document-level
purchase requisition review
Example: Document-level review
design-time experience
Example: Document-level review
run-time experience
Line-item
purchase requisition review
Example: Line-item review design-time
experience
Example: Line-item review run-time
experience
Mixed
document and line-level purchase requisition review
Example: Stage-gate review design
time experience
Example: Stage-gate review run-time
experience
Sharing
workflows across organizations
Example: Shared workflow across all
organizations
Example: Different workflows for
different legal entities, using Conditional decision
Example: Different workflows for
different legal entities, using activation conditions
Architecture of purchase requisition
workflow in Microsoft Dynamics AX
Overview of purchase requisition review workflow
Purchase requisitions in Microsoft Dynamics® AX
require a workflow to move them through their life cycle. Purchase requisitions
are entered into the system in Draft status. There are two roles
involved: the Preparer, that is, the worker entering the purchase
requisition; and the Requester, that is, the worker requesting the
product. Those two roles can be the same, or they can be different. The
requesters can be different across the line items of the same purchase
requisition. When the preparer submits a purchase requisition for review, a
workflow is instantiated. Workflow is the technology used by Microsoft Dynamics
AX to move the purchase requisition through its life cycle from Draft to
Approved. During the approval process, the Reviewers get involved
in the process. It is not possible to approve a purchase requisition without a workflow.
However, a workflow that performs the approval automatically without human
intervention can be set up (see Automatic
purchase requisition approval for more details).
Once a purchase requisition has been approved, the follow-up
process through to purchase order creation is currently handled outside of
workflow.
This concept paper requires
a certain level of familiarity with the Microsoft Dynamics AX workflow
infrastructure. It is recommended that the reader be familiar with the
following content:
·
CCAX2012BV015: Business process automation using
workflow
·
CCAX2012IC0021: Workflow implementation
·
CCAX2012HT0071: Implementing a new workflow
·
CCAX2012HT0072: Authoring a workflow I (basic)
·
CCAX2012HT0074: Authoring a workflow II (advanced)
·
CCAX2012HT0077: Authoring a workflow III
(line-item workflow)
·
CCAX2012HT0078: Authoring a workflow IV
(assignments)
Purchase requisition workflows have a design-time
experience and a run-time experience. At design time, a user with the duty to maintain
the procurement process for the company will author the purchase requisition
workflow(s) based on the organization’s business requirements. At run time,
users will participate in the purchase requisition review process based on the
specific workflow that was instantiated for the purchase requisition to be
reviewed.
Purchase requisition workflow in Microsoft Dynamics
AX
In Microsoft Dynamics AX, you can define the purchase
requisition review process in workflow to meet your exact business requirements
for reviewing and approving purchase requisitions. You can define one workflow
that works for your entire organization, or you can define multiple workflows
and activate the correct one based on criteria such as the organization in
which the products are requested. You can also define the workflow at the
document or at the line item level, and you can even mix the two approaches. You
will be using the Microsoft Dynamics AX workflow infrastructure to define and
manage purchase requisition workflows.
There are basically two
different roles involved in the purchase requisition review process:
·
The preparer of the purchase
requisition, who will create the purchase requisition, submit it for review,
and deal with any follow-up actions in the event that changes are requested or
the entire purchase requisition or a specific line item are rejected by a
reviewer. The preparer of the purchase requisition does not necessarily have to
be the requester of all the purchase requests that it contains. Some or all of
the requests could be entered by the preparer on behalf of a different
requester.
·
The reviewer of the purchase
requisition, who will perform whatever tasks have been assigned to them in the
workflow. How many reviewers are required in order to approve a purchase
requisition completely depends on the organization’s specific business process.
Reviewers can span many different business roles within the organization. The
most common reviewers of purchase requisitions are the manager of the item’s
requester, the users responsible for the budget to which the expenditures will
be charged, sourcing professionals who are in charge of sourcing the items at
the best price from the best vendors, and purchasing and accounts payable
professionals who need to ensure that the purchase requisition document is
complete and correct and contains all the information needed to eventually
place a purchase order with a vendor.
The preparer of the
purchase requisition can perform the following actions:
·
Submit
·
Recall
·
View history
The actions that the reviewer
can take are as follows:
·
Task:
·
Complete
·
Reject
·
Request change
·
Delegate
·
View history
·
Approval:
·
Approve
·
Reject
·
Request change
·
Delegate
·
View history
In order for a user to take
action on a purchase requisition (line) that is In review, two
conditions must be fulfilled:
1.
The user must have a work item associated with
the purchase requisition (line) assigned to them.
2.
If the work item is for a workflow Task element
and was assigned to multiple users, a user must have accepted the work item.
Note: As
soon as one user accepts the task, the work item will be removed from all other
users that it was originally assigned to.
Whether or not the user can also change data of the
purchase requisition (line) that is assigned to him or her solely depends on
whether the user has been assigned the security privilege to edit purchase
requisitions.
The flow chart below gives
a general overview of the purchase requisition process and where the review
process falls within it. Please keep in mind that you can configure the
workflow any way you want; you can have any number of workflow elements in it
in whatever sequence you like.
Figure 1 Purchase
requisition process overview
Scenarios of purchase requisition review processes with
Microsoft Dynamics AX
This section
describes the most common end-to-end scenarios of how purchase requisition
workflows can be set up and used within Microsoft Dynamics AX. They are meant
to be examples only and should help you realize how you can implement any
company’s review process in Microsoft Dynamics AX.
Importing predefined purchase requisition workflows
In Microsoft Dynamics AX, workflows can be imported from
an XML file. The Purchasing manager or any other role to which you have
assigned the Enable procurement process duty performs this action. On
CustomerSource and PartnerSource, the product team will make available four
sample workflows that illustrate the most common patterns to jumpstart
implementation of purchase requisition workflows. The user can edit imported
workflows like any other workflow authored in Microsoft Dynamics AX.
Example: Leverage Microsoft Dynamics AX sample
workflows
A company implementing Microsoft Dynamics AX wants to get
a feel for how to use purchase requisition workflow before gathering the
requirements for creating their specific workflows. They import one of the
predefined workflows and activate it. Once familiar with the workflow concepts
in Microsoft Dynamics AX, they adapt the imported workflow to meet their
specific business requirements.
Example: Reuse proprietary workflows
A Microsoft Dynamics AX partner has created purchase
requisition workflows that suit the specific requirements of a niche vertical. They
export the workflows to XML files and import them in each customer
implementation. They then tweak the imported workflows to meet the exact customer
requirements.
Defining a purchase requisition workflow from
scratch
Rather than importing workflows from XML files, the
Purchasing manager or any other role to which you have assigned the Enable
procurement process duty can author purchase requisition workflows from scratch.
Example: Demonstrate workflow authoring
A consultant wants to illustrate to a customer how easy
authoring a purchase requisition workflow in Microsoft Dynamics AX is. They log
in with the Purchasing manager role, create a new workflow of type Purchase
requisition review, and start adding tasks, approvals, conditions, and line
item workflows as necessary.
Automatic
purchase requisition approval
In Microsoft Dynamics AX, you can configure a workflow
that essentially does nothing other than moving the purchase requisition in its
life cycle from Draft to Approved. The system does not assign
work items to any users, and all purchase requisitions are approved
automatically.
Example: Bypass purchase requisition review during initial
implementation phase
Contoso is in the process of implementing Microsoft Dynamics AX.
Before drilling into the details of the purchase requisition review process,
they want to make sure that they can complete the entire Procure-to-Pay
business process from creating a purchase requisition to paying the vendor. To
facilitate this exercise, they configure the purchase requisition review
workflow to automatically approve all purchase requisitions.
Figure 2 Automatic approval
Note: Any
condition that always returns true can be used.
Example:
Bypass purchase requisition review based on spending limits
Contoso requires review of purchase requisitions only if the
total amount of the purchase requisition exceeds the requester’s spending
limit. Therefore it includes a condition in the workflow that checks for the
spending limit and bypasses all other steps in workflow if the spending limit
is not exceeded.
Note: Spending limits
are set up in Organization
administration > Setup > Signing limits > Signing limit policies.
Figure 3 Automatic approval based on spending limit
Document-level purchase requisition review
Many organizations wish to move their purchase
requisitions through the review process as one entity. At any step in the
workflow, actions are taken on the entire purchase requisition. Any reviewer
can only complete, approve, or reject the entire purchase requisition. If a
reviewer wants to reject just one line, he or she must reject the entire
purchase requisition and add a comment to it explaining which line item it is
that should be changed or removed from the requisition. In Microsoft Dynamics
AX, we call this type of review a document-level purchase requisition review.
This configuration of the purchase requisition review
workflow is appropriate if various line items of a purchase requisition do not
require different processing.
To configure purchase requisition review on the document
level you must use the workflow type Purchase requisition review, and
you must not include the Purchase
requisition line-item workflow element
in the workflow.
Example: Document-level review design-time experience
Ken, Contoso’s business analyst, has determined that
Contoso reviews purchase requisitions as entire documents. He uses the Microsoft
Dynamics AX workflow designer to create one workflow of type Purchase
requisition review, to
which he adds one task and two approvals, based on Contoso’s business
requirements.
Ken configures submission instructions to inform the
employee prior to submission about required documentation and applicable
policies. He also enters meaningful Subject and Instruction messages for all
the elements in the workflow. This will help the reviewers to whom work items
will be assigned to understand easily what kind of review is requested.
Ken assigns each of the workflow elements to the correct
audience and sets limits for the duration of each review step. Optionally he
can configure notifications that should be sent to various stakeholders at
different stages in the process.
The picture below shows an
example of what the workflow design for the review process could look like.
Figure 4 Example of
a document-level purchase requisition review workflow
Note: The first
workflow to be created of any workflow type is automatically marked as Default.
If there are multiple workflows of type Purchase requisition review and
they do not have activation
conditions, then the one marked as Default will be retrieved at run time.
This approach can be used if you want to experiment with different workflows,
but at any given time only one workflow should be used. You can select the
workflow by simply toggling the Default
property.
If the workflows do
have activation conditions, the workflow runtime first evaluates whether
any workflow of type Purchase requisition review has a condition that
evaluates to true for the selected purchase requisition. If yes, then
this workflow is instantiated for the purchase requisition. If no, then the default
workflow is used. If more than one workflow returns true for the activation
condition, a runtime error will occur since the system cannot decide which
workflow to use. Therefore, we recommend that you be very cautious when using
activation conditions and make sure that they are unambiguous. Instead of using
activation conditions, you can model the condition explicitly in the workflow.
Please refer to the workflow concept papers for more information about
activation conditions, default workflows, and activation methods. On the
purchase requisition, the activation method activateFromWorkflowType is
used.
An example of a condition at the document level is if
purchase requisition review differs based on the total amount, since that value
can be determined at the document level.
More often, though, the conditions that determine the
workflow to be used needs to be evaluated for each line. This is because a
purchase requisition can contain requests for different requesters, buying
legal entities, vendors, products, and so on. If, for example, requests for
fixed assets need to be processed differently than requests for expenditures,
the condition needs to be evaluated at the line-item level. Please see the
section Line-item purchase
requisition review for more details about the line-item review scenario.
Example: Document-level review run-time experience
When Nicole submits a
purchase requisition for review, a workflow is instantiated and routed to
different reviewers based on the workflow that Ken defined.
Figure 5 Run-time
example of the document-level review workflow
Reviewers can take
the workflow action either from the unified
work list in their Role Center, or by opening the purchase requisition
details form in the Microsoft® Windows® client or on
Enterprise Portal.
First, the
purchasing agent Alicia will verify that Nicole’s purchase requisition is
complete and that the correct vendors have been selected for all the line items.
Then Nicole’s manager Julia has to verify that all of the charges on any of the
purchase requests in the purchase requisition are being charged to the correct
budgets. Finally, the Chief Financial Officer Sara has to approve of the
expenditures that Contoso will incur due to her signature authority.
Once Sara has
approved the purchase requisition, the workflow has completed its last step. At
this point in time, the entire purchase requisition will be moved to the Approved status. If configured, the system sends a
notification to Nicole that her purchase requests were approved and that
purchase orders will be generated for them.
Line-item purchase requisition review
Use line-item workflow if different line items warrant a
different review process, e.g. because they need to be routed to a shared
service center that is specialized on the requested procurement category, or
because they are requested in a legal entity that has different statutory
requirements for the review process. It is important to note that even if you
use line-item workflow, the purchase requisition must be submitted as a whole.
If line-item workflow is configured, individual line-item workflows will be
instantiated for all lines after the purchase requisition as a whole has been
submitted. It is not possible to submit only a subset of the line items.
A common scenario where line-item purchase requisition
review makes sense is if different lines on a purchase requisition are for
different requesters, and the requester’s manager should approve all purchase
requests by his or her employees.
You must use the workflow types Purchase requisition
review and Purchase requisition line review to define line-item
workflows. You always must define a document-level workflow that invokes the
line-item workflow. The Purchase requisition line review workflow type
has been implemented to wait for all line-item workflows to complete before the
document workflow can proceed. As a consequence, even though the line-item
workflows occur in parallel and proceed at their own pace, the entire purchase
requisition workflow can only complete once all line-item workflows have been
completed.
Example: Line-item review design-time experience
Contoso’s business requirements have evolved over time and
the company now wants to be able to route different line items individually to
different reviewers. Ken, Contoso’s business analyst, will create new workflows
that reflect the changed business requirements.
First Ken creates one line-item workflow of type Purchase
requisition line review. The process of authoring this line-item workflow
is very similar to the example provided above for document-level review. Ken adds
one task and two approvals and assigns each of the elements to the correct
audience. He configures Subjects and Instructions and Notifications as needed.
Ken saves and activates the line-item workflow and marks it as Default.
Next, Ken authors the document level workflow that invokes
the line-item workflow. Ken creates a workflow of type Purchase requisition
review. The only element that he adds to the workflow is the line-item
element. Ken configures the line-item element to invoke the line-item workflow
that he just authored. Ken configures submission instructions for the employee
to inform him or her prior to submission about required documentation and
applicable policies. Ken saves and activates the document level workflow and
marks the workflow as Default.
The following picture shows
an example of what the workflow design for the review process could look like.
Figure 6 Example of
a line-item purchase requisition review workflow
Example: Line-item review run-time experience
As in the preceding example
for document-level review, when Nicole submits a purchase requisition for
review, a workflow is instantiated and routed to different reviewers based on
the workflow that Ken defined.
Figure 7 Run-time
example of the line-item review workflow
This time, however,
each line gets routed to the reviewer applicable to just the line item. Since
the purchase requisition in our example contains two requests for different
requesters with different managers, and with line items for procurement
categories and charges for different departments, a different set of reviewers
gets assigned to each line item. Each reviewer will be able to see the entire
purchase requisition with all lines, but they will only be able to take action
on the lines that are assigned to them. Reviewers can take the workflow action
either from the unified work list in their Role Center, or by opening the purchase requisition
details form in the Windows client or on Enterprise Portal and selecting the
line they want to take action on.
When all of the
reviewers are done with their reviews and have completed or approved the
respective line items, the purchase requisition will transition into the
Approved status.
Note: when using line-item workflow, a separate workflow is always instantiated
for each line, even if multiple lines are sent to the same reviewer. If, for
example, all line items were requested for the same worker, the worker’s
manager would receive separate approval requests for each line item.
Mixed document and line-level purchase requisition
review
It is a common misperception that a workflow can only occur
either at the document level or at the line-item level. A document workflow can
contain as many line-item workflow elements as necessary, and those can invoke
different line-item workflows. This enables you to branch into line-item
workflows where it is necessary but keep the workflow at the document level
where it is appropriate. We call this kind of workflow a stage-gate process.
You must use the workflow types Purchase requisition
review and Purchase requisition line review to define mixed document-level
and line-item workflows. You always must define a document-level workflow that
invokes the line-item workflow.
Example: Stage-gate review design time experience
As in the preceding examples,
Ken defines the purchase requisition review process in Microsoft Dynamics AX.
He creates a new workflow of type Purchase requisition review and adds
three line-item workflow elements to it, and one task as well as one approval
that happen at the document level. He creates three separate line-item
workflows, each of which contains only one element. He then configures the
line-item elements in the document level workflow to point to the correct
line-item workflows.
Figure 8 Example of
a stage-gate purchase requisition review workflow
Example: Stage-gate review run-time experience
The picture below shows an
example of the run-time experience that could result from the preceding
workflow definition. Of course, the exact run-time experience always depends on
the data in the document. In the following example, we see one purchase
requisition with two line items going through the workflow. The requesters on
both lines report to the same manager, therefore the managerial review of both
line items is assigned to the same person, but as two individual work items
which can individually be approved or rejected. The procurement review is
assigned to different shared service centers due to the different nature of the
requested goods. The expenditure review is assigned on a line-item level to all
budget owners whose budget gets charged with the expenditure for the request.
The Document review as well as the Signature authority approval, however, is
performed for the entire purchase requisition; therefore line-item workflow is neither
required nor appropriate for those two workflow steps.
Figure 9 Runtime example
of a stage-gate purchase requisition review workflow
Sharing workflows across organizations
Purchase requisition workflows in Microsoft Dynamics AX
have their Association property set to Organization-wide. This
means that any purchase requisition review workflow that you define by default
applies to the entire organization. The benefit of this approach is that you
need to define your purchase requisition review process only once.
Note: This is
different from Microsoft Dynamics AX 2009, where workflows needed to be defined
in each Microsoft Dynamics AX company, even if they were identical.
In case you need different workflows for different parts
of the organization, there are two options you can deploy:
1.
Create separate workflows with activation
conditions. At run time, the system will select the workflow where the activation
condition is true.
2.
Create one workflow with conditions.
Since it is possible to request each purchase requisition
line item for a different buying legal entity and operating unit, it is best to
place the conditions on a line-item–level workflow, unless it is guaranteed
that all line items included in the purchase requisition are for the same
organization.
Note: Both
options above work for differentiating workflows by any criteria, not just
organization.
Example: Shared workflow across all organizations
Contoso applies the same purchase requisition review
process across the entire organization. Ken defines just one purchase
requisition review workflow, which is automatically marked as the Default. No
matter how many legal entities and operating units are defined within Microsoft
Dynamics AX to model Contoso’s business, every purchase requisition that is
submitted for review will follow this same workflow.
Note: Even
though all purchase requisitions will follow the same workflow, it is still
possible that the reviewers could differ. This is because the assignment can be
based on data of the purchase requisition. For example, assignment to the
requester’s manager will result in a different reviewer, based on who the
requester is.
Example: Different workflows for different legal
entities, using Conditional decision
When using the workflow
element Conditional decision, different workflow branches can be modeled
declaratively based on whether the condition is true or false.
Figure 10
Example of a Conditional decision to model workflows that differ by
organization
Example: Different workflows for different legal
entities, using activation conditions
When using activation
conditions, a separate workflow is created for each condition, and the
activation conditions are expressed in the workflows.
Figure 11 Example of activation conditions to model
workflows that differ by organization
Architecture of purchase requisition workflow in
Microsoft Dynamics AX
AOT workflow artifacts
The following table lists the most important purchase
requisition workflow-related artifacts in the AOT. It is not a comprehensive
listing of all artifacts.
|
Artifact type |
Artifact name |
Comments |
|
Workflow types |
|
|
|
|
PurchReqReview |
The workflow type used for document-level purchase
requisition workflows. |
|
|
PurchReqLineReview |
The workflow type used for line-item purchase requisition
workflows. |
|
Workflow approvals |
|
|
|
|
PurchReqReviewApproval |
The approval element used in the PurchReqReview workflow
type. |
|
|
PurchReqLineReviewApproval |
The approval element used in the PurchReqLineReview
workflow type. |
|
Workflow tasks |
|
|
|
|
PurchReqReviewTask |
The task element used in the PurchReqReview workflow type. |
|
|
PurchReqLineReviewTask |
The task element used in the PurchReqLineReview workflow
type. |
|
Classes |
|
|
|
|
PurchReqDocument |
The document used for the PurchReqReview workflow type. |
|
|
PurchReqLineDocument |
The document used for the PurchReqLineReview workflow type. |
|
|
PurchReqWFTypeEventHandler |
This class implements the completed event handler which
manages the transition to Approved status when the purchase requisition
workflow completes successfully. |
|
|
PurchReqWFStatusTransitionHelper |
This class governs the actions that need to be triggered
on certain state transitions. E.g. automatic purchase order generation, or
recording or pre-encumbrances, if configured. |
State model
Following is a picture of
the state model of the purchase requisition and the purchase requisition line.
Figure 12 Purchase requisition and purchase requisition line
state model
|
Term |
Definition |
|
Preparer |
The worker who creates the purchase requisition to
initiate a request for a product. |
|
Requester |
The worker who requests the product. The same person can
assume both the requester and preparer roles. |
|
Reviewer |
The worker(s) who
review the product requests. |
|
Purchase
requisition review |
The process of
reviewing the purchase requisition as a whole. |
|
Purchase
requisition line review |
The process of
reviewing a single line item – i.e. an individual purchase request – of a
purchase requisition. |
|
Document-level
workflow |
A workflow that acts on a business document. Workflows are always specific to a business
document and are created and maintained using a graphical workflow editor by
business users and IT staff. Workflows that are ready for use are made “active.”
This allows end users to submit records for workflow processing. |
|
Line-item workflow |
A workflow that acts on a line-item record for a business
document. For example, for a purchase requisition, a line-item workflow would
exist for each purchase requisition line item. Line-item workflow support is
built into the workflow system, providing explicit support for this pattern
in Microsoft Dynamics AX. |
Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar Microsoft software, automating and streamlining financial, customer relationship, and supply chain processes in a way that helps you drive business success.
This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Microsoft Dynamics, the Microsoft Dynamics Logo, and Windows are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners. |
Comments
Post a Comment