Edit

Share via

Raise purchase requisitions overview

Applies to: Dynamics 365 Commerce, Dynamics 365 Field Service, Dynamics 365 Finance, Dynamics 365 Project Operations, Dynamics 365 Supply Chain Management

This article describes the importance of purchase requisitions as a crucial internal document in supporting your organization's purchasing needs, and explains how Dynamics 365 products can streamline their creation.

Many organizations use purchase requisitions as a formal request made by an employee or department to acquire goods or services. It serves as the initial step in the procurement process, outlining the need for certain items or services. The benefits of using purchase requisitions are:

  • Control and oversight: Purchase requisitions help in controlling and monitoring the procurement process by ensuring that all purchases are authorized and align with the organization's budget and objectives.
  • Budget management: They assist in managing budgets more effectively by providing visibility into planned purchases before they're made.
  • Streamlining procurement: Purchase requisitions streamline the procurement process by centralizing requests and standardizing documentation, leading to greater efficiency and consistency in the procurement creation process.
  • Compliance and audit: They contribute to ensuring compliance with internal policies and external regulations by documenting the approval process and providing a paper trail for audits.

Purchase requisitions aren't mandatory for every organization, but they can be useful when you need more control and visibility over the purchasing process. If you want to include purchase requisitions in your scope, plan to address them before purchase orders, as they affect the downstream processes of creating and approving orders. You can also add purchase requisitions later in your project, but this may require some adjustments in your existing purchasing workflows and policies.

A poorly-defined business process for purchase requisitions can lead to inefficiencies, errors, and delays in the purchasing cycle, as well as increased risk of fraud and non-compliance. While a well-defined process can streamline the approval workflow, improve the accuracy and transparency of the purchasing data, and enhance the collaboration and communication between the purchasing and requesting departments.

Stakeholders

Many people across the organization should contribute to the raise purchase requisitions business process. The following list provides examples of such stakeholders:

  • Procurement stakeholders: Roles such as Buyer, Director of Procurement, Purchasing agent, Purchasing manager and various line managers are integral part of providing insight on purchase process within the organization. Frontline supervisors are critical in the review and approval of purchase requisition.
  • Management: Roles such as finance managers, CEOs, COOs, and various line managers are for approvals of large purchase requisitions and make decisions on spending and approval authority of organizational personnel.
  • Project managers: In the context of Dynamics 365 Project Operations and service-based organizations, project managers play key roles by overseeing the purchase requisition process related to their specific project. They can be crucial in the review and approval of purchase requisitions.
  • Compliance officers and internal auditors: Compliance officers are responsible for ensuring that the organization adheres to relevant regulations and standards. They use the system to monitor and report on compliance, track regulatory changes, and make necessary adjustments to policies and procedures to maintain legal and ethical compliance.
  • Employees: Employees request for item or services for your business and are responsible for ensuring the accuracy of their records.

Process flow

The following diagram illustrates the Raise purchase requisitions business process area.

Diagram of the 'create purchase requisitions' business process.

Before you begin, ensure to create an employee. The steps in the process flow diagram are grouped into swim lanes to indicate which role is responsible for each step.

If you're an employee, follow these steps:

  1. Start

  2. Manually, identify need of product or service.

  3. Manually, collect information regarding the requirement or services such as product ID or description of service and price.

  4. Create or update purchase requisition.

  5. Add new line and select legal entity.

  6. Select procurement category if the item isn't known.

  7. Enter quantity required.

  8. Select receiving operating unit.

  9. Known price

    1. If yes, then enter unit price if the purchase requisition line is for a category. If the purchase requisition line is for an item and a trade agreement exists, then the price is defaulted for the trade agreement.
    2. If no, proceed to step 10.

  10. Submit requisition.

If you're a purchasing agent, follow these steps:

  1. Navigate to purchase requisition assigned to me form.

  2. Request for quotation required.

    1. If yes, then initiate request for quotation (RFQ) process.
    2. If no, then review or enter unit price and unit of measure.

  3. Select final vendor and attach document (if applicable).

  4. Submit requisition.

If you're a manager or accounting manager, follow these steps:

  1. Approval required.

    1. If yes, then accounting manager accesses the purchase requisition assigned to me form.
    2. If no, then proceed to step 18.

  2. Approved

    1. If yes, then proceed to step 17.
    2. If no, then go to step 5 in the Employee swin lane.

  3. Purchase order process initiated.

  4. End

Purchase policy overview

A purchasing policy is a set of rules that govern the requisition process, helping procurement administrators align with the organization's strategic purchasing goals. To create a purchasing policy, you must define and configure policy rules along with start date and end date.

A policy must be linked to an organization before it can take effect. Purchasing policies are tied to the procurement internal control hierarchy purpose, thus they only apply to organizations within hierarchies with this designation. Additionally, you can choose organizations from legal entities list known as Companies in the policy framework.

Purchase requisition lines let users choose items from an assigned catalog. If an item or service isn't in the catalog, users can still select the category and manually enter the product name and details.

The purchase policy can be adjusted to match the organization's purchasing process. These rules govern procurement and requisition processes, including catalog and category access, vendor selection, and re-approval for purchase orders. They also define criteria for informal or formal RFQs and offer optional controls for requisition purposes and replenishment. Additionally, they outline policies for consolidating and generating purchase orders from approved requisitions.

Implement raise purchase requisitions

Purchase requisition is a global feature that allows users to create a request across all legal entities in the organization. This means that a user can specify that they want a product or service for Company A or Company B, for example. In contrast, purchase orders are always specific to the current company.

In Dynamics 365, you have the option to create a purchase requisition before creating a purchase order to take advantage of the benefits mentioned above. Alternatively, Dynamics 365 also allows you to directly create a purchase order without first creating a purchase requisition.

The following table shows the configurations available, and the sequence recommended for setting up the configurations from top to bottom. Use the links in the Process step column to learn more about the component. The Process stage column includes three values that are separated by semi colons (;). The first value indicates the project phase when a configuration or step should be completed. The second value indicates the type of configuration, and the third value indicates if the step is a configuration or an operational step. The Process modifiers column is used to further describe other attributes for each step. The Application: Navigation and Entity column uses abbreviations to indicate the user interface or application with the navigation path after the colon. First, we list the navigation to the relevant forms. Next comes the name of the entity for importing or exporting data in either the Dataverse (DV) or with Data Management Framework (DMF). We use the abbreviations to indicate the type of entity, followed by the name of the entity after the colon.

For more information about the abbreviations and explanations of the values used in this table, refer to Business processes, steps and how to find things.

Process step Process stage Process modifier Application: Navigation and Entity
Purchase requisition permission Initialize; Configuration; Base Early; Continuous; multiple recommended SCM: Procurement and sourcing > Setup > Policies > Purchase requisition permissions
DMF: N/A
Set up number sequences for purchasing Initialize; Configuration; Base Early; Gold; At least one; More than one recommended SCM: Procurement and sourcing > Setup > Procurement and sourcing parameters> number sequences> Purchase requisition voucher
DMF: N/A
Legal entity Initialize; Configuration; Base Early; Gold; At least one FIN: Organization administration > Organizations > Legal entities
DMF: Legalentities
Operating unit Initialize; Configuration; Base Early; Gold; At least one FIN: Organization administration > Organizations > Operating Units
DMF: OperatingUnit
Release product Initialize; Configuration; Base Gold; More than one recommended SCM: Product information management > Products > Released products
DMF: ReleaseProductsV2
Procurement category Design; Configuration; Optional Gold; More than one recommended SCM: Product information management > Setup
Categories and attributes > Category hierarchies
DMF: Productcategoryhierarchies
Vendor Initialize; Configuration; Base Early; Gold; At least one FIN: Accounts payable > Vendors > All vendors
DMF: VendorV2
Business Justification Design; Configuration; Optional Gold; Continuous SCM: Procurement and sourcing
Setup > Policies > Business justifications
DMF: PurchPurchaseRequisitionBusinessJustification
Unit of measure Initialize; Configuration; Base Early; Gold; At least one FIN: Organization administration
Setup > Units > Units
DMF: Units
Currency Initialize; Configuration; Base Early; Gold; At least one FIN: Cost accounting > Ledger setup > Currencies > Currency exchange rates
DMF: Exchangerates
Purchasing policy Initialize; Configuration; Base Early; Gold; At least one SCM: Procurement and sourcing
Setup > Policies > Purchasing policies
DMF: N/A
Employee Initialize; Configuration; Base Early; Gold; At least one FIN: Human resources > Workers > Employees
DMF: EmployeeV2
User Initialize; Configuration; Base Early; Gold; At least one FIN: System administration > Users > Users
DMF: N/A
Purchase requisition workflow Initialize; Configuration; Base Early; Gold; At least one SCM: Procurement and sourcing
Setup > Procurement and sourcing > workflows
DMF: N/A
Item sales tax group Initialize; Fundamental; Configuration Gold; Continuous FIN: Tax > Indirect taxes > Sales tax > Item sales tax groups
DMF: Item sales tax group
Sales tax group Initialize; Fundamental; Configuration Gold; Continuous FIN: Tax > Indirect taxes > Sales tax > Sales tax groups
DMF: Sales tax groups
Inventory dimensions Initialize; Fundamental; Configuration Early; Gold; At least one SCM: Inventory management
Setup > Inventory breakdown
DMF: Sites V2, Warehouses, Warehouse locations
Financial dimensions Initialize; Fundamental; Configuration Early; Gold; At least one FIN: General ledger > Chart of accounts > Dimensions > Financial dimensions
DMF: Financial dimensions

Requisition purposes

Requisition purposes make the process of fulfilling requisition demands more flexible. When you create a requisition, you can assign one of two purposes to it:

  • Consumption
  • Replenishment

In the procurement policies, you can control the requisition purposes that're available when a requisition is created for your organization.

  • Purpose of consumption: A requisition that has a purpose of consumption represents demand for items or services that are used internally by your organization. The demand is created by a purchase order. If purchasing policy is set up with automatically creation of purchase order, then order is created and is in approved state.
  • Purpose of replenishment: A requisition that has the purpose of replenishment represents demand to replenish inventory. For example, you create a requisition to replenish items so that they can be sold at a specific location at a specific time. The demand for such requisition can result in purchase order, transfer order, or production order.

Next steps

If you would like to implement Dynamics 365 solutions to assist with the Raise purchase requisitions business process, you can use the following resources and steps to learn more. (Links are added when the articles are ready.)

  1. Define procurement and sourcing strategies

  2. Manage supplier relationships

  3. Source and contract goods and services

  4. Procure goods and services

    1. Raise purchase requisitions overview (the article that you're currently reading)
    2. Issue purchase order
    3. Manage open purchases
    4. Issue blanket purchase orders
    5. Return goods to suppliers
    6. Consolidate requisitions
    7. Analyze supply purchase plan

  5. Manage accounts payable

  6. Analyze procurement and sourcing

The following patterns can help your implementation of the raise purchase requisitions business process. (Links are added when the articles are ready.)

  • Add a category line to a purchase requisition
  • Add an item to purchase requisition
  • Add products using punch-out e-procurement
  • Import purchase requisitions from a third-party system

You can use the following resources to learn more about the Raise purchase requisitions business process in Dynamics 365:

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal author:

  • Amir Hemani | Consulting Manager / Solution Architect

Other contributor: