SAP PP What is Planned Independent Requirement (PIR)

A PIR is useful to perform Demand Management functions. A PIR consists one planned quantity and date or a number of planned independent requirements schedule lines i.e., a planned quantity split over time as per dates.

Integration –

A planned independent requirements is created as follows –

  • By entering quantities and dates manually.
  • By copying the material forecast automatically.
  • By copying the results of sales and operations planning automatically.
  • By copying the original plan automatically.
  • By copying the planned independent requirements of another material or another planned independent requirements version of the same material automatically.
  • It is required to maintain the fiscal year variant in the Forecast requirements section of the material master record if either –
    • Copy the planned results from Sales and Operations Planning and use a fiscal year variant as the planning period.
    • Maintain planned independent requirements with reference to a fiscal year variant.

Planned Independent Requirements (PIR) –

The PIRs are planned production or sales quantities based on some sort of forecast procedure such as material forecast or S and OP procedure. These numbers used in MRP for calculating the procurement or production quantities to a material.

(Planned) dependent requirements –

Planned dependent requirements or Dependent requirements is a demand depended on another material.

Example –

A company plan to sell 50 bicycles in the month of January 2022 based on sales in the same month of 2021. These 50 bicycles is a Planned Independent Requirement for 01/2022.

Since every bicycle is produced using two pedals the 50 bicycles planned to sell in January 2022 results in 100 pedals needed to procure. These 100 pedals is a planned dependent requirement for 01/2022.

Based on these numbers, MRP can calculate including current stock levels how much bicycles and pedals are actually need to produce.

Stock/Requirements List –

In a stock/requirements list, it displays the up to date stock and requirements situation. The difference between MRP list and the stock/requirements list states that whenever the stock/requirements list is called up then the system selects the different MRP elements and displays the up to date situation.

In that way it always allows to see the current availability situation of the material in the stock/requirements list. The changes made after the planning date are displayed directly. So the list is therefore said dynamic.

Stock/requirements lists are not saved in a fixed state in the system but are subject to change and only exist in the working memory.

Comparison –

  • The screen layout of both Stock/requirements lists and MRP list is basically the same.
  • The system will automatically runs the rescheduling check directly when the lists are created and puts its forward rescheduling proposals.
  • The exception messages displayed in the list is roughly same for both lists.
  • In fact the difference is because of the nature of list, no exception messages will occur to a newly planned MRP elements in the stock/requirements list.
  • After planning run, the both lists possess the same information.
  • Whenever a change related to MRP is made, the system will updates the information in the stock/requirements list.
  • Since the stock/requirements lists are tend to change, they should not set with a processing indicator.

Structure –

  • Every MRP list was divided into a header and items.
  • The Material data like material number, plant, and MRP parameters are all recorded in the MRP list header.
  • The items consist the information on the individual MRP elements i.e., planned orders, purchase orders, reservations, sales orders etc.
  • These will be grouped by the MRP data into individual planning segments.
  • The beginning of every new planning segment will be highlighted.
  • The system will carry out the net requirements calculation for every segment separately.

Planning Segments –

The below segments are individually displayed and planned –

  • Net segment –
    It consists part of the list for which the net requirements calculation in planning was carried out on plant level.
  • Gross segment –
    It groups together with the gross requirements and the corresponding procedure proposals for gross requirements planning.
  • Storage location segment –
    For every separately planned storage location or for every location, which is not included in MRP.
    • Individual customer segment
    • Individual project segment
    • Segment for planning without final assembly –
      It displays the requirements planned without the final assembly. Which means that their procedure is triggered by incoming sales orders and non-convertible planned sales orders with the order type VP.
    • Segment for direct production planning
    • Segment for direct procurement planning
    • Direct production segment
    • Direct procurement segment
    • Segment for the provision of material for subcontracting.

Technical Data –

The technical data of PIR is –

Entity Type Business Object
Software Component Version ESM SCM 7.02
Technical Name Planned Independent Requirement
Object Category Business Process Object

Business Context and Use –

  • A PIR business object allows the processing of planned independent requirements and PIR items.
  • These are used to support planning for additional product demand.
  • This demand is not a customer or sales order driven instead it is planned in response to business and market factors.
  • It may contain a quantity of product from a particular supplying location and planned for a specific date.
  • Alternatively, it may contain multiple PIR items that effectively outlining a schedule of product quantities planned for consumption over multiple dates.
  • After a PIR was created, its quantities are consumed by different customer requirements like sales orders or purchase requisitions.
  • The type of order consumed by a PIR is determined during customization.
  • The PIRs are subject to planning versions and models.