Request

The initial purchasing process begins with a request or service order.

---

The request can originate from an ERP system or can be created within the ME. Currently, we have the following scenarios:

• Request created in the client's ERP and sent to the ME through the following endpoints:
  • POST Create a request.
  • PUT Update a request based on the requestId.
• Request created in the ME and sent to the client's ERP: in this case, the Buyer performs queries through the GET endpoints available in the REQUEST API, in addition to receiving notifications via webhook when a request is approved or its status is changed (in this case, they also perform GET on one of the APIs to query).

Creating a Request

The purchasing request can be created by users who have the integration TAG registered on the portal. This integration TAG must be provided in the integrationTag field when creating a request through the POST endpoint Creates a request.

📘 Note

Profile configuration, done through the portal, defines who can create a purchasing request. By default, the request can be created by the requester profile.

The request is the first step in the purchasing process flow:

When it comes to a catalog request, also called contract item consumption, there is no Quotation in the flow:

When there is a contract associated with the item the buyer is requesting, the Pre-order can be created automatically (or by the buyer themselves) without going through the negotiation (quotation) process:

• The field that establishes this relationship is isCreatedPreOrderAutomatically in the CONTRACTS API.

When there is no contract associated with the item, the buyer needs to open a quotation to receive responses from suppliers and then issue the Pre-order/ Order.

Learn more about Pre-order.

Particularities of the Request

Types of Requests

Each request can be of a specific type (field category in the REQUESTS API). Examples: contract, catalog, normal, rental, special, and urgent.

Request Status

The request can have the following statuses:

• 0 = Submitted (The request enters with this status in the ERP)
• 1 = Approved
• 3 = Canceled
• 123 = ERP INCONSISTENCY
• 124 = WAITING FOR ERP INTEGRATION
• 125 = WAITING FOR ERP APPROVAL

Items

The request is created by selecting the items that will make up that request, i.e., the products and/or services. It can be thought of as a shopping cart on a portal.

In the list of request items, all details of that product are provided, such as: quantity, estimated price, expected date, unit of measure, type of accounting classification, among other details.

To consult the list of items in a request, use the endpoint: GET Get a list of request items.

This query returns the status code (field status) of each request item:

• null = In pending purchase
• 0 = In pending purchase
• 19 = Awaiting ERP approval
• 20 = In order at the ERP
• 3 = In quotation
• 5 = In Pre-Order
• 1 = In Order
• 6 = Cancelled

Cost Objects

During the creation of a request, we can specify one or more cost objects and perform cost distribution for the selected cost objects, dividing by quantity, percentage, or value.

Example: Item with quantity = 10
Distribution:

• Cost Center 3030 quantity = 5
• Cost Center 4040 quantity = 3
• Cost Center 2020 quantity = 2

To consult the cost objects of a specific item in a request, use the endpoint: Get request item cost object.

To consult the list of all cost objects for all items in a specific request, use the endpoint: Get the entire list of cost objects.

Approvers

After creating a request, it goes through the approval flow in the client's system. The approval of a request is usually done by the superior of the requester and serves as a first approval step (another approval occurs in the purchase order) and is used to verify the need for that item.

Occasionally, the approval may occur only in the ME and be sent to the ERP already approved just to reflect the document. In these cases, the client must return to the ME one of the following statuses:

• 1 = Approved: if the request was created successfully and/or is approved.
• 125 = WAITING FOR ERP APPROVAL: if the request was created successfully and is pending approval.
• 123 = ERP INCONSISTENCY: if the request was not created, along with the reason for the inconsistency in the note field.

To consult the list of approvers of a request, use the endpoint: GET Get a list of request approvers.

Approved Request Pending Purchase

After the request is approved, it remains pending for purchase until the procurement department makes the pre-order/ purchase order.

The Purchase Pending is the list of items within the request that the buyer will analyze and select the items to be quoted. Each item in the request can follow a different negotiation process.

Product Portfolio Configuration

Each buyer can have their product portfolio, making specific requests reach a particular purchasing area/group. Thus, only a group of buyers views that request.

The steps for configuring the product portfolio are:

1. A product is related to a product group by registering the product group (clientGroupId) and product (clientReferenceProductId) fields when creating products and requests:
   1. POST Create a product
   2. POST Create a request
      During integration, all values are sent. Thus, if the product or product group does not exist, they are created at this moment.
2. The product group along with the user is associated with a purchasing permission. These permissions can be set through the endpoint: POST Create a product within the permissions node, as shown in the following image:

Thus, the buyers' pending items (i.e., the items in the request) are separated based on the product group. They can also use this product group field to filter what is relevant to them.