Supply Planning Master Data in HPA

Products are produced, transported, and stored in the supply chain network.

The product is similar to the location, as this is also a simple master data type. Most attributes are commonly used.

For example, there is an attribute Product Group. However, certain attributes might also be application-specific, such as the Product Type attribute for OBP.

This is a compound master data type. It is one of the most important master data types and has the most attributes. The attributes describe the properties of the combination of location and product.

For the location product, there are also common attributes, and they are aligned. The planner attribute is an example of a common (core) attribute used by all applications. There are also some application-specific attributes.

For example, in the OBP application, lot-sizing strategies or procedures are not supported, whereas the time-series algorithms do. Therefore, this attribute, which defines the lot sizing strategy or procedure, is application-specific.

Examples of several application-specific attributes of Location Product are demonstrated in the figure below.

There have been changes from a distribution perspective in the Harmonized Planning Area. The main master data object will be the I_TLANEPRODUCT in the data model, serving as the main master data for modelling lanes.

The master data type I_TLANEPRODUCT uses LOCFR - LOCTO and is absolute, not directional.

Reference Master Data Types (I_TLANEUPSTEAM and I_TLANEDOWNSTREAM) and Virtual Master Data are utilized at the planning levels. As a result, Upstream and Downstream Key Figures can be generated.

The benefit of this model is the ability to combine information defined at the planning level using I_LOCID in a single view or in key figure calculations.

An attribute I_TLANETYPE will define whether T-Lane is a Subcontracting (3), Consignment (2), Stock transfer (7) or a Purchasing (0) T-Lane.

The keys for I_TLANEPRODUCT are the I_PRDID, I_LOCFRID, I_LOCTOID, and I_MOTID. A generic subkey, the I_ADDLANEID, is added to enable additional details, including contracts, scheduling agreements, and purchase information records.

There is an extension to the T-Lane regarding product validity.

The upper object I_TLANEPRODUCT defines the validity of the T-lane itself for the entire horizon. Within the Master Data Type I_TLANEPRODUCTVALIDITY, you can model seasonality (specifying for certain parts of the year which T-Lanes are valid). This is supported from release 2605.

From a data modelling perspective, the main master data objects are I_TLANEPRODUCT, I_TLANEPRODUCTVALIDITY, and I_TLANEPRODUCTRESOURCE.

The I_TLANEPRODUCTRESOURCE allows you to model transportation resources.

You can assign different transportation resources to a specific lane, along with their capacity consumption rates. This is now modelled via I_CAPACONSLNRESDENOMINATOR and I_CAPACONSLNRESNUMERATOR, a change compared to SAPIBP1.

The data model is an extended production model for time series and order-based data. It allows it to extend the core data model (product direction) to model additional outputs: coproducts, by-products, and output location. It also has an extension for PDS header validities; you can define multiple validities. It also introduces the use of activity type = 'P'. The component input and the resource consumption can be defined within each activity. This new production data model enables additional features that will come in the future, such as planned production resource substitution (also known as alternate resources), characteristic-based planning, in-order-based planning, and shelf life planning in-order-based planning.

This is how the entity relationship diagram looks in the production data model.

The PDS Header is at its core.

It defines the PDS, the key, and groups bill of material activities, resource consumption, and all the relevant information.

Here, the key is a single key I_PDSID, unlike in SAP7F, which had a production version, product ID, and location ID -> a total of three keys, and time series supply planning, which also had source ID, product ID, and LOCID as keys.

The I_PDSID is a 60-character field. It is generated via the RTI by concatenating the Product, Location, and Production Version.

The PDS Activity has been there for order-based planning. Still, it's new to time-series supply planning, which defines the sequence of activities, their resource consumption, and duration. Note, only linear activity networks are supported. The leadtime is the sum of the activities' duration, and it is expressed in days.

From the 2508 release until now, only production activities have been supported. Only one output product is supported. The output is available at the end of the last activity.

The remaining two main parts of the production data model are:

• The Production Component (equal to the PDS item in planning area SAP7F or the Production Source Item in time series supply) comprises the input components.
• The assignment of the resource to the PDS activity.
  • The capacity consumption of a particular activity is defined in this master data type.
  • The PDS Resource specifies that an Activity ID is an additional key, as compared to SAPIBP1
  • You can specify the same resource if it's consumed multiple times at different activities, which was a limitation in the time series.

As part of product direction, to model coproducts and by-products, additional master data, PDS Additional Output, will be used.

HPA supports the following procurement processes:

The first is the unspecified purchasing. It involves an unspecified purchasing source of supply. In the current time series supply in SAP IBP, it is referred to as anonymous procurement or the U rule.

The harmonized planning area has dedicated master data (Unspecified Purchasing) to model U rules. Unspecified Purchasing Source of Supply is not supported by OBP.

In unspecified purchasing, you can define your Product ID, Location ID, and different attributes, including lot sizes and freeze horizon validities.

There are also validities if they are relevant. As per product direction, the source of supply validity will become available from release 2605.

In time-series supply, multi-stage purchasing is supported.

Unspecified purchasing will apply to any node in your network, similar to today's time series, and will function in the same way

So, you can specify an unspecified purchasing rule, whether it's any location, plant, vendor, supplier, or DC.

A single-tier vendor modelling is depicted in the figure below.

Single-tier vendor modelling assumes a production plant and a vendor. Currently, this is what we call a simplified model. The reason for being simplified is that it doesn't have any location products at the vendor location.

This type of model is integrated today via RTI. It might be one-on-one with how ERP looks. In SAP IBP, it allows to plan only the supplies created on the lane; no planning happens at the vendor location, i.e. in terms of the location product level, no supplies are created.

The presence of location products at the vendor location, and the unspecified purchasing source of supply, define it as a fully qualified model.

In the future, there will be a switch in RTI that will enable you to create vendor products, master data, and unspecified purchasing, all through RTI. The BAdI implementation is needed to avoid ambiguity when two locations are sourced by the same vendor. Only the left side, a single-tier simplified model, is supported from release 2508.

A multi-tier vendor model is depicted in the figure below.

A multi-tier situation occurs when several tiers of vendors are modelled.

It allows for modelling arbitrarily deep multi-tier vendors.

A multi-tier simplified model means that the supply chain ends with vendor V0, which doesn't have a location, product, or an unspecified purchasing source of supply.

In this case, the simplified master data V1/P1 (vendor location product) must be created.

This additional master data must be created via CI or RTI (RTI supports only the first tier), and an additional lane must be created from the first-tier vendor V1 to the second-tier vendor V0.

A multi-tier, fully qualified model requires the vendor product location and unspecified purchasing for the last tier.