APO doesn’t use standard tables.

That is not true, of course, but is what a person from the ECC/R3 world may think when trying to extract information directly from tables in APO. APO can be very confusing and I hope that I don’t make it more confusing by trying to explain the situation in this post.

In my view, there are two main reasons why APO direct access to data is perplexing from the ECC perspective:

Use of internal ID codes

ECC tables use the object name as the table key and as link to other tables.

For the material tables the key is the material number and for production orders tables, the order number.

APO changes this approach and assigns internally an ID with a cryptic combination of 22 characters with no real world meaning and challenging to dictate. Here is one I made before (0CyjdOvAfKcdDzTgZlF1Y0).

This makes the ID quite unique, that is a good idea considering that APO can aggregate multiple ECC and external system that may have the bad luck of choosing the same number for different things.

If you manage to find that the table holding the material information at the plant level (/SAPAPO/MATLOC) you may be surprised to find out that it doesn’t include as fields the material or the plant (product and location in APO’s terminology). Instead it have IDs that needs to be referenced to other tables in order to get the usual material and plant numbers.

Equipped with this knowledge it becomes possible to build a query to display the equivalent to ECC’s MARC table in APO by linking /SAPAPO/MATLOC to the product table (/SAPAPO/MATKEY) and the location table (/SAPAPO/LOC) as shown below.

This is painful but doable, until you start looking for transactional data - for example the production order table.

Don’t waste your time, the table is not there. At least not as a standard table.

Tables in LiveCache

LiveCache is the precursor of HANA in the sense that data is stored in speedier memory rather than in slow to reach hard disks. I’m not going to bother you with the technical details of how it works, I will only say that accessing the data raises to a new level of pain.

Transactional data in APO is stored in LiveCache to give data intensive processes – like the optimized – a fighting chance to finish what they need to do in a workable amount of time. The time required to access a standard table would be prohibitive.

One way to access the data is to use functions calls. In my next blog I will be showing how to access and display information from the production order with an ABAP query.

One problem with the difficult access to the data in LiveCache is that the few tools SAP provide feel “bloated”.

This is the case of standard transactions like /SAPAPO/RRP4 or BAPIs like BAPI_MOSRVAPS_GETLIST2 that are designed to cater for many different needs to access data in LiveCache. For example, they may bring all kind of information that we don’t need but add extra checks and processing time to the run.

A query or program using more direct function calls can be much faster and efficient. After the information is transferred to internal tables, more complex calculations and checks can be archived.

So, to continue with the automotive simile, your car has not been stolen; it is just parked in a different level than the one you thought it was.

(This post was first published in my professional blog)

Integration Scenario for APO modules

                SCM APO is a planning tool which is used to plan and optimize supply chain processes in different business processes such as Demand Planning (DP), Supply Network Planning (SNP), Production Planning and Detailed Scheduling (PPDS), Global Available to Promise (GATP) and Transportation Planning & Vehicle Scheduling (TPVS).APODP is a set of functionalities around Demand Management, Statistical Forecasting, Promotion and Life-cycle Planning processes. It is an integral part of any organizations Sales & Operations Planning Process. APOSNP is a set of functionalities around Distribution Requirement Planning, Deployment, Demand and Supply Matching and Optimization. APO PPDS is a set of functionalities around In-house Production Planning, External Procurement Planning, Resource Scheduling and Sequence Optimization. APO GATP is a set of functions around Order Promising and Fulfilment checking across the whole supply chain. APO TPVS is used to plan, optimize, and execute the complete transportation process between companies in a detailed manner.

We started the integration scenario which consists of all the modules of SCM APO which are the DP, SNP, PPDS, GATP, and TPVS. Some specific scenarios were picked up in each module to demonstrate the end to end scenario. A team of 5, each module’s experts were chosen for the task. We got together and came up with a real time scenario for which the master data was created in ERP system. To set up a proper master data the team took help of one of the Partners. The core master data was built by the PPDS expert which would be used across modules. Accordingly the relevant master data was either built or some customizing changes were made to the existing master data. We took the example of a biscuit manufacturing company.

We had to spend time initially to choose a proper product and then to identify various requirements. Many trial and error methods were done while creating the master data which would be used across the modules. We used to have a short sync up meeting for half an hour every alternative day to check the status on the progress. We got to know the requirements of each module and also what used to happen in each module. For example DP, it used to take the DFUs and then get the forecasted data ready to be used for SNP. We had faced many issues while we were setting up the data. Initially we started with some set of master data and then we had to change a certain data due to which some of them had to bear the changes and adopt them in their respective module. Though there were so many issues all of them handled them in a smooth way and were successful in executing the scenario.

The key ingredients for the production of biscuit are flour, refined oil and sugar.  We also have packets of different sizes to pack the biscuits finally when they were ready. We have two plants located in Bangalore and Chennai. Each plant has three work centers for mixing, baking and packing. We have two distribution centers and two Regional distribution centers each located in Bangalore and Chennai and one customer. First of all the materials were built which were followed by creation of work centers, Bill of materials and routings. Work centers were given with some estimated duration according to the type of work center used. The mixing work center did the job of mixing the flour, refined oil and sugar in proper proportions as specified in the PDS which is the Production data structure. Then the mixture is baked to a certain time and under certain temperature with the help of ‘baking’ work centre. Once the biscuits are ready these are packed in different sized packets with the help of ‘packing’ work center.

1. Once the set up for the production of biscuit was ready, the manufacturer has to get to know how many packets of biscuits should be produced. So, demand planning (DP) was taken for this purpose wherein the historical data was extracted from the BW (Business Warehouse) system and a forecast data would be created with the help of Interactive planning. This forecast data is then released to SNP where a rough cut planning is performed with the help of some heuristic run. These SNP planned orders would be then picked up by PPDS and converted to PPDS planned orders which have all the details of the operations, activities, quantities and available dates. The orders are now re-scheduled using the DS planning board where a proper placement of orders is obtained. Simultaneously the sales orders (if any) from the customers are handled by GATP for which additional planning is performed. Once the plan is ready, the orders are sent for execution to the ERP system and the production takes place. Finally tasty biscuits are ready to eat

The whole Idea of building this integration scenario was to have a sanity check of all the modules and also test the integration points. An ecatt test script can be developed for this integration scenario and can be used for smoke test during the test phases so that it would save time and also the basic integration of all the modules would be tested.

We display production planning Heuristics Logs in APO using the transaction /SAPAPO/RRPLOG1 transaction. Review and analysis of heuristics logs is an important activity which helps planners rectify many errors and make sure that planning results are very accurate.

But one problem we encounter in standard SAP is that often the planning logs are confusing. These are not very user friendly and often planners get confused if they try to understand the exact reason of the errors and sometimes also when they try to attribute a particular log to a particular location-product. Often SAP Consultants try to search for means by which they could improve the heuristics logs in SAP APO. I am sharing some helpful information in this small article.

There are some SAP Notes which help to improve the MRP logs. For example, two SAP Notes are as follows:

----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------

SAP Note 1911427 - Improvements for the logging of the production planning run

Version 3 Validity: 16.10.2013 - active Language English

Header Data

Released On 21.10.2013 11:27:55

Release Status Released for Customer

Component SCM-APO-PPS Production Planning and Detailed Scheduling

Priority Correction with medium priority

Category Program error

Symptom

You use the production planning run. When you check its log information, you notice that some information is incomplete or not specific enough to identify the issue directly or to trace its cause directly. When you use parallelization in MRP planning runs, you also notice that log information is missing or cannot be directly assigned to a planning run in certain cases (for example, when triggered from process chains).

Other Terms

/SAPAPO/CDPSB0, /SAPAPO/BACKGROUND_SCHEDULING, MRP, material requirements planning

Reason and Prerequisites

In addition to functional gaps, the production planning run offers potential for optimization at certain points, which takes effect if it is not triggered directly from transaction /SAPAPO/CDPSB0 or the report /SAPAPO/BACKGROUND_SCHEDULING, for example.

Through the use of parallel processing during MRP runs in particular, the system splits datasets and processes them in parallel using separate tasks in order to optimize performance. Although the system writes logs within these tasks, specific information may become lost that is required to combine all relevant log data into one planning step for display purposes. This may give the impression that certain objects have not been planned or that problems with planning have not been identified.

Solution

Implement the attached correction instructions or import the Support Package relevant for your release.

The corrections in this SAP Note optimize the processes for creating, finding, and preparing logs in the context of planning runs.

----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------

SAP Note 1920820 - Improvements for the logging of the production planning run (2)

Version 3 Validity: 16.10.2013 - active Language English

Header Data

Released On 21.10.2013 11:37:28

Release Status Released for Customer

Component SCM-APO-PPS Production Planning and Detailed Scheduling

Priority Correction with medium priority

Category Program error

Symptom

You use the production planning run. When you check its log information, you notice that some information is incomplete or not specific enough to be able to directly assign the issue or to directly identify its cause. When you use the parallelization of or in MRP planning runs, you further observe under certain conditions (for example, when triggering it from process chains) that log information is missing or cannot be directly assigned to a planning run.

Other Terms

/SAPAPO/CDPSB0, /SAPAPO/BACKGROUND_SCHEDULING, MRP, material requirements planning

Reason and Prerequisites

The production planning run sometimes not only has functional gaps but also potential optimisation possibilities. These weaknesses make themselves felt if you do not use transaction /SAPAPO/CDPSB0 or the report /SAPAPO/BACKGROUND_SCHEDULING to directly trigger the production planning run.

Due to parallel processing during MRP runs in particular, the system splits datasets and processes them in parallel using separate tasks in order to optimize the performance. The system writes logs within these tasks, but specific information may get lost that are actually needed for display purposes and to be able to assemble any relevant log data to form one planning step. This may suggest that certain objects have not been planned, or problems with planning are not identified.

Solution

Implement the attached correction instructions or import the Support Package relevant for your release.

The corrections of this SAP Note optimize the processes of creating, searching, and editing logs in the context of planning runs.

------------------------------------------------------------------------

|Manual Pre-Implement. |

------------------------------------------------------------------------

|VALID FOR |

|Software Component SCMAPO |

| Release 713 Until SAPK-71302INSCMAPO |

------------------------------------------------------------------------

Before you can implement the corrections of this SAP Note, you need to carry out the following manual steps. You can procure the required modification keys on SAP Service Marketplace. For this, contact your system administrator.

<Text clipped; for details please check out the SAP Note on support.sap.com>

----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------

But you need to be aware that implementing these two SAP Notes may cause some system performance issues.

Are there any ways so as to implement these SAP Notes for improvements in planning logs and still avoid the performance issue? The answer is yes. To know “how” to do it, wait for the second part of this series. I shall also update this article with the link to the next part.

[Disclaimer: Written by Rahul. This article or post is written by the author based on his personal experience while working on SAP. Before implementing any solution you are advised to always do the analysis and adopt a solution only if it suits you and testing is successful.]

Next posts in the series:

Improvements in Production Planning Heuristics Logs in SAP APO (Part- 2/3)

Improvements in Production Planning Heuristics Logs in SAP APO (Part- 3/3)

This continues after Part-1: Improvements in Production Planning Heuristics Logs in SAP APO (Part- 1/3)

In Part-1 of this three part series, we discussed how we can make an improvement on the way production planning and scheduling heuristics logs appear in standard SAP APO (displayed through transaction /sapapo/rrplog1). SAP Notes 1911427 and 1920820 come to our help in that regard. But if we implement SAP Notes 1911427 and 1920820, these may cause some system performance issues. In this small piece we shall discuss how to overcome these system performance concerns.

In order to resolve or overcome these system performance issues, we need to implement following three SAP Notes.

--------------------------------------------------------------------

1. SAP Note# 1998968 - Update task hangs in program SAPLSENA

Version 3 Validity: 21.05.2014 - active Language English (Master)

Released On 21.05.2014 15:40:03

Release Status Released for Customer

Component BC-SRV-BAL Basis Application Log

Priority Correction with high priority

Category Program error

--------------------------------------------------------------------

2. SAP Note# 2025948 - Long processing times spent by waiting for an enqueue

Version 7 Validity: 05.11.2014 - active Language English (Master)

Released On 05.11.2014 08:54:34

Release Status Released for Customer

Component BC-SRV-BAL Basis Application Log

Priority Correction with high priority

Category Program error

--------------------------------------------------------------------

3. SAP Note# 2069753 - Infinite wait in program SAPLSENA

Version 2 Validity: 07.10.2014 - active Language English (Master)

Released On 16.10.2014 15:37:42

Release Status Released for Customer

Component BC-SRV-BAL Basis Application Log

Priority Correction with medium priority

Category Program error

--------------------------------------------------------------------

Please note that these SAP Notes are standard SAP Notes which will be delivered along with the support package.

So to summarize, the recommendation is that if you are implementing SAP Notes 1911427 and 1920820 for improvement in heuristics planning logs, also implement the following SAP Notes and prerequisite SAP Notes if any (depending on your system):

After going through the implementation and resolution of performance issues related to it, it will be good to see examples of how the improved logs should look like. I shall try to address that in Part-3 which will conclude this topic.

***

[Disclaimer: Written by K Rahul. This article or post is written by the author based on his personal experience while working on SAP. Before implementing any solution you are advised to always do the analysis as well as reach out to SAP in case needed and adopt a solution only if it suits you and testing is successful.]

Next post in the series:

Improvements in Production Planning Heuristics Logs in SAP APO (Part- 3/3)

Hello GATP colleagues,

In several occasions we are reported by an end-user that a specific Sales Orders confirmation changed, and wonder if that date or that quantity is actually right and where that confirmation came from.

As in most large companies than runs GATP, BackOrder Proessing (BOP) is part of the daily jobs, and there are big chances that BOP changed that order.

Due to the business requirements, BOP runs are split in multiple executions, then finding the run in which a specific Sales Order was changed can take some time. Transaction /SAPAPO/BOP_RESULT and /SAPAPO/BOP_MONITOR doesn't have a Selection field for Sales Orders, so this forces us to enter few BOP logs until finding the one we are looking for.

To help me with this I developed a Z report that uses a Sales Order number as input criteria, and find all the BOP runs in which that order was part of.

In case you are interested in seeing the code, you can find it in the attached file "ZBOP_ORDER_DISPLAY".

Here are some screenshots of the report:

1. The entry point of the report is the Sales Order selection field. Here you need to enter the Sales Order number, together with the leading zeroes:

2. After you run, the system will display
- BOP Job Name
- Date/time executed

- User who ran the job

- Filter type/variant

- Status of the BOP run and sorting used

Based on this information, we can go to /SAPAPO/BOP_MONITOR and specifically select the BOP run we would like to analyze.

I think this report still have room for improvement, and I appreciate if you implement and check it since there is no risk with this report since it is read-only and does not change any information in the system.

Every suggestion is also highly appreciated to improve the tool.

This continues after

Improvements in Production Planning Heuristics Logs in SAP APO (Part- 1/3)

Improvements in Production Planning Heuristics Logs in SAP APO (Part- 2/3)

In this series we see how to improve production planning heuristics logs. In part-1 and 2 we discussed how to make the improvements and how to resolve a system performance issue which may result from it. In this concluding part, we shall see some examples of it using screenshots from SCM 7.0. You can note that the actual screenshots may vary in your system depending on your configurations and may not exactly match this.

In my SAP APO system, before implementation of this improvement, the planning logs appeared like below in this step. As you can notice, it is short and there is lack of details:

After the improvement changes, the same logs appear like below:

Now, the logs show step-wise details of the sequential processing being carried out.

Some more screenshots:

What I readily observed during testing is that the level of details in the logs improved drastically. I would suggest that you can first implement the changes in testing system and test extensively and observe what kinds of improvements are made by the changes and then make a decision about whether you need the more level of details or not.

[Disclaimer: Written by K Rahul. This article or post is written by the author based on his personal experience while working on SAP. Before implementing any solution you are advised to always do the analysis as well as reach out to SAP in case needed and adopt a solution only if it suits you and testing is successful.]

I was looking at the DB procedure call APS_ORDER_GET_DATA in one of the gATP FMs /SAPAPO/OM_ORDER_GET_DATA to understand a bit more on the architecture. The above DB procedure simply fetches the data from the Live Cache. But, how does it do ? It makes a connection to your LC server and executes the above mentioned DB procedure in the LC to fetch the data from the memory. My understanding is this DB procedure would execute set of Native SQL scripts that can manipulate the data within the LC memory and give the results back to you. I was trying to look for some SAP notes if there is any tool that can trace the code in it. But, I couldn’t find any. (You’re welcome to share if you know….).  Now, the point is this looks close to what SAP is offering with AMDP (ABAP Managed Database Procedures ) on HANA. With AMDP, you can write your own DB procedures to run on that little XS server i.e., tightly coupled with HANA DB. Not sure if we will be able to manipulate the standard DB procedures using some “exits" in the future. The concept as such tells me that LC processing is one of the predecessors of HANA as it uses the in-memory processing engine. Just my thoughts !!

SAP software provides excellent planning functions and capabilities. But before you can effectively use them one must define the planning horizons... some people, as I have seen often, do not necessarily mind if they're in the long, middle or short term for what transactions and tasks they perform.

As an example, it might happen that a scheduler turns a planned order into a production order several weeks or even months before production of that order starts. Or the forecast is worked by the MRP Run (and subsequently planned orders are generated) way beyond the short or even middle term.

At my current client, we have worked on a definition and rule set for planning, which I would like to share with you, so you may use it as a frame of reference if you find it useful.

Below graphic summarizes the concept and it must be said that there are two major rules valid in any planning system:

Rule of Planning #1: "There is a point in time after which planning activities end". This point in time is not today! It comes before today, exactly at the point where the frozen zone begins. Once you're in the frozen zone you are working with production orders. And production orders are supply elements that we are not planning with anymore. we're expediting on them, reschedule them, re-route operations to different work stations and react to exception messages they received from the MRP Run when actual results differ from the plan. If you find yourself looking for a tool to automatically re-assign and re-schedule within the frozen zone you either don't have a frozen zone or you're under the wrong assumption that the planning system should not only 'plan' but also fix deviations from the plan. These deviations are due to variability. And variability can only be buffered but not be planned. Especially not after it occurs.

Rule of Planning #2: "To plan your resources in the mid and long term level and manage demand - To plan your resources and sequence in the short term level, schedule and manage supply". It doesn't make sense to reshuffle planned orders in the long term. You shouldn't have any in the first place. In the long term you are working in SOP and therefore with a planning hierarchy, monthly demand figures and SOP orders that cause rough capacity requirements (and not detailed capacity requirements). In SOP you move the demand so that capacity violations are resolved. In the mid-term you should work with Long Term Planning (LTP) and its Planning Scenarios. A Planning Scenario contains a demand program which you can simulate (with simulated planned orders) for mid-term capacity planning. Here you should also work with the demand program until you find one that generates simulated planned orders which fit into your available capacity program. That is then the demand program (Planning Scenario) that you activate into the short term. Now you can run MRP on those Planned Independent Requirements and the resulting planned orders can be sequenced, leveled and scheduled in capacity planning. The latter activity was 'managing and scheduling supply' whereas the previous activities were concerned with 'leveling demand'

Those two rules we have persistently respected and followed in our efforts to build a standardized and integrated planning system everyone in the organization is using and looking at for continuous improvements.

The sales planners enter their forecast into product groups within a planning hierarchy. SOP Orders, statistical work centers and rough cut planning profiles are used to analyze the capacity situation for a horizon of 18 months out up to 5 years. Should we encounter a problem, we're moving the entire product group demand into a previous, less capacity constrained period or fill out a request for more capital expenditure to increase capacity and meet increasing customer demand.

When the leveled demand is dis-aggregated from the product group level to the actual product, we then transfer the demand profile into Long Term Planning (LTP) where we simulate various demand programs and generate stimulative supply. Requirements are determined for long lead time items and the procurement process is started if necessary. During Phase 1 of the mid term - 12 months to 18 months out in this example - we let demand changes from the SOP flow in and integrate these into the demand programs. In Phase 2 of the mid term, we perform detailed capacity planning with stimulative planned orders and find the best demand program that fits into our available capacity.

The activation of the demand program (transfer of Planned Independent Requirements into MRP) indicates the move from the mid term to the short term planning horizon. After MRP is run, planned orders are generated which we can sequence, level and schedule within available capacity on the bottleneck work center.

The last planning activity then is to take all leveled and sequenced planned orders of, say, one week and perform a collective material availability check. Now you have ensured that all materials and the capacity is available for all the orders to be executed and you are ready to move these orders into the frozen zone. This is done by collectively converting the planned orders into production orders for the next week. From then on - within the frozen zone and into backorder scheduling - all planning has stopped. Anything that happens against the plan needs to be adjusted manually. If a work center is down, an alternative work center will have to be found and the sequence in the work order changed manually.

This last point is especially important as I often get asked if one can automate this function. But in my personal opinion this is an impossible proposition. To actually do so one would have to build all possible cures to an exception into the basic data (production versions, alternative BoMs or routings, etc) and you can not possible do that. It is much better to have someone who is close to the exceptional situation pick an alternative and just change it into the order.

...after all, that is the whole reason why we';re comparing 'actuals' to the 'schedule' and the 'plan'

PPM (Production Process Model) and PDS (Production Data Structure) are both SAP APO relevant master data. In most of the situations we have either of these in APO unless due to specific business requirement you can have both. Sometimes due to specific business needs, you need to make a switch from one to the other (though it will be elaborate process). Sometimes for specific testing, you may like to change the setting from PPM explosion to PDS explosion while APO system creates orders; or the vice versa. Due to these reasons it is important to know the configuration which ultimately decides whether PPM will be exploded or PDS will be used while order creation. In below section we discuss the simply steps in which the configuration is done.

In SPRO customization, use the below path to navigate:

SAP – Implementation Guide -> Advanced Planning and Optimization -> Supply Chain Planning ->Production Planning and Detailed Scheduling (PP/DS) -> Global Settings -> Maintain Global Parameters and Defaults

When you go to ‘Maintain Global Parameters and Defaults’ screen, you can go into edit mode and look at the drop down menu corresponding to the field ‘Plan Explosion’:

Here, you can choose ‘Explode Production Process Model’ if you want PPM to be used or else choose ‘Production Data Structure Generated from R/3’ if you want to use PDS. Make the selection and choose ‘Save’.

After customizing is done, it is important to know that there is one more place where the same setting is done. It is location product master in APO.

Go to location product master using transaction /SAPAPO/MAT1; input the product and location numbers and go to ‘PP/DS’ tab. Look for the field ‘Plan Explosion’. Go into edit mode and display the available options.

If you want to use PPM, select ‘2’ and if you want to use PDS, select ‘5’.

If you leave this field blank in the location product master, the default value as specified in the customizing (discussed before) will be used.

I hope now you have fair idea how it is decided whether PPM or PDS will be used during plan explosion in APO.

If you have any further queries, do let me know using comments.

[Disclaimer: Written by K Rahul. This article or post is written by the author based on his personal experience while working on SAP. Before implementing any solution you are advised to always do the analysis as well as reach out to SAP in case needed and adopt a solution only if it suits you and testing is successful.]

In short: recently, a correction note was created to improve performance of PPM explosion when orders are created in PP/DS. Due to a side effect of this note, some errors may occur:

• Upon running the Product Heuristic, operation descriptions are missing for new orders
• Upon running the Product Heuristic, message "Order not created for product" is raised
• Upon trying to convert multiple SNP PlOrd to PP/DS PlOrd, error message "The order has no activities", the the orders are not converted
• During /SAPAPO/CCR reconciliation, if multiple PlOrd are sent to APO, the queues get stuck with error "Plan AAAA not valid for Product BBBB at time MM.DD.YYYY"
  

These issues can be solved by applying note below:

2149211 /SAPAPO/RRP3: Error when PPM read buffer during order creation

Hi All,

It is expected that when an production version is locked in ECC, then its PDS is to be deleted in APO. But so far we have a note 854561 that provides a work around solution, by setting the procurement priority of a locked PDS to 555555... and then this value is filtered during source determination.  From business point of view it makes no difference whether the PDS does not exist anymore (i.e. was deleted) or is just filtered (was locked). Some time the PDS will not be used anymore by existing orders, so some time the deletion will work eventually.

There are 2 new notes 2167226 and 2167228, which actually make use of a lock indicator  It works exactly the same way as note 854561, but a) is part of standard and b) use an appropriate field (no misuse of procurement priority).

So if you face issues in deletion of locked production version then please implement these notes

2167226

2167228

Thanks

Gomathi

SAP provides a lot of standard heuristics for planning under APO Production Planning and Detailed Scheduling module. But you have an option to create your own heuristics. In this blog post we shall quickly go through the process of how to create your own custom heuristics.

In APO either go to transaction /sapapo/cdpsc11 directly or else go through following path:

Advance Planner and Optimization --> Supply Chain Planning --> Production Planning and Detailed Scheduling (PP/DS) --> Heuristics --> Maintain Heuristics

It will show you the standard heuristics list.

Click on “New Entries” button. It will open a new screen for you where you can maintain lots of details as follows:

In the “Other Heuristics” field you can select from the available options as follows depending on the business need:

“Reuse mode” has following options:

The field “Degree of Fineness for Run time Statistics” is the value that defines for which products the system records an entry in the runtime statistics when planning with the heuristic. An entry is made for each multiple of this value.

You can use the custom heuristics along with all the settings available on the screen for your advantage depending on the business case. For example, top down Heuristics or the other way round depending on the business case.

- Rahul

1. Live cache consistency check

Here we create a process variant to do livecache consistency check; this variant can then be used in the background job.

To Access the activity, use one of the following navigation options:

1) SAP Menu: Advanced Planning and Optimization® APO Administration  ® Consistency Checks ® LiveCache Consistency Check

2) TCode: /SAPAPO/OM17

3) On the Consistency Check LC – APO DB (Preparation) – Client 100 screen, choose Consistency Check liveCache – APO DB.

4) On the dialog box Caution window, choose Continue.

5) On the Consistency Match liveCache – APO Database screen, make the following selections and entries as highlighted in the screenshot (select as many entries as per requirement):

6) Choose Save.

7) In the Variant Attributes window, enter the following values as per screenshot:

8) Choose Save.

9) Choose Go back.The variant for consistency check has been created, and can be used for background job run.

<To be continued>

In standard, when running a Product Heuristic like SAP_PP_002, shortages inside the PP/DS Horizon are planned even if the PP/DS Horizon is set to 0 days.

I've come across a few customers who would prefer to have the Location-Product filtered out from the heuristic execution and/or planning run in this scenario, therefore I created a sample code to be used in BAdI /SAPAPO/RRP_HEUR_DO, Method BEFORE.

While this is not a standard solution, it can easily be implemented, tested, and adjusted to suit your requirements.

Example:

Today is 13.02.2016.

PP/DS Horizon has been set to '0' for Planning Version TEST in /SAPAPO/MVM and for Product FERT at Location 0001 in /SAPAPO/MAT1.

It ends on 12.02.2013 23:59:59.

There is a forecast within the PP/DS Horizon, in the past:

Once Planning of Standard Lots is executed, a Planned Order is created, as early as possible, to cover it:

Template below excludes from the pegging areas to be planned those for which the PP/DS Horizon ends before or at the current date and time, when the heuristic to be executed is a Product Heuristic (SAP_PP_002, SAP_PP_003, etc):

method /SAPAPO/IF_EX_RRP_HEUR_DO~BEFORE.

     DATA: ls_pegid     TYPE /SAPAPO/OM_PEGID,

           ppds_horizon TYPE TIMESTAMP,

           lv_now       TYPE TIMESTAMP.

    " The BAdI only affects heuristics which can be marked as Product Heuristic  

     CHECK i_heurfunc-prod_heur IS NOT INITIAL.

     LOOP AT i_object_keys-pegid_tab into ls_pegid.

       CALL FUNCTION '/SAPAPO/DM_PEGID_GET_MATERIAL'

         EXPORTING

           iv_pegid        = ls_pegid

         IMPORTING

           ev_ppds_horizon = ppds_horizon

         EXCEPTIONS

           OTHERS          = 4.

       IF sy-subrc <> 0.

         CONTINUE.

       ENDIF.

       GET TIME STAMP FIELD lv_now.

      " Compare Current Date and Time with PP/DS Horizon, in UTC

       IF sy-subrc = 0 and ppds_horizon LE lv_now.

         DELETE i_object_keys-pegid_tab WHERE pegid = ls_pegid.

       ENDIF.

     ENDLOOP.

   endmethod.

Once the BAdI implementation is active, the heuristic is terminated for the material, if you run it at the Product View:

The pegging area will also be filtered from the heuristic in planning runs (/SAPAPO/CDPSB0, /SAPAPO/BACKGROUND_SCHEDULING), though the step will be successful if there are objects to be planned (which were not filtered).

If an information or warning message is required, to alert planners of the materials which were not planned due to the BAdI, FM /SAPAPO/DM_PEGID_GET_MATERIAL can be used to determine the Product Number and Location for the pegging area.