How to Use GATP Allocations for Supplier Capacity Modeling
Executive Summary
- SAP GATP can be used to model supplier capacity with allocations.
- There are many disadvantages to performing supplier capacity modeling in SNP.
- In this article, we will cover the GATP background and how to set up applications in GATP.
Introduction
The ability to model supplier capacities is a common request from companies. This can be a desire to model ordinary suppliers, but also third-party order processing (where the company takes the sales order, but the demand is satisfied entirely by a different company), as well as subcontracting (where the company provides an input product to the subcontractor and receives a processed item in return).
In SAP APO, the standard design to accomplish this objective is to model master data objects such as the BOM, routing, and resource of the supplier inside of a supplier location in SAP APO. In the past, this has been modeled with a PPM, but new developments in APO appear to allow this to be modeled with the more modern PDS object. For more on both of these master data objects, see this article.
Disadvantages to the “Standard Approach”
The problem with this standard approach is that it creates a lot of overhead. Companies have enough problems keeping their resources up to date, and secondly, the effort required to set up this design greatly limits how many suppliers can be modeled.
Typically the company goes down the pathway and then realizes how difficult it is after the fact. The overall maintenance becomes un-wieldy, and this part of the implementation stops being used. However, it is not the only option for modeling supplier capacity.
Emulating Supplier Capacity with GATP
Supplier capacity can be emulated with GATP through the use of allocations. Allocations stop a sales order from being accepted or from being confirmed if it is over the allocation. Allocations are much easier to set up than all master data objects necessary to configure for SNP and PP/DS. Therefore, it allows many more suppliers to be “modeled” in the planning application and makes the overall supplier modeling process much more sustainable. This sustainability issue is quite important because most companies that I have seen attempting supplier capacity modeling with the “standard approach” fail to pull it off successfully. SAP APO does make the standard approach possible, and will often write it up as a way to design the supplier modeling solution, but leave out how difficult the process is, and do nothing to make the management of the master data objects in APO easier to maintain.
SAP attempted to move supplier collaboration to a parent or combined master data object called the PDS, which became even more difficult to maintain than the PPM. I don’t need to get too much into these objects except to say they are a major overhead.
Now even much easier to use applications that SAP APO updating this information takes a lot of work. However, SAP has its unusual overhead, which makes the maintenance even more problematic.
To understand how this is done, let us review some important aspects of GATP to begin.
GATP Background
GATP has the following unusual characteristics:
- CIF synchronizes the data between SAP ERP and GATP in near real-time.
- The ATP check is performed in ERP when GATP is not available.
- GATP integrates closely with supply planning for the order fulfillment process and commits to customer’s orders based on the input information provided by the supply planning receipt elements.
There are four workflows, which connect supply planning or SNP to GATP:
- (GATP Check) ATP quantity (developed from inventory or MPS)
- (GATP Check) Sourcing (based upon product/location substitution – that is, GATP checks procurement for itself in a way that is not part of the supply plan)
- (GATP Check) Allocations management
- (GATP Check) Supply plan (daily/weekly MRP run)
However, the allocations we are thinking of creating are not connected to SNP. If we placed the resources and PPMs/PDSs into SNP, we would rely upon SNP to tell GATP what can plan to be available. However, this design has GATP working off of allocations entered into the system that primarily serves as a proxy for the suppliers’ resources.
This gets into the next topic: setting up allocations in GATP and how they are assigned to the product location combination.
Setting up Allocations in GATP
Allocations are set up in GATP. Some of the pathways for doing this are listed below:
IMG => Advanced Planning and Optimization => Global Available to Promise => Product Allocation => Maintain Sequence of Product Allocation Procedure
IMG => Advanced Planning and Optimization => Global Available to Promise => Product Allocation => Maintain Connection to Planning
More detail will be added on how to create allocations in GATP when time allows…
After the allocations are created, they are then assigned to the product location combination in the
The ATP Tab
ATP tab which is shown below:
The field definitions are as follows:
1: “Product Allocations: The product allocation procedure determines how a product in limited supply is allocated to (sales) orders.
2: Location-Dependent Product Allocation Procedure: The product allocations procedure determines how a product in limited supply is allocated to sales orders.
3: Sequence of Product Alloc. Procedures (Location-Dependent): Via a sequence of product allocation procedures, several product allocation procedures are grouped into a specific sequence.
4: ATP: Checking Horizon in Days: Defines a time interval (checking date + period) in which a product availability check can be carried out. If the requirement date lies within this time interval, the check is carried out. Requirements that lie beyond the checking horizon are not checked (for more information, see Consider Checking Horizon). You can display the replenishment lead-time, for example, using the checking horizon.
5: ATP: Horizon for Recreating Receipts in Calendar Days: Defines a time period behind which receipt elements, created via Capable-to-Promise (CTP) or via a conversion of the ATP tree structure (after a multilevel ATP check) in the order network of the SAP liveCache, are ignored in during a new ATP check. You have already performed CTP processing or a conversion of the ATP tree structure (after a multilevel ATP check) and change the sales order in SAP R/3 (SD), for example. If the requirements date (material availability date) is later than the end of the horizon.
6: ATP Group: The ATP group contains a number of settings for the product availability check and corresponds to the checking group in R/3. The checking group is transferred to the location-specific APO product master (ATP tab page) as the ATP group via the APO Core Interface.
7: Parameter-Dependent ATP Safety Stock Indicator: Enables calculation of the parameter-dependent ATP safety stock (PASS) for this location product.” – SAP Help
Conclusion
The standard approach to modeling supplier capacity in SAP APO has a high failure rate because it is too much maintenance and complexity for the vast majority of companies to tolerate.
SAP does little to address this fact except to tell companies to use the same approach that many companies have had problems implementing. A lower maintenance approach is required, and I would say recommended for capacity constraining suppliers. One exists in APO, but it exists in GATP rather than in SNP / PP/DS. This method is rarely discussed, but it requires that an allocation is placed on a product location.
This presentation illustrates the problems with SAP support and how Brightwork SAP Support addresses these shortcomings.
What Kind of Support is This?
If this does not sound like standard support, you are right. And that is the point.
We designed our support to help our customers get the most out of SAP, not maximize our margin or try to protect previous sales inaccuracies. We know how to get your SAP applications working better.
To see the broader information about our SAP support, see our main SAP Support Page.
References
SAP Help