SAP IBP for Response and Supply

A new OData based API to extract pegging information from OBP. The API is published in API hub and can be utilized in the same fashion as Stock and Purchasing APIs.

Motivation

The analytical outbound, also called 'Data Integration: Extraction of Order-Based Planning Results' in Application jobs, enables customers to analyze planning results, along with pegging information, outside of SAP Integrated Business Planning. This feature is based on SDI technology and serves the purpose of downloading the data into files.

This comes with the following drawbacks:

1. Extracts multiple files with data from the entire planning version.
2. Bound to SDI
3. No filter capability
4. The data is not very user friendly in terms of readability. There is a need to switch between files to get full picture of the pegging. Missing Order type or external element ID information.
5. It did not extract unpegged supply

Keeping in mind the drawbacks of Analytical outbound and also growing Interest from customer, it is decided to have an extraction service API to fetch Detailed pegging information from OBP.

The purpose of this extractor is to provide Odata based Detailed pegging extraction service with improvements in terms of:

1. Filter capabilties
   • Snapshot creation on filters : Primary demant type, Required time Interval, Split Unpegged Supply, Pegging level,
   • Filtering on Reading is possible on any output column
2. Visibility of Unpegged supply
3. Order type information differentiating Purchasing, subcontracting, production, demand elements etc
4. Support with RTI

• Pegging is stored in 3 tables
• Direct pegging (supply outputs to demand inputs)
• Fine pegging
  • Supply outputs to primary demands
  • Demand order inputs to primary demands
• The algorithm combines this information: which share of a supply contributes via which direct demand to finally which primary demand

Unpegged Supply

Supply orders whose output is (at least partially) not fine-pegged to any primary demand

For every supply order where the output quantity doesn't match the total of fine pegged quantities, we create an entry in our pegging list with

• The quantity difference
• pegging level 0
• Initial primary demand order

We can even split such lines to distinguish between supply elements that are not pegged at all and supply elements that are pegged to demands which are not fine-pegged to any primary demand (see next slide)

This is controlled via a flag '_IBPDetPggngUnpSplIsSplFltr' which means Split Unpegged supply. If this is set to true,

Document IDs and Types

To increase the readability we will add the internal and external document ID and the document item type (as already used in purchasing and production APIs) to the output.

Master data

To enable efficient filtering, there is the ProductID and LocationID added to the output (i.e. the readable ones, not the internal IDs)

Units of measure

The previous solution returned/stored pegged supply quantity and affected primary demand quantity without UoMs. The implicit contract was to refer to the respective base units of measure.

In an OData service every quantity needs an explicit reference to a unit of measure in the same entity. Hence, there is include

• SupplyQuantityUnitOfMeasure
• PrimaryDemandQuantityUnitOfMeasure

In order to have a 'self-contained' list you would need not only the external OrderIDs, but also at least order planned date and order total quantity, preferably also the location product, CBP attributes, …

Live data access of mass data has performance and consistency issues.

Snapshot : Read mass data from a snapshot persistency rather than calculating on-the-fly.

A customer can e.g. trigger the snapshot creation directly after a planning run, when the pegging is most up to date.

We extract pegging network into the snapshot, with filtering on planning area and planning version. Creating snapshots on scenario is not (yet) supported.

Pros:

1. Better performance
2. In long term, consistent and harmonized access to data from OBP

Cons:

1. In short term, chance of outdated data in snapshot
2. Two-level extraction required when filtering for MRP controller, Subnetwork, …

1. _IBPDetPggngPrimDmndDTpFilter -
   • Operator : 'EQ'
   • Possible Values : "SD_ITM" , "DEL_ITM", "FCST"
2. _IBPDetPggngUnpSplIsSplFltr -
   • Operator : 'EQ'
   • Possible Values : 'True', 'False'
3. _IBPDetPggngPeggingLvlFltr
   • Operator : 'BT'
   • Example values : "PeggingLevelValueFrom": 1, "PeggingLevelValueTo": 2
4. _IBPDetPggngPrimDmndRTFltr
   • "Operator": "BT",
   • Example values : "PrimaryDemandReqdTimeValueFrom": "2021-01-01T00:01:01Z", "PrimaryDemandReqdTimeValueTo": "2025-01-01T00:01:01Z"

What's new

OData API: Detailed Pegging Extraction:

SAP Help documentation

OData API: Detailed Pegging Extraction | SAP Help Portal:

Extracting Detailed Pegging Data for External Systems | SAP Help Portal:

It is now possible to restrict users to specific planning area versions in order-based planning for reading and writing order and stock data.

New restriction types

• Transactional Order and Stock Data Read
• Transactional Order and Stock Data Write

Affected areas

• all Fiori apps dealing with order or stock data
• all application jobs dealing with order or stock data

Not affected

Order key figures calculated from order or stock data

Migration 2411 to 2502

Users who have application jobs or Fiori apps in their role which deal with order or stock data, will automatically have full access.

What's New: New Restriction Types for Transactional Order and Stock Data:

Product Allocations provide the mechanism to restrict the confirmation of orders with certain order characteristics like e.g. dedicated customers or regions. This could prevent supply shortage situations caused by a single high volume order to consume significant stocks and thus leaving the other customers orders, down the line, unconfirmed.

Step 1: Allocations Planning

With the OBP Supply Planning run you can create a feasible supply plan based on forecasts and constraints in a single step. As part of this planning run you create allocation quantities (= constrained forecast), which are covered by supply.

Step 2: Allocation Reduction/Consumption

You use the OBP Supply Planning Run with order confirmation to reduce allocation qty and constrain the confirmation of sales orders with certain order characteristics like e.g. dedicated customers or regions.

Alternatively: Allocation reduction/consumption can also be executed as part of aATP in S/4HANA

Use the product allocations planning as a bridge between the planning and order fulfillment side processes. Ensure the right amount of supply is being allocated to the right channel partners.

Plan product allocations (overall supply will be constrained in relation to the overall demand)

Maintain/adjust product allocations

Re-adjust product allocations (monitor customer consumption levels and react to deviations against forecasts)

Confirm sales orders accocrding to allocated supply

• Execute product availability/product allocation check (S/4 HANA AATP)
• Consider product allocations as constraint for response planning (IBP Response & Supply)

Allocation reduction step:​

Reduction of key figure "Allocation Final" with key figure "Processed Sales Qty"

• Processed Sales Qty = Original Sales Order qty - Open Sales Order Qty (MNG03-MNG01)

Date: Sales Order date

Allocation consumption step:

Consumption of "Allocation Final Reduced" by sales order items (done by planning run)

Optional: As the allocation reduction is done by key figure calculation you are able to influence the input for the allocation reduction.

Example: Use simplified key figure consumption IBP_CONSUMPTION to cover cross period consumption requirements for Allocation Final Reduction.

Configuration of the IBP_CONSUMPTION Function:

Key Figure "Allocation Remaining" needs to be adjusted.

Use global configuration to switch to the new key figure based Allocation Reduction.

Create exception list for planning areas to exclude from key figure based Allocation Reduction

Attribute-based planning is essential in the supply chain for several reasons:

1. Product Diversity: Many supply chains deal with a wide range of products with varying attributes such as size, weight, shelf life, and demand patterns. Attribute-based planning allows for customized strategies to address the specific requirements of different products.
2. Customer Expectations: Different products may have unique customer requirements. Attribute-based planning helps in aligning supply chain processes with customer expectations, enhancing customer satisfaction by delivering products in line with their specifications.
3. Cost Reduction: Through better resource allocation, reduced waste, and improved efficiency, attribute-based planning contributes to overall cost reduction in the supply chain.
4. Compliance Adherence: Companies have to adhere to regulatory norms imposed by different agencies and countries while doing business there. Rapidly changing geo-political situation also forcing companies to adhere to the restrictions (embargo).
5. Risk Mitigation: Considering attributes helps in identifying potential risks associated with specific products or suppliers. This allows organizations to implement risk mitigation strategies tailored to the attributes of each product or supplier.
6. Resource Optimization: By considering attributes like transportation modes, storage conditions, and supplier capabilities, organizations can optimize the allocation of resources, ensuring that each product is handled in the most cost-effective and efficient way.

In summary, attribute-based planning is required to meet the challenges posed by product diversity, optimize resources, satisfy customer expectations, enhance flexibility, reduce costs, and mitigate risks in the complex landscape of supply chain management.

Characteristics-Based Planning (CBP) in SAP IBP empowers planners to balance demand and supply and harmonize their supply chain processes across the network, based on attributes of products, demands and supplies.

Physical Product attributes as well as Logical Attributes to proactively steer supplies

• Uses the SAP7F Planning Area, Order Based only
• Pre-requisite is HANA Cloud, some regional restrictions and customers will need to ask for it specifically
• Characteristics considered in supply planning using the finite heuristic, not optimization
• Focus is for MTS, not MTO or CTO
• Such characteristics can be product-related, like size, color, or quality, or any other that would support you in steering supply decisions: related to special events, packaging, labels, or sustainability, for example.
• With the CBP data model, you can avoid duplicating your master data. Instead of creating product variants, you can model CBP attributes
• Real-time integration in characteristics-based planning supports SAP S/4HANA Segmentation, but not a pre-requisite
• Supports Batch Class (023) for batch level integration
• During RTI, a number of BAdIs can be called, and you can make use of the already existing BAdIs to adjust classification data of orders

• Attributes are characteristics that are used to describe demand and supply at more detailed levels. example - color, size, country of origin, etc.
• Attributes can be relevant for demand elements, supply elements and/or sources of supplies.
• Data type can be INTEGER or NVARCHAR
• For CBP attributes of data type NVARCHAR, specify a default value. The default value must be of a minimum length of 1 and no longer than the length specified for the attribute. The default value can't be changed after activation

• Attribute Sets are a logical grouping of attributes. Attribute sets are assigned to one or more products.
• Attributes and values can be also imported from S/4HANA characteristics, segmentations

An attribute set is assigned to one or more products :

• Option 1: RTI supported via BAdI.
• Option 2: integrate values using Data Integration
• Option 3: maintain manually in IBP, e.g. in Manage Master Data app

Life cycle of characteristics values

• Characteristics values can be introduced at any point in time, simply by adding new records to the master data type
• Existing values can't be changed (since keys)

More information regarding CBP Attribute can be found here: SAP Help

To serve the purpose of Source of Supply selection based on Attributes, Production Data Structure (PDS) and Transportation Lane (Tlanes) Master Data type were also extended with the following fields:

PDS:

Source Group ID: identifies groups of sources of supply in characteristics-based planning (CBP). Groupings can be based on any principle you define for your model.

Transportation Lanes:

• Source Group ID: identifies groups of sources of supply in characteristics-based planning (CBP). Groupings can be based on any principle you define for your model. Add the source group ID to your procument lane master data type if you want to run CBP for distribution scenarios. (Purchasing)
• Attribute Value Combination ID : used in the transportation lane master data type refer to exactly one combination of product characteristics values used to plan stock transfers in line with custom business requirements. (Stock Transfer)

more information about setting up Source Group ID can be found here:

Footnotes: are based on S4Jane segmentation

• Prioritization of forecast based on attributes, SFC attributes .
• Forecasting handover from time series to OBP ( T shirt level- size level example)
• The usual OBP consumption wont work

• Characteristics-Based Planning Profiles (CBP Profiles) helps in accurately planning demand and supply by considering product characteristics like size, quality, or color. The profiles define how these attributes are matched for demand fulfillment.
• Each CBP profile contains a set of rules for attribute sets, ensuring that demands with specific attribute-value combinations are fulfilled with matching supply
• Once a profile is saved and activated, it can be selected for planning runs in the Application Jobs app.
• Fore more details regarding CBP profile overview can be found here:

• Similar to demand prioritization in Planning Run Profiles the relevant demands to be matched to supply are first sorted into segments. 
• A segment defines which supply matching conditions are applied to the demands within a segment.
• Demands are sorted into a segment based on a Demand Condition. Only for Demands that fulfill the condition the underlying Supply Matching Condition is evaluated.
• Demands can be sorted into one segment only. 
• Demands that are not part of any segment are sorted into the catch-all segment where a default supply matching condition is defined. The catch-all segment does not have a demand selection condition. 
• The catch-all segment is configured with a default supply matching condition (1:1 Matching). attributes that are supply and demand attributes are to be identical
• attributes that are supply attributes only, are interpreted by default as 1:ANY
• Each segment has a segment order number and a description.

For more details regarding rule segment can be found here

• When a demand segment has been introduced for an attribute set, the condition for a demand to be sorted into that segment has to be defined.
• The Attribute Set for which the demand segment shall be defined needs to have at least one demand attribute
• Demand Segment Conditions can be defined based on Demand Attributes only
• Demand Segment Conditions are defined by logically combined condition statements
  • <condition1> AND <condition2>
  • <condition1> OR <condition2> 
• It shall be possible to define nested conditions / subconditions
  • <condition1> OR ( <condition2> AND <condition3> )

• Supply Matching Conditions are established for each demand segment and are exclusively applicable to demands categorized within that segment.
• A Supply Matching Condition applies matching criteria to the attributes of available supply. To achieve a successful match, the supply's attribute value must correspond precisely to the value defined in the condition.
• For ease of maintenance, a default 1:1 matching condition is automatically assigned to each segment's Supply Matching Condition
• Only in cases where a non-1:1 matching condition is required should the default be removed or replaced with explicit matching conditions for the relevant attributes.

Comparison of demand attributes to be clarified by Zoltan

Some nuances to keep in mind while building the rules

• It matters whether a CBP attribute is Demand relevant and/or supply relevant and how it is used in the rules.
• The Rules framework is designed to work in similar way to the Planning run profile. Both are needed to run a Finite Heuristic Supply Planning run with CBP
• The starting point is always with a Segment - for example a Demand Region
• If you have "Supply only" attributes in the attribute set, and you have used it in the supply matching condition, then you must define in the supply creation rule the value for it to be written on the planned orders. For example, country of origin is a supply only attribute, and Demand Region EU can only take supply from VN, then in the Supply Creation Rule you must specify the value as VN.
• For demands that are added to a segment but not matched with any supply, 1:1 matching is applied by default.
• Any attribute that you do not specify in any segment, would be assigned to the catch all segment in supply creation and will always be considered last.

IBP Order-based Planning supports Characteristics Based Planning with finite heuristics.

When set up the planning run job, you have the option to specify a CBP Profile. The planning run operates in CBP mode only when a CBP Profile is specified.

• Projected Stock
• View Confirmations
• Analyse Supply Usage
• Orders
• View Stock Details
• Planners Workspace and Excel
• Gating Factors and Gating Orders

View Confirmations

In the Order Items table, you can view CBP attribute Set ID for the Product as well as Attribute values for the Demand.

Analyze Supply Usage

columns and filters for CBP attribute values of receipts and requirements are available. In addition, Batch Number and Lot Grouping ID are also visible.

Orders

By using the Orders app, you can filter orders for CBP attributes and values

View Stock Detail

In the CBP Attributes and Values column, you can view CBP attribute values related to the batches of integrated stock elements. You can also limit your search scope using the CBP Attributes/Values field.

Planner Workspace and Excel

Like other root attributes, CBP attributes can be used for filtering and drilling down

Gating Orders and Gating Factors

There are in total 3 types of Gating Factors which are related to CBP:

1. Projected Stock Shortage (Attributes): Occurs when demand can only be satisfied late due to a mismatch of attribute value combinations. The situation is such that the attribute value combination of the fixed supply does not match the required demand attribute value combination.

2. Supply Chain Model - No SoS with matching attributes: This gating factor occurs when there is no source of supply matches required attributes.

3. Supply Chain Model - Conflicting creation and matching rule. This issue arises when supply creation and matching conditions in the assigned CBP profile conflict, preventing the planning run from creating new supply for segment demands.

• CBP will go GA (generally available) with 2502
• All Customers/partners from 2502 onwards can request CBP activation
• Request activation: through a Ticket addressed to component SCM-IBP-TDS
• Prerequisites and release restrictions still apply - refer next slides
• Response and Supply Order Based Planning (OBP) with Real Time Integration
• Instance runs on Hana cloud
• Backend SAP ERP system on right support package or notes (see note 3435209):
• OKF (Order based Key Figures) instead of external Key Figures
  • New Cache mode (in addition to today not cached)

With the enhancement in 2502, the Order should memorize the SoS Filter Attribute Values on Input and Output side:

A Stock Transfer Order supply can only be consumed in case it fulfills the Transport Filter criteria

Due to a minimum lot size, an STR might transport a higher quantity than required to satisfy the first demand. Other demands with SoS filtering requirements need to know if the remaining quantity can be used or not

With the enhancement in 2502, the Order should memorize the SoS Filter Attribute Values on Input and Output side:

Restrictions:

• Only Propagation to One Main Component with Same Attributes Set
• 1:1 Relationship between Component Quantity and Output
• No lot size allowed; no Filtering possible
• Component Validity: Exactly one component must be valid to be bi-directional for the validity of the PDS header (late Engine Check because of Start/End)
• No backend integration yet to and from S/4 or ERP-> Roadmap for upcoming release

• CBP will go GA (generally available) with 2502
• All Customers/partners from 2502 onwards can request CBP activation
• Request activation: through a Ticket addressed to component SCM-IBP-TDS
• Prerequisites and release restrictions still apply - refer next slides

• Response and Supply Order Based Planning (OBP) with Real Time Integration
• Instance runs on Hana cloud
• Backend SAP ERP system on right support package or notes (see note 3435209):
• OKF (Order based Key Figures) instead of external Key Figures
  • New Cache mode (in addition to today not cached)

Not supported (Restrictions)

• Optimizer run- only OBP Finite Heuristics
• Safety Stock key figure will be ignored in supply planning run*
• Deployment
• Transport Load Building (TLB)
• Minimum and max key figures ( adjustment) will be ignored in the whole planning run
• Shelf life product cannot run with CBP product in one planning run
• Allocation as constraint in OBP is not supported and will be ignored with error message
• Jobs bases on the template "Data Integration: Extraction of Order-Based Planning Results" doesn't include CBP attributes
• Interactive planning in projected stock or planner workspaces will not be supported for creation/change
• Propagation from attribute in production is only supported for 1:1 relationship of output and component. More complex scenarios incl. Super BOM and explosion rules are not supported
• Regarding further restrictions and frequently asked questions please refer to SAP note 3422877:or documentation:

• SAP IBP Characteristics- Based Planning:
• Setting Up Characteristics-Based Planning
• Proactive Supply Decisions with Characteristics-Based Planning (CBP) in SAP IBP 2408:
• Supply Chain Management Blogs by SAP
• SAP IBP What's New 2408: Characteristic-Based Planning

WHAT?

• In the ERP system, a Storage Location MRP area (in short: MRP area) is an organizational unit within a plant for which you carry out separate material requirements planning and inventory management
• • An MRP area might consist of one or more storage locations

• HOW?

• With MRP areas, you can perform material requirements planning at a more granular level than at the plant level
• • You can use RTI to transfer selected MRP areas to SAP IBP, where they are mapped automatically as independent locations and are fully fledged for planning.

• WHY?

• Out-of-the-box integration with SAP ERP and IBP, requiring less adaptation and custom development.

Using MRP Areas you can plan your location products in separate planning segments modelled as locations with reference to the same plant.

For example, the planning of production can be separated from distribution by assigning forecast and sales orders to an MRP Area location which has a DC function and is replenished via stock transfers from the MRP Area for production within the same plant.

Also, multiple MRP areas with a production and/or DC function can be set up within the same plant enabling dedicated planning parameters and separate stock buffers for different markets.

Value Proposition

Manage complex supply chain relations within a plant without creating additional plants in your ERP backend system. Instead, make use of MRP Areas for segmentation while leveraging all IBP Response and Supply planning functions out of the box as if they were plants.

Capabilities

• Set-Up and Master Data integration
  • Create an MRP Area and integrate it as a location
  • Decide which products within a plant are planned in a segmented way using MRP Areas
  • Create transportation lanes to MRP Area locations based on special procurement types via RTI, create additional transportation lanes via flexible master data maintenance or RTI BAdI
  • Create production data sources in all or dedicated locations of the same plant via RTI
• Planning and Transactional Data Integration via RTI
  • Separate stock, sales orders, forecast and other demand or supply elements within a plant
  • Plan them per MRP Area and map locations on IBP side with storage locations on ERP side

• Location attribute Plant Type
• • Plant Type has a new value MR (MRP Area) for distinguishing locations for Storage Location MRP Areas from Plant MRP Areas (with Plant Types PL or DC)
• Location attribute Reference Location for MRP Area (in short: Reference Location)

RTI master data integration will fill this new attribute with:

• The Location ID for all Plant MRP Areas (Plant Types PL or DC)
• The Location ID of the referenced Plant for all Storage Location MRP Areas (Plant Type MR)

The Reference Location attribute is used for selecting and filtering location products that belong to the same plant across all of its MRP Areas.

Do not maintain the attribute Reference Location on the SAP IBP side via flexible master data maintenance on top of RTI master data integration!

• Time Zone and Production Calendar
• In RTI integration, these attributes are filled from the Plant MRP Area (Reference Location) for all Storage Location MRP Areas.
• Do not(!) maintain these attributes on the SAP IBP side via flexible master data maintenance on top of RTI master data integration
  • On the ERP side the Factory Calendar cannot be differentiated by MRP Area
  • Deviating values might lead to date-time inconsistencies of supply or demand elements between SAP IBP and the ERP system
• Attributes regarding GeoLocation and Address
• In RTI integration attributes such as Longitude, Country, ZIP Code, or City are filled from the values of the default receiving storage location according to transaction OMIZ in case of MRP Area Locations.
• As the physical location of an MRP Area has real life interdependencies with Time Zones and Calendars do not (!) use MRP Areas as a workaround for a distant plant that is in a different time zone or subject to a different legislation w.r.t. to relevant planning parameters

• The Reference Location attribute is used for selecting and filtering location products that belong to the same plant across all of its MRP Areas.
• The following applications contain Reference Location as a filtering and display attribute:
• Manage Master Data
  • Location Attribute
  • Location Product Attribute
• Projected Stock
• View Master Data apps, such as View Locations
• Supply Chain Dependencies
• Analyze Supply Usage
• View Confirmations
• View Gating Factors
• View Stock Details
• Orders

• MRP Area Locations are fully fledged locations of type Plant (P)
• There is no difference regarding planning capabilities and features between Plant Type (MR) MRP Area vs. Plant Type (PL) Production od (DC) Distribution Center.
• All Planning Processes: including Supply Planning, Response Management, Deployment Planning, Transportation Load Building and Supply Usage and Gating Factors are available for MRP Area Locations.
• Exception: The Planning Processes Production Planning Integration is not released yet with IBP 2502.
• There are no specifics in the way of making Basic Settings: in OBP such as setting up planning run profiles
• Exception: Some specific settings regarding RTI. See SAP Help: Real-Time Integration with SAP ECC or SAP S/4HANA:
• There are no limitations or specifics regarding
  • OBP Planning Algorithms: such as OBP Optimizer
  • OBP Planning Runs:such as Deployment Runs
  • Planning Functions:such as Forecast Consumption, Shelf Life, or Subcontracting.
• There are no limitations or specifics regarding OBP features for Reviewing and Refining Plans: such as:
  • Analyze Supply Usage
  • Interactive Planning
  • Adjusted Quantities.

The following preparation steps need to be taken to use Storage Location MTP Areas in SAP IBP

1. Define MRP Area of type Storage Location (Transaction Code OMIZ)
2. Assign material to the MRP Area (Transaction Code MM02)
3. Extend materials to the storage location
4. [Optional] Maintain issuing storage location for component in order to determine the withdrawal location
5. [Optional] Maintain receiving storage location for production version in order to define production versions for a dedicated MRP Area only

• MRP Areas are defined in transaction OMIZ
• There are 3 types of MRP Areas in SAP S/4HANA
• Plant (01)
• Storage Location (02)
• Subcontracting (03)
• Create an MRP Area entry of type Storage Location or maintain an existing entry
• Storage Location MRP Areas are assigned to a Plant which is an MRP Area of type plant at the same time
• In IBP the respective plant is referred to as Reference Location.
• Assign at least one Storage Location to the entry
• Also specify a receiving storage location
• The receiving storage location is used to determine a default the storage location for both:
• output elements and
• input elements

of planned receipts created for MRP Area locations and integrated RTI outbound to SAP S/4 HANA

• MRP Area views for materials are maintained in the MRP1 view of the Material Master (transaction codes MM01, MM02)
• Press the MRP Area button in the MRP1 view of the material master
• Maintain an entry for every location product that shall be planned in a separate MRP area location or review existing entries
• Only materials for which an MRP Area view is maintained in the material master can be integrated as an MRP Area Location Product to SAP IBP.
• Stock as well as demand or supply elements which are assigned to an MRP storage location where the material has no MRP area view in the material master will be planned as elements of the product in the reference location (MRP Area type plant).
  • In this document we will refer to this as "fallback to the reference location"

• The MRP Area view of the material allows a limited number specific settings for the material in an MRP Area
• For example:
• an MRP Area specific MRP Controller, planned Delivery Time or Safety Stock can be defined in the MRP1 tab
• an MRP Area specific Planned Delivery Time and Safety Stock can be defined in the MRP2 tab
• a Special Procurement Key can be defined in the MRP2 tab of the MRP Area view based on which transportation lanes can be generated.

• Each and every storage location that is assigned to an MRP Area location needs to be released for transactions that assign demand and supply elements for a given material
• The extension of material to storage location can be done from Plant Date / stor. 1 tab of the material master (transaction MM02)
• Alternatively, transaction MMSC Collective Maintenance of storage locations for materials can be used for the same purpose

Master data are integrated from SAP S/4HANA to SAP IBP in two steps

• Transaction CFM1: Create integration model(s) for
• • MRP Area
  • MRP Area-Material
  • Transportation Lane
  • Production Data Structure
• Transaction CFM2: Activate integration model(s)

• In order to integrate a material with an MRP Area view from SAP S/4HANA to SAP IBP both MRP flags have to be checked at the same time
• MRP Area Material
• MRP Areas

even if an active integration model already exists for the MRP Area

• As a prerequisite the respective Material and the Plant must be in an active integration model already or be integrated with the same integration model.
• If an MRP Area shall not be integrated to SAP IBP in order to plan its products within the reference location it must explicitly be excluded from the MRP Area selection of integration models where MRP Area Material and MRP Areas are flagged.
• Setting MRP Area flags corresponds to a business configuration decision to adopt the standard RTI based MRP Area feature of SAP IBP.
  • Customers already using BAdI extensions as a workaround for MRP areas may continue their BAdI usage if they do not use CFM models with MRP flags.

• All Storage Location MRP Areas (Type 02) from SAP S/4HANA in an active integration model are integrated to SAP IBP as a separate MRP Area Location which
• has location type Plant (P)
• has plant type MRP Area (MR)
• has a reference location which is the corresponding plant MRP Area (Type 01)
• MRP Area locations are integrated in addition to the Reference Location which
• corresponds to the MRP Area of type plant (01) in SAP S/4HANA
• has location type Plant (P)
• has plant type Plant (PL) or Distribution Center (DC)
• is assigned to itself as a reference location
• MRP Area Locations are only integrated to IBP, if:
• the MRP Area flag is set in CFM1
• the MRP area is in scope of the filter for the MRP Area flag
• the reference location is active in CIF integration model
• the reference location entry exists in MDT LOCATION

• All MRP Area Materials which are in an active integration model are integrated to SAP IBP as additional location products in an MRP Area location
• Products for MRP Area Locations are only generated, if:
• MRP Area and MRP Area Material flags are set in CFM1
• MRP area and the Material is in scope of the filter for the both flags
• Product is maintained in the MRP Area view of material master
• The material for the Plant MRP Area (reference location) is active in CIF Integration model
• Location entry for the MRP Area exists in MDT LOCATION

• Transportation Lanes are created based on special procurement key (SPK) maintained in the material master on MRP Area Level during the MRP Area-Material integration
• Transportation Lanes from any plant location to any MRP Area location can be created based on SPK automatically.
• Special Procurement Keys are defined for the reference plant of the MRP Area Location Product in customizing.
• Customizing Path: Production/MRP/Master Data/Define Special Procurement Type

• Transportation Lanes
• from an MRP Area Location to a Plant Location
• from an MRP Area Location to an MRP Area Location

can only be created

• either via BAdI implementation (based on purchasing info records for the plant location)
• or directly in SAP IBP via master data maintenance

• Transportation Lanes for stock transfers of type 7 which are generated from a plant location to an MRP Area Location based on a Special Procurement Type (SPK) can be spotted by their
• typical ADDLANEID string: 7____00000
• the Created By attribute which is a communication user

Purchasing TLANE (Type 0) and Subcontracting TLANE (Type 3)

• TLANEs from a vendor to a an MRP Area Location, can be created
• via BAdI implementation based on the purchasing info record for the plant
• directly in SAP IBP via master data maintenance

Stock transfer TLANEs (Type 7) for components based on Subcontracting PDS

are not created by RTI because stock in the Vendor Location cannot be segmented by MRP Area from an MRP Area Location to a Vendor Location

• PDS can be created on both Plant and MRP Area location in IBP depending on the receiving storage location maintained in the production version
• The component's locations are determined during integration based on the issuing storage location which might be specified in various master data such as BoM, Material Master or Production Version

• If there is no receiving storage location maintained the PDS will be created
• on the plant location
• and on all MRP Area locations to which the output material is assigned in the material master and for the MRP Area-material combination there is an active integration model
• If a receiving storage location is assigned to the production version, the PDS will be created
• only on the MRP Area location if the storage location is assigned to the MRP Area to which the output material is assigned in the material master and for the MRP Area-material combination there is an active integration model
• in any other cases the PDS will be created only on the main plant (like storage location does not belong to any MRP area, MRP area no assigned to the output material, there is no active integration model)
• In case of multiplication of the PDS to MRP Area, all PDS master data types are multiplied (header, activity, resource, component)

• Based on the ERP settings in plant FA1 all components are withdrawn from the same location in this simple example
• As production version 0001 has no receiving storage location the components of the PDS have been multiplied to the MRP Area locations as well.
• The prerequisite for this is that there is
  • An MRP Area View in the material master of the components
  • An active integration model for the components

in each MRP Area.

• Issuing storage location maintained in SAP ERP determines the withdrawal location in SAP IBP
• It can be maintained on multiple levels, follows an hierarchical approach
• PDS integration follows the standard SAP ERP rules to assign storage location to component
• PDS integration translates plant and storage location combination to MRP Area location. If succeeds and the component is assigned to the MRP Area and this combination is in an active integration model, from SAP IBP point of view it is a withdrawal from alternative location scenario
• In any other cases the component is withdrawn from the main plant (fallback)
• When PDS gets multiplied to MRP Areas the following rule is applied for components
• PDS in the main plant considers the storage location as described above and assign the component to the right MRP Area if needed
• PDS components on MRP Area locations will be assigned only to the MRP Area location to which the PDS is being copied over (no storage location considered) by default, if not possible assignment will be on the main plant as fallback
• If PDS is to be created only on MRP Area location (due to the receiving storage location) during the withdrawal location determination storage location is considered as if the PDS was created on the main plant
• If component has special procurement type to support withdrawal from alternative plant, no storage location is taken into account additionally

• These are the priority rules to determine the issuing storage location for compo-nents when creating planned orders in ERP, including RTI Outbound integration
• In RTI MD integration, the same rules are applied to the integration of PDS, to find the right location for components according to these storage locations, if all integration prerequisites are met.
• Avoid fallback assign-ments of reference loca-tions for PDS components: Ensure that the MRP Area is maintained in the material master and an RTI Integration Model exists for these component location products. Otherwise IBP vs. ERP inconsistencies for planned orders will occur.

• RTI determines the component location based on logic to find the issuing storage location when creating planned orders in ERP
• In the example to the right the issuing storage location for planned order creation is as follows:
  • A001 in MRP Area FA1_A for BOARD, CASE and CPU
  • A002 in MRP Area FA1_A PACKAGING
  • 0001 in plant MRP Area of alternative plant FA2 for MEMORY
• Usually, all PDS components to be picked from storage locations A001 or A002 in MRP Area FA1_A are integrated with respect to component location FA1_A
• However, in the example to the right only the component location of PACKAGING is FA1_A in IBP. This is because in case of BOARD, CASE and CPU one of the following was missing:
  • Component has no MRP Area View in the material master
  • Component has no active integration model with both MRP Area related check boxes selected in CFM1
  • Ensure that the above prerequisites are met for components to be picked from specific MRP area locations. Otherwise, planned orders from IBP will not have consistent MRP Areas in ERP because the planned order component's storage location is determined without fallback on the ERP side

• With IBP release 2502 RTI-CIF Structures have been extended by the field MRP Area
• Every business document is integrated to IBP with the MRP Area ID in addition to the Plant Number in order to map it to the right location
• CIF Structures in RTI are extended with MRP Area information for both
  • document's output nodes, e.g. production order's output product
  • document's input nodes, e.g. production order's components
• MRP Area Determination on ERP Outbound side
• In SAP ERP business documents are stored with respect to the storage location whereas in IBP documents are only stored with respect to their location (i.e. MRP Area location), except for stock
• Therefore, in ERP Outbound processing for RTI the MRP Area is determined based on the document's storage location before it is submitted to IBP using he enhanced CIF structures.
• Prerequisites for document integration into MRP Area locations:
• The Material must have a MRP area view in the material master
• CIF Flags for both MRP Area and MRP Area Material must be checked and active for material for the respective material and MRP area selection
• Otherwise, the business document is integrated to the reference location as a fallback handling

Use Cases:

No fallback

Product A in MRP Area M1: Fulfills all requirements for integration into location 0001M1.

Fallback

to reference location due to missing requirements

Product A in MRP Area M2: No active entry for MRP Area M2 in RTI Integration Model

Product C in MRP Area M1: No active entry for MRP Area Material C in RTI integration model.

Product D in MRP Area M1: Missing MRP Area entry in material master for material D.

RTI/CIF queue error:

Product B in MRP Area M1: Fulfills all requirements for integration into location 0001M1 but location product was deleted on IBP side.

• With IBP release 2502 RTI-CIF Structures have been extended by the field MRP Area
• Planned receipts are integrated to ERP with the MRP Area ID in addition to the Plant Number based on the location and reference location IDs.
• CIF Structures in RTI are extended with MRP Area information for both, the document's:
  • output nodes, e.g. planned order's output product
  • input nodes, e.g. planned order's components
• Storage Location determination on ERP Inbound side
• In SAP ERP business documents are stored with respect to the storage location whereas the planned receipts from IBP documents are only stored with respect to their location (i.e. MRP Area location).
• In case, there are multiple storage locations per MRP Area a storage location has to be determined
• The determination of the storage location may depend on different logic for different document types. (See details on next slide)

Storage Location determination on ERP Inbound side (Details)

In case, there are multiple storage locations per MRP Area

• the storage location for the output node of all planned receipts is defaulted based on the receiving storage location of the MRP Area (tx Code OMIZ).
• the storage location for the input node of stock transfer requisitions is also defaulted based on the receiving (!) storage location of the MRP area.
• the storage location for the planned order components is determined based on the RTI PDS integration logic to determine component locations in case of master data settings for component issuing storage locations.
• The standard behavior can be enhanced via BAdI

Demo Scope

• Stock Transfers from MRP Area to MRP Area (FA1_B→DC1_A)
• Production in MRP Area (FA1_B)
• External Purchasing to MRP Area (FA1_B)

Transactional RTI Inbound in order execution

• Convert purchase requisition and process order
• Convert planned order and process order
• Convert stock transfer requisition and process order
• Scrap stock in FA1_A
• Change sales order
• Create, consume, and reduce forecast

Transactional RTI Outbound after supply planning

• Re-plan stock transfers
• Re-plan planned orders
• Re-plan purchase requisitions
• Deployment and TLB

• Compare the planning situation Projected Stock App in IBP vs. the Requirements Stock List (MD04 in ERP).
• Note that storage location IDs are always visible for all business documents in ERP. IBP aggregates them to MRP Area locations.

• For the stock transfer receipts the receiving storage location A001 is specified in the last column.
• For the stock transfer requirements the issuing storage location B001 is visible in the column next to the ship-from plant FA1 .
• Note that in SAP S/4H the MRP Area of a connected product location is identifiable by the storage location of the connected plant.
• For the sales order requirements the differences regarding issuing storage location A001 vs. A002 are visible in the last column.

• In the initial planning situation for the finished product in the MRP Area location B of the factory plant FA1 is balanced.
• The stock transfer requirements from DC1 MRP Area A are covered by planned orders.

• For the planned orders the receiving storage location B001 is specified in the last column.
• For the stock transfer requirements the receiving storage location A001 is visible in the column next to the ship-to plant DC1.
• Note that in SAP S/4H the MRP Area of a connected product location is identifiable by the storage location of the connected plant.
• For the stock transfer requirements the issuing storage location B001 is specified in the last column.

• In the initial planning situation for the component in the MRP Area location B of the factory FA1 is balanced.
• The component requirements from planned orders are covered by purchase requisitions.

• For the purchasing receipts the receiving storage location B001 is specified in the last column.
• For the dependent requirements the issuing storage location B001 is visible in the last column.

• We start the order execution journey upstream in order to fulfill ATP checks for downstream orders.
• That is, first we show the conversion of a purchase requisition in an MRP area and the follow up steps until GR which are performed with respect to storage locations and are displayed on IBP side at MRP Area level

Select the purchase requisition from the stock / requirements list and convert it interactively.

Pull the requisition to the shopping cart and save to create the purchase order

• Note the Purchase Order in the Stock/Requirements List
• Note that the storage location of the purchase requisition was inherited, so it remained in the same MRP Area

• Note the purchase order in the Projected Stock app's element view.
• Note that the purchase order was integrated to the same MRP Area, because an MRP Area is defined for the material CPU_A. Otherwise the purchase order would have been integrated to the reference location FA1 (Plant MRP Area).

Post goods receipt against the purchase order for the component in the receiving storage location B001 indicating MRP Area B in Plant FA1 according the purchase order.

• Note that 2 purchase orders with 61 and 5 EA respectively have vanished from the stock requirements list in the MRP Area B of plant FA1 after GR.
• Note that stock has increased by 66 EA to 70 EA in MRP Area B of plant FA1

• Note that 2 purchase orders with 61 and 5 EA respectively have vanished from the element view in the MRP Area B of plant FA1.
• Note that stock has increased by 66 EA to 70 EA in MRP Area B of plant FA1

• We continue the order execution journey with the planned order conversion for the finished good in MRP Area B of plant FA1.
• We show the conversion of a planned order in an MRP area and the follow up steps until GR which are performed with respect to storage locations and are displayed on IBP side at MRP Area level.

Select the planned from the stock / requirements list and convert it interactively.

Note that the availability check for components was successful because GR for components had been posted into the storage location B001 of the MRP Area B in plant FA1.

Note that the production order inherits the receiving storage location for the finished good from the planned order.

• Note the production order in the Projected Stock app's element view.
• Note that the production order was integrated to the same MRP Area, because an MRP Area is defined for the material PHONE_A. Otherwise the production order would have been integrated to the reference location FA1 (Plant MRP Area).

Note that the production order inherits the issuing storage location for the components from the planned order.

• Note the production order component requirement in the Projected Stock app's element view.
• Note that the requirement was integrated to the same MRP Area, because an MRP Area is defined for the material CPU_A. Otherwise the production order's dependent demand would have been integrated to the reference location FA1 (Plant MRP Area).

Post goods receipt against the production order for the finished good in the receiving storage location B001 indicating MRP Area B in Plant FA1 according the production order.

• Note that the production order with 70 EA has vanished from the stock requirements list in the MRP Area B of plant FA1 after GR.
• Note that stock has increased by 70 EA to 70 EA in MRP Area B of plant FA1

• Note that the production order with 70 EA has vanished from the stock requirements list in the MRP Area B of plant FA1 after GR.
• Note that stock has increased by 70 EA to 70 EA in MRP Area B of plant FA1

• Note that the production order's dependent demand for component CPU_A of 70 EA has vanished from the stock requirements list in the MRP Area B of plant FA1 after GR.
• Note that stock has decreased by 70 EA to 70 EA in MRP Area B of plant FA1

• Note that the production order's dependent demand for component CPU_A of 70 EA has vanished from the stock requirements list in the MRP Area B of plant FA1 after GR.
• Note that stock has decreased by 70 EA to 70 EA in MRP Area B of plant FA1

• We complete the order execution journey with the STO conversion for the finished good in MRP Area A of plant DC1.This part of the process is very detailed due to two step processing wrt both outbound and inbound deliveries.
• We show the conversion of a STR in an MRP area and the follow up steps until GR which are performed with respect to storage locations and are displayed on IBP side at MRP Area level.

Select the stock transfer requisition from the stock / requirements list and convert it interactively.

• Pull the requisition to the shopping cart and save to create the purchase order
• In case of multiple storage locations the receiving storage location can be changed. In this case it is changed from A001 to A002 during interactive conversion within same MRP Area DC1_A.

• Note the Stock Transport Order in the Stock/Requirements List
• Note that the storage location of the STR was not inherited to the change during conversion, but it remained in the same MRP Area

• Note the Stock Transport Order requirement in the Stock/Requirements List
• Note that the storage location of the STR in the ship-from location was inherited during conversion, so it remained in the same MRP Area

• Note the stock transport order in the Projected Stock app's element view.
• Note that the order was integrated to the same MRP Area, because an MRP Area A is defined for the material PHONE_A in DC1. Otherwise the order would have been integrated to the reference location DC1 (Plant MRP Area).

• Stock is the only document type that has storage location detail
• Note the on hand stock before receiving PHONE_A in MRP Area A of DC1.
• 80 EA are available in storage location A0001
• 50 EA are available in storage location A0002
• 130 EA are available in total in MRP Area A of DC1.

• Note the STO requirement in the ship-from location in the Projected Stock app's element view.
• Note that the requirement was integrated to the same MRP Area, because an MRP Area B is defined for the material PHONE_A in Factory FA1. Otherwise the production order's dependent demand would have been integrated to the reference location FA1 (Plant MRP Area).

• We continue the journey for STOs with outbound and inbound deliveries.
• First the outbound delivery is created with respect to the storage location B001 indicating MRP Area B of FA1.
• Next the inbound delivery is created with respect to the storage location A001 indicating MRP Area A of DC1.

• Create the outbound delivery in transaction VL10B
• ATP check is passed because sufficient stock exists from the GR production orders into the issuing storage location B001.

• Note the outbound delivery requirement in the Stock/Requirements List
• Note that the storage location of the STO in the ship-from location was inherited, so it remained in the same MRP Area

• Note the outbound delivery requirement in the ship-from location in the Projected Stock app's element view.
• Note that the requirement was integrated to the same MRP Area, because an MRP Area B is defined for the material PHONE_A in Factory FA1. Otherwise the outbound delivery would have been integrated to the reference location FA1 (Plant MRP Area).

• Create the inbound delivery directly from the confirmations view of the stock transfer order
• Note that the receiving storage location A002 was inherited from the STO

• Note the inbound delivery requirement in the Stock/Requirements List as a shipping notification.
• Note that the receiving storage location A002 was inherited from the STO, so it remained in the MRP Area (see last column)
• Note that the issuing storage location B001 is displayed next to the ship-from plant.

• Note the inbound delivery in the Projected Stock app's element view.
• Note that the inbound delivery was integrated to the same MRP Area, because an MRP Area A is defined for the material PHONE_A in DC1. Otherwise the inbound delivery would have been integrated to the reference location DC1 (Plant MRP Area).

• We finalize the journey for STOs with outbound and inbound deliveries.
• First GI is posted for the outbound delivery for issuing storage location B001 indicating MRP Area B of FA1.
• Next GR is posted for the inbound delivery for the storage location A001 indicating MRP Area A of DC1.

• Note that outbound delivery with 70 EA has vanished from the stock requirements list in the MRP Area B of plant FA1 after GI.
• Note that stock has decreased from 70 to 0 EA as well.
• Stock is in-transit now.

• Note that outbound delivery with 70 EA has vanished from the element view in the MRP Area B of plant FA1 after GI.
• Note that stock has decreased from 70 to 0 EA as well.
• Stock is in-transit now.

Post goods receipt against the purchase order in the receiving storage location A002 indicating MRP Area A in Plant DC1.

• Note that inbound delivery with 70 EA has vanished from the stock/requirements list in the MRP Area A of plant DC1 after GR.
• Note that stock has increased from 130 to 200 EA as well.
• Stock is no longer in-transit now.

• Note that inbound delivery with 70 EA has vanished from the element view in the MRP Area A of plant DC1 after GR.
• Note that stock has increased from 130 to 200 EA as well.
• Stock is no longer in-transit now.

• Stock is the only document type in SAP IBP that has separation by Storage Locations.
• Note that stock has increased from 50 to 120 EA in Storage Location A002 of MRP Area A in DC1, specifically.

In this part of the process demo we show that the MRP Area Location of a sales order is determined by changing the issuing storage location in the Shipping Tab of the sales order transactions in SAP S/4H or SAP ECC.

• Sales order is changed in transaction VA02.
• Sales order item 30 for PHONE_A with 200 EA had been created for shipment from storage location A002 of MRP Area A of DC1.
• First, the quantity is changed from 200 EA to 300 EA in the Sales A view.

• Sales order item 30 for PHONE_A with 200 EA had been created for shipment from storage location A002 of MRP Area A of DC1.
• In a second step, the issuing storage location is changed from storage location A002 of MRP Area A of DC1 to storage location A001 of the same MRP Area in the shipping view.

• Note that for sales order item 30 for PHONE_A:
• the quantity has changed from 200 EA to 300 EA
• issuing storage location has changed from storage location A002 of MRP Area A of DC1 to storage location A001 of the same MRP Area.

• Note that for sales order item 30 for PHONE_A the quantity has changed from 200 EA to 300 EA leading to a shortage which has to be covered by a new planning run.
• Note that the change of the issuing storage location from storage location A002 of MRP Area A of DC1 to storage location A001 of the same MRP Area cannot be seen in the element view because storage locations are not relevant for planning in SAP IBP.
• If the storage location had been changed from A002 of MRP Area A of DC1 to storage location 0001 of the reference location, the entire sales order item quantity would not no longer be visible in the selected MRP Area A because the sales order item would have been integrated with respect to the reference location DC1.

• After the increase of Sales Order Requirement from 200 EA to 300 EA in MRP Area Location B of DC1 an IBP Supply Run was performed to cover demand across the supply chain of our connected MRP Area Locations.
• We will comparing the new planning situation in the Projected Stock App in IBP vs. the Requirements Stock List (MD04 in ERP).
• Note that storage location IDs are always visible for all business documents in ERP. IBP aggregates them to locations.

• Note that for sales order item 30 for PHONE_A in MRP Area A of DC1 the quantity had been changed from 200 EA to 300 EA leading to a shortage which was covered by the new planning run.
• Note that an additional stock transfer requisition with 100 EA was created because the existing STR had been fixed before the run.

• Note that for sales order item 30 for PHONE_A in MRP Area A of DC1 the quantity had been changed from 200 EA to 300 EA leading to a shortage which was covered by the new planning run.
• Note that an additional stock transfer requisition with 100 EA was created because the existing STR had been fixed before the run.
• Note that in the ERP system both storage locations are visible in the stock requirements list:
• the issuing storage location B001 of MRP Area B in Ship-From Plant FA1
• the receiving storage location A001 of MRP Area A of ordering plant DC1
• Note that a deliberate choice has been taken for the receiving storage location during the ERP inbound integration of the new STR.
• SAP IBP only submits the MRP Area information, even in case it has multiple storage locations, e.g. A001 and A002 in MRP Area A of DC1.
• For this STR, SAP S/4H has determined the storage location A001 based on the default receiving storage location maintained in transaction OMIZ
• Note that a deliberate choice has also been taken for the issuing storage location during the ERP inbound integration of the new STR.
• For this STR, SAP S/4H has determined the issuing storage location B001 based on the default receiving (!) storage location maintained in transaction OMIZ for MRP Area B of ship-from plant FA1.
• Note that the field labeled as receiving storage location in OMIZ is also used for the defaulting of issuing storage locations of stock transfers.

• Note that in MRP Area Location B of Factory FA1 stock requirements for PHONE_A from MRP Area A of DC1 the quantity have increased from 200 EA to 300 EA in total.
• Note that the existing planned order with 200 EA was replaced by a new one with 300 EA by the IBP Supply Run.
• Note that production version 0001 is used for MRP Area Location B of reference location FA1. This is the production version of a production data structure explicitly replicated into MRP Area Location B. Keep in mind the following:
• If the receiving storage location of a production version is empty in SAP ECC or SAP S/4HANA then the same production version is created in all MRP Areas of a reference location.

• Note that in MRP Area Location B of Factory FA1 stock requirements for PHONE_A from MRP Area A of DC1 the quantity have increased from 200 EA to 300 EA in total.
• Note that the existing planned order with 200 EA was replaced by a new one with 300 EA by the IBP Supply Run.
• Note that in the ERP system the receiving storage location B001 of MRP Area B of plant FA1 is displayed in the stock requirements list.

• Note that in MRP Area Location B of Factory FA1 component demand for CPU_A from PHONE_A has increased from 200 EA to 300 EA in total.
• Note that the existing purchase requisition with 200 EA was replaced by a new one with 300 EA by the IBP Supply Run.

• Note that in MRP Area Location B of Factory FA1 dependent demand for CPU_A from PHONE_A has increased from 200 EA to 300 EA in total.
• Note that the existing purchase requisition with 200 EA was replaced by a new one with 300 EA by the IBP Supply Run.
• Note that in the ERP system the receiving storage location B001 of MRP Area B of plant FA1 is displayed in the stock requirements list.

Deployment and TLB Orders created in MRP Area Locations are integrated to the right MRP Area with their specific procurement statuses D and C respectively.

Convert the fixed stock transfer requisition for PHONE_A in MRP Area Location A of Factory DC1 interactively.

• Note that the fixed stock transfer requisition for PHONE_A in MRP Area Location A of Factory DC1 has been converted to a deployment requisition.
• Note that the external order number of the requisition has not changed.

• View the deployment requisition in transaction ME52N in SAP S/4HANA.
• Note that the Procurement status of the "purchase requisition" for PHONE_A in MRP Area Location A of Factory DC1 has been set to "Deployment STR" after the stock transfer requisition was converted to a deployment requisition in SAP IBP.

In SAP IBP sales orders are consumed and reduced with respect to locations.

If you flag MRP Areas in the RTI integration model CFM1, make sure to split the overall "plant" forecast for a product according to the specific customer segmentation across the reference location and every referencing MRP Area before performing supply planning in OBP. Also keep in mind that split forecast consumption can be affected from changes of the shipping storage location of a sales order from the time of creation until goods issue.

Creation of Forecast

• Note that the key figure Forecast Unconstrained is maintained in March only with 1000 EA.
• As monthly forecast consumption is set-up the new forecast does not match with any sales order from January or February
• Note that the key figures
• Forecast Consumption Relevant Quantity and
• Goods Issue Quantity on Sales Order Demand Date

are empty in March as there is no Sales Order Requested

Creation of Forecast

• Note that the Forecast element is visible at the first day and second of March with 1000 EA
• As monthly forecast is set-up the new forecast does not match with any sales order from January or February

Consumption of Forecast through Sales Orders

• Note that the Forecast Unconstrained value of 1000 EA in March has been split and shifted to January and February with 200 EA and 800 EA respectively.
• As monthly forecast is set-up the changed forecast now matches with sales orders in January or February, so consumption may take place
• Note that the key figure Goods Issue Quantity on Sales Order Demand Date is empty in January and February as the sales orders are only created but not yet further processed.

Consumption of Forecast through Sales Orders

• Note that the forecast of 1000 EA in March has been split and shifted to January and February with 200 EA and 800 EA respectively.
• As monthly forecast consumption is set-up the forecast now matches with sales orders in January or February, so consumption takes place
• In the Projected Stock view the open forecast elements are being shown with 150 EA and 600 EA respectively after consumption with the respective sales orders in January and February.
• Note that the sales orders only consume forecast in the MRP Area A of DC1 because of the choice for shipping from Storage Location A001. If shipping storage location is changed to another one which is not assigned to MRP Area B then the forecast at another location would be consumed.

Forecast Consumption during the stage of Outbound Delivery

• An Outbound delivery has been created for the sales order in January replacing it in the Projected Stock app.
• Note that the quantity of open forecast element in January (150 EA) does not change during outbound delivery processing until GI.
• Note that the sales order scheduling items in outbound delivery stage consume forecast in the MRP Area A of DC1 because of the initial choice for shipping from storage location A001. If the storage location of an outbound delivery was changed to one which is not assigned to MRP Area A then the outbound delivery would be integrated to another location but forecast would still be consumed at MRP Area A through the last changed shipping storage location before creating the outbound delivery.

Forecast Consumption at GI

• Goods issue of 50 EA was posted for the full sales order quantity in January
• Note that the key figure Goods Issue Quantity on Sales Order Demand Date is now filled in MRP Area A of DC1 in January,

Forecast Consumption at GI

• Goods issue of 50 EA was posted for the full sales order quantity in January.
• Note that stock on hand has decreased from 250 EA to 200 EA accordingly.
• Note that the outbound delivery of 50 EA has vanished accordingly and that the GI did not change the open forecast of 150 EA in January.
• Note that the sales order scheduling items in outbound delivery stage consume forecast in the MRP Area A of DC1 because of the initial choice for shipping from Storage Location A001. If the outbound delivery quantity was picked from a storage location not assigned to MRP Area A during GI then stock would decrease in another location but the forecast would still be consumed at MRP Area Location A through the storage location last changed before outbound delivery.

If a product is not part of an RTI Integration Model for an MRP Area in the ERP system, then all demand and supply elements are integrated with respect to the reference location in RTI transactional data integration.

Example:

• Even if the MRP Area exists in ERP and an MRP area view is created in the MRP1 tab of the material master (transaction MM02) there will be no location product for product F in MRP Area 0001M2 in IBP.
• Hence, all transactional demand and supply elements will be integrated with respect to the Reference Location 0001 (Plant MRP Area) as a fallback until it is activated to the RTI integration model.
• The same fallback mechanism will occur in transactional data integration as soon as Product E in MRP Area 0001M1 is removed from the RTI Integration model.
• Not only, the split of transactional documents between locations of the same reference location changes with RTI model changes but also all planning related set-up and parametrization must be adapted to appropriately control which product is planned in which location with which forecast, which priorities, which quota for which planning outcome of which OBP run.
• In the following, various planning set-up and parametrization aspects are highlighted. Review them before using MRP areas in IBP first time or adding or removing location products from MRP Area locations in ongoing operational mode.

• Without MRP Area Locations the LOCATION ID selection criterion has been maintained with Reference Locations (Plant MRP Areas) only.
• Now, there will be additional MRP Area Locations, which need to be maintained to define a appropriate planning scope

Therefore:

• Check and adjust OBP Job Templates regarding planning filters:
• Examples: Create Planned Receipts from Interactive Key Figures Run or Delete Planned Receipts
• Check and adjust OBP Job Templates with explicit selection fields for Location:
• Examples: Supply Planning Run or Supply Usage and Gating Factor Run or Copy Version Data,
• Check and adjust settings for selection attributes regarding LOCATION and LOCATIONPRODUCT in Copy Operator Profiles for SAP7F Planning Areas

• In all planning filters for OBP application screens Location ID is expected to be the value of a dedicated location.
• That is: In no application the Location ID of a reference location (MRP Area Type Plant) can be used to select dependent MRP Area locations implicitly.
• The Job Template Real-Time Integration Reconciliation is the only exception to the above rule.
  • Demand or supply documents that cannot be integrated or created in an MRP Area due to missing set-up requirements are created in the respective reference location.
  • For this reason the RTI reconciliation job has to be performed across all MRP Areas for a given product.
  • Therefore, the Location ID field in the Real-Time Integration Reconciliation job template has to be filled with the Location ID of Reference Locations only.
  • The same applies to Location ID attributes in Planning Filters used in the Real-Time Integration Reconciliation job template

• Segment conditions in various tabs of the planning run profile Demand prioritization rule such as Demand Prioritization Rule, Switchable constraints, or Maximum lateness may include the location.
• MRP area locations need to be considered explicitly.
  • The new value MRP Area for the PlantType attribute of the location can be used for indirect selection of locations.
• Review any segment conditions that use locations (including ship-to and ship-from locations), their names, or their numbers.
• If location products (including ship-to and ship-from location products) have been selected by attributes such as MRP controller, subnetwork, or source of supply selection profile, you may also need to adapt the selection.
• Note that a product in an MRP area location can be assigned to different attribute values than the same product in the reference location.

Master Data Type LOCATION:

• Do not (!) change location attribute values sourced from RTI in case of Plant Types Plant (PL), Distribution Center (DC), and MRP Area (MR).
• In particular, this applies to the values of the attributes Plant Type, Reference Location, Production Calendar ID and Time Zone.
• All Storage Location MRP Areas (Plant Type MR) and the Plant MRP Area (Plant Types DC or PL) of a given plant must have
• the same Reference Location ID, which is the Location ID of the Plant MRP Area.
• the same Time Zone and the same Production Calendar in order to ensure date time consistency of the availability date between IBP and ERP backend
• Note that MD data checks will be applied in case you attempt to change the attributes Plant Type or Reference Location
• Note that attributes specifying geolocation data and address of MRP Areas are sourced via RTI from the default receiving storage location's data

Master Data Type LOCATIONPRODUCT:

Location Product attributes sourced via RTI:

Most of these location product attribute values are distributed from the material master to all location products of the same reference location without the option to have MRP Area specific settings in the MRP Area View of the Material Master.

• Examples: Procurement Type, Goods Receipt Processing Time
• Exceptions: The location product attributes MRP Controller, Planned Delivery Time, and Safety Stock are integrated specifically for MRP Area Locations if they are maintained in the MRP Area View of the material master.
• Refrain from overwriting RTI sourced attributes on the IBP side. In particular, GR Processing Time is not suited for changes on IBP side and should be uniform across all MRP areas of the same plant.
• IBP specific Location Product attributes not sourced via RTI:

Just like in case of the reference location these attribute values have to be maintained from the IBP side for all MRP Area locations

• Typical examples: Subnetwork, profiles such as Forecast Consumption Profile, Freeze Horizons.
• These attributes can be used for specific parametrization of location products MRP Area locations.
• You may set up MD Rules for automated derivation from reference location or other sources if necessary
• However, location related attributes such as Inbound Calendar or Shipping Calendar should not be specific to MRP areas, as the MRP area use case is not designed for distant MRP Areas.

Other Master Data Types that depend on Location or Location Product

• There are many more master data types that depend on Location or Location Product, for which MRP Area specific attribute values can be set, most prominently the source of supply master data such as Production Data Structure and Transportation Lane and the respective dependent MDTs.
• One should refrain from overwriting attribute values which are integrated via RTI like in the case of location products.
• Example: The common WorkCenter Resource or its capacity consumption should not be changed for a PDS that is used in an MRP area. It might be based on a production version w/o a receiving storage location which is multiplied into multiple MRP Area locations using consuming the same WorkCenter Resource. If capacity has to be split by MRP Area, specific workcenters should be modelled for production versions with specific storage locations on the ERP side.
• Common vs. specific values per MRP Area have to be reviewed and maintained in case of attributes not sourced via RTI like in the case of location products.
• For such attributes you may set up MD Rules for automated derivation from reference location or other sources if necessary
• Specific values per MRP Area should be maintained with care. For example, MRP area specific inbound calendars or receiving calendars are not recommended like in the case of location product while PDS or TLANE Priorities might make sense for differentiation across MRP Areas.
• If MRP area specific resources or equipment which are not integrated from RTI and used in MRP Area Locations such as MultiPurpose Resources, Transportation Resources, Production Resources that are not Workcenter Resources or TLB Equipment these master data have to be created upfront and their usage parameters have to be maintained for all sources of supply accordingly.
• Further Master Data Types beyond sources of supply such as LOCATIONPRODUCTSUBST must be maintained and reviewed for each MRP Area Location individually

Maintaining MDT related to LOCATION, LOCATIONPRODUCT, SOURCE of SUPPLY and other dependent MDTs via BAdI

• BAdIs are often used to generate, enrich, or adapt Master Data entries via RTI, rather than maintaining them in IBP.
• In particular, BADIs for the MDTs for LOCATION, LOCATIONPRODUCT, PDS, TLANE and other dependent MDTs might already be in use before adopting MRP Areas in IBP or are planned for first-time use or change in future .
• These BAdIs might include parameters, conditions, or data sources that relate to location information on a data model or level data entry level. Such relations have to be reviewed and adapted before and while using MRP Area functionality in IBP.

• There are many key figures and attributes key figures that are input to planning runs
• Without MRP Area Locations the key figure values use to be related to the Reference Locations (Plant MRP Areas) only.
• Mostly, key figures are inputs to planning runs but there are also key figures and alerts for an analytical follow up.
• With MRP Area use, there will be additional MDT entries regarding MRP Area Locations, for which these which these key figures have to be maintained and calculated as well.
• Often times key figure values will be split across the MRP Area dimension of a given planning level and key figure, so often times not only manual maintenance results have to be reviewed but also calculation rules have to be revised as well in Planning Area set-up.
• Review, maintain, and re-calculate key figures and attributes as key figures
• Mainly, reduce existing values in the reference location, split values across MTP Area locations accordingly.
• Most importantly, review your E2E forecasting process and split forecast to the additional MRP Area locations appropriately, before scheduling Supply Runs.
• Also, watch out for input key figures in use such as:
  • ALLOCATIONADJ
  • INTDISTRDEMANDLANE / INTDISTRRECEIPTLANE / INTDISTRDEMANDLANEDEPL / INTDISTRRECEIPTLANEDEPL
  • INTPRODRECEIPTPDS
  • MAX/MINDISTRDEMANDTLANE / MAX/MINDISTRRECEIPTTLANE / MAX/MINPRODRECEIPTPDS
  • MAX/MINPDSQUOTA / MAX/MINTLANEQUOTA
• Also, watch out for attributes as key figures in use such as:
  • EQTYPELIMIT
  • FCSTCONSHELPER
  • SAFETYSTOCKMD

• Both, MRP Area and corresponding MRP-Area-Material must always be added to the same integration model
• When you add a MRP Area-Material combination to an integration model where the corresponding master and transactional data had already been integrated with respect to the reference location before:
  1. Delete (mark for deletion) previously integrated PDS from IBP that based on the ERP setting should belong to a specific MRP Area, but before MRP area integration were integrated on plant level
  2. Reactivate the corresponding integration models for PDS and transactional data
     • With that the PDS and the transactional data will be recreated/reassigned to the right locations

  3. Perform reconciliation for stock
  4. Adapt the set-up and parametrization of OBP Plans as described above
• When you remove an MRP Area-Material combination from an integration model, but the integration of the material on plant level to which the MRP Area is assigned to still remains:
  1. Delete PDS and TLANEs which were previously integrated to the MRP Area location
  2. Reactivate the corresponding integration models for PDS and transactional data
     • With that the PDS and the transactional data will be recreated/reassigned to the reference location of the MRP Area

  3. Perform reconciliation for stock
  4. Adapt the set-up and parametrization of OBP Plans as described above

• Changes to the MRP Area Definition may include
• Adding or removing a storage location
• Changing the receiving storage location
• In case of adding or removing a storage location:
  1. Reactivate all Master and Transactional Data integration models that might be impacted by the change
     • With that the PDS and the transactional data will be recreated/reassigned to the right locations

  2. Perform reconciliation for stock
• In case changing the receiving storage location planned receipts will be subject to a change of defaulting during RTI transactional outbound w/o a need for realignment.
• We recommend to use a systematic split of integration models, that prepares best for such changes, so the affected integration models can be identified easily and integration models have been generated without overlaps in the first place

• If you remove a material from an MRP Area in the material master, any master data and transactional data transfer will no longer consider the MRP area during integration and fall back to the reference location.
• Follow-up as follows:
  1. Remove the MRP Area-Material combination from the integration model

     Use the option "log deactivated material master" in transaction CFM2 so change pointers are created in order to set the deletion flag for the affected MRP Area location products.

  2. Perform reconciliation to delete all transactional data from SAP IBP that refers to this location-product combination
  3. Delete all master data from SAP IBP that refers to this location-product combination
  4. Trigger initial data transfer for all corresponding master and transactional data so they are created on the plant location instead of the MRP Area
  5. Adapt the set-up and parametrization of OBP Plans as described above

• If you change storage location information
• in any master data i.e.:
  • Material master
  • Bill of Material
  • Production Version
• labelled as
  • issuing storage location
  • receiving storage location
  • production storage location
• or change material master fields related to storage location handling such as
  • MRP Group
  • special procurement key for components
• Follow-up as follows:
  1. Delete obsolete PDS in IBP
  2. Retransfer all corresponding Production Versions to IBP

• Production Data Structures
• Material Settings are not considered on MRP Area level (e.g. MRP Group of an MRP Area location product)
• Phantom related production storage location determination strategies for components are not supported, i.e. strategies 5, 6, 7
• Transportation Lanes
• Only transportation lanes from plants to MRP Areas are integrated via RTI based on Special Procurement Keys
• Any transportation lane from and to an MRP Area location can be created in IBP flexible master data management or via BAdI, but it must be ensured that no circular supply chain relationships are modelled.
• Subcontracting: Component provisioning transportation lanes from MRP Areas to subcontracting vendors are not generated via RTI, as multiple ordering locations are not supported in subcontracting
• MRP Area locations and dependent master data are not yet shown in the Supply Chain Network application
• Production Planning Integration (also known as Synchronized Planning for Production) is not yet released.

SAP Notes:

https://me.sap.com/notes/3547103

WhatsNew

SAP IBP 2502: Support of MRP Areas in Order-Based Planning:

SAP Help

• Integrating Production Data Structures at MRP Area Locations:
• Integrating Components at MRP Areas: