Microsoft Dynamics AX 2012
®
Defining business process
workflows for purchase
requisitions
Concept Paper
This paper describes how to use workflow to model a company’s
business process for purchase requisition review in Microsoft
Dynamics AX 2012.
June 2011
CCAX2012IC0070
Table of Contents
Overview of purchase requisition review workflow..................................... 3
Purchase requisition workflow in Microsoft Dynamics AX ........................... 3
Scenarios of purchase requisition review processes with Microsoft
Dynamics AX ............................................................................................... 5
Importing predefined purchase requisition workflows ................................................................ 5
Example: Leverage Microsoft Dynamics AX sample workflows ................................................. 5
Example: Reuse proprietary workflows ................................................................................. 6
Defining a purchase requisition workflow from scratch ............................................................... 6
Example: Demonstrate workflow authoring ........................................................................... 6
Automatic purchase requisition approval .................................................................................. 6
Example: Bypass purchase requisition review during initial implementation phase ..................... 7
Example: Bypass purchase requisition review based on spending limits .................................... 8
Document-level purchase requisition review ............................................................................. 8
Example: Document-level review design-time experience ....................................................... 8
Example: Document-level review run-time experience .......................................................... 10
Line-item purchase requisition review .....................................................................................10
Example: Line-item review design-time experience ............................................................... 11
Example: Line-item review run-time experience ................................................................... 13
Mixed document and line-level purchase requisition review .......................................................14
Example: Stage-gate review design time experience ............................................................. 15
Example: Stage-gate review run-time experience ................................................................. 16
Sharing workflows across organizations ..................................................................................16
Example: Shared workflow across all organizations ............................................................... 17
Example: Different workflows for different legal entities, using Conditional decision .................. 18
Example: Different workflows for different legal entities, using activation conditions ................. 19
Architecture of purchase requisition workflow in Microsoft Dynamics AX . 19
AOT workflow artifacts ..........................................................................................................19
State model ........................................................................................................................21
Glossary of terms ...................................................................................... 22
2
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
3
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS

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.
4
DEFINING BUSINESS PROCESS WORKFLOWS FOR 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.
5
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
6
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
7
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
8
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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
9
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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 lineitem level. Please see the section Line-item purchase requisition review for more details about lineitem 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
10
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
11
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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
12
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
13
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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 documentlevel workflow that invokes the line-item workflow.
14
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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 lineitem 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
15
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
16
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
17
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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
18
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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
PurchReqReview
The workflow type used for
document-level purchase requisition
workflows.
PurchReqLineReview
The workflow type used for lineitem purchase requisition workflows.
PurchReqReviewApproval
The approval element used in the
PurchReqReview workflow type.
PurchReqLineReviewApproval
The approval element used in the
PurchReqLineReview workflow type.
Workflow types
Workflow approvals
19
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
Artifact type
Artifact name
Comments
PurchReqReviewTask
The task element used in the
PurchReqReview workflow type.
PurchReqLineReviewTask
The task element used in the
PurchReqLineReview workflow type.
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.
Workflow tasks
Classes
20
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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
21
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
Glossary of terms
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.
22
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS
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.
U.S. and Canada Toll Free 1-888-477-7989
Worldwide +1-701-281-6500
www.microsoft.com/dynamics
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.
23
DEFINING BUSINESS PROCESS WORKFLOWS FOR PURCHASE REQUISITIONS