Order requests and demand processing in SAP S/4HANA

Purchase requisition and requirements requisition are both written requests typically submitted to the purchasing department of a company and include the need for goods or services.

The similarities between them are:

• Documenting the need for goods or services.
• Initiating the procurement process.

The differences between them are:

• A requirements requisition is a process step within procurement in companies. It is part of a unified system used by employees or automatic demand planning systems to document the need and initiate a purchase by purchasing.
• A purchase requisition, on the other hand, is a request to procurement to acquire a material or service in a specific quantity at a specific time. It does not constitute a purchase order but initiates a procurement process. Based on the purchase requisition, the procurement department initiates the necessary steps for the subsequent purchase.

There are direct and indirect purchase requisitions. In a direct purchase requisition, an employee manually creates the request in the system, while the system triggers the request automatically in the case of an indirect purchase requisition.

Purchase requisitions (BANF) and requirements processing in SAP are crucial aspects at the beginning of the procurement process. However, they can pose some challenges:

The purchase-to-pay process always starts with demand recognition and purchase requisition. If everything is not optimized from the beginning, it can lead to production issues due to missing or incorrect materials.

There can be significant differences between conventional and automated processes in demand determination and procurement requests. Employees need to clarify if there are quotes available for this item, which supplier(s) they can order the items from, and who is authorized and in the position to order this item.

Purchase requisitions above a certain amount do not go directly to purchasing but need approval from management first. This can slow down the process and cause delays.

These challenges can be overcome through process automation and the use of the right tools, such as MyCart.

The purchase position consists of header data, an overview of the positions (“position overview”), and one or more positions. Each position is assigned to one of the following procurement types:

• Normal
• Subcontracting
• Consignment
• Transfer
• Service

The position includes, among other things, the quantity, unit, and delivery date of the material to be delivered or the quantity and unit of the service to be provided. For positions awarded for subcontracting, the material components to be provided can be specified for each delivery date. The position of the service procurement type can contain a performance specification or alternatively limits. The performance specification can be divided into multiple levels of structure. The performance lines determine the ordered quantity, unit, and date. For performance positions that cannot be specified precisely, value limits are specified instead of performance lines. If services are requested from contracts, the value limit may refer to the specific contract. The costs incurred can be distributed through cost accounting to various controlling objects such as cost centers and PSP elements. A purchase requisition can be processed through purchase orders or framework agreements. It is an internal document that has no use outside the company.

Header data, data from the position overview, and details of the positions can be maintained on a central screen. The three areas of the screen can be expanded and collapsed, and their display size can be adjusted. This eliminates the need to “jump” between different screens and edit an entry screen. Within the same screen, you can switch between “Create”, “Change”, and “Display” if appropriate permissions are granted.

For requirements processing, the following apps are available, among others: