Recently, I was exploring some of the options in Rules Based Availability Check ( RBA ) and found that SAP has introduced the option of merging the sub items to ease the handling of transactional documents in ECC. However, it has some pre-requisites that has to be met.

As part of the implementation I was running through, I always had the following questions in Product Substitution (in fact many users did come to me with the same question ) for which I didn't have any answer.

If there is a Product Substitution between two products P1->P2; and if the Product 1 is fully available to the extent of ordered quantity ? Why would system create a sub item with the same ordered product ? 

Initially when I approached SAP with this question, they reverted to me saying that the "Rules Immediately" option in the check instructions is responsible for such a behavior, however from business perspective it doesn't make any sense to create a sub item when the same product is fully being fulfilled with enough stock being available.

With the recent upgrade to SCM 7.0 EHP2; I found something in check instructions that made me to setup some test data and see how it behaves and it did answer me the questions I initially had ( mentioned above )

I have created a sub item between two products P1->P2 with rule control as "Start from top of list" approach. There is some stock of 900 PCs available for P1 in the location L1 (1000 ) and there was no stock for Product P2 in the same location (1000) .

I have selected the check boxes "Activate RBA", "Start Immediately" in check instructions and I have created the sales document for 2000 Pcs with Product P1 as shown below

I have seen that the sub item has been created though P2 doesn't have any stock. This particular case is something similar to normal ATP check wherein P1 is being ATP checked to look out for confirmation. Following screenshots shows the ATP picture and sales order situation.

Note :- The behavior is same ( sub item is created ) when the sales order quantity is less than or equal to the stock available for Product P1.

Now, I have selected the "Merge Sub items" option in the Check instructions and executed the ATP check. There has not been any change in the delivery proposal however, the sub items have been merged together and only main item is available in the sales order with the confirmation 900. Also, you can see the confirmation picture of schedule line at main item level as shown below.

Now, I have created a stock of 500 PCs for Product P2 and re-executed the availability check ( by keeping "Merge Sub-items option ticked ) and following is the delivery proposal screen for the same ordered quantity 2000 PCs.

After accepting the proposal, I see the sales order situation as shown below.

Hence, it looks like whenever the partial confirmation picture is identified, the pegging areas are being shared for a single sales document and hence as per the SAP documentation, the merging of sub item is not possible. In short, whenever the substitution takes place between two same products, sub items can be merged to ease the transactional document in OLTP for further steps.

But, there is one thing that we need to keep in mind in terms of location substitution. If there is one single product that is being substituted between two locations and if the quantity is completely being fulfilled with only one single product though two locations are being substituted, in this case merging the sub items is still possible because there can be a Stock transport requisition that could be created between the two locations. This can be configured in location substitution procedure using an activity to tranship the product between two locations.

Hope the above information helps.

You use Subcontracting in PP/DS and a PDS is used for order creation at Subcontracting Location.

When creating a Purchase Requisition for the Product at Plant Location, the order creation fails with error"Activity Not Valid" (/SAPAPO/OM_ERROR 043).

Conversely, if you try to create a Planned Order for the Product at Subcontracting Location, the same error is raised.

At the Product View, the following popup may be shown in this case

The issue is caused, in general, by a program error in PDS transfer.

To solve it, you may

1) Implement note 1824590 PDS-EXP: Dump TABLE_INVALID_INDEX after PDS explosion
2) Make an initial transfer of the Subcontracting PDS from ECC to APO
3) Retest the issue

You use /SAPAPO/CDPSB0, /SAPAPO/CDPSB1 or report /SAPAPO/BACKGROUND_SCHEDULING for planning in APO.

You face any of the symptoms below:

• You execute in a Planning Run heuristic New Explosion (SAP_PP_021). At the end of the Planning Run, you notice that no orders were reexploded
  
• You execute in a Planning Run heuristic Rescheduling: Top-Down (SAP_PP_010). The Planning Run is terminated and in the Planning Logs error message "Order Not Found" can be seen. Also, error message "Invalid Order" (/SAPAPO/OM010) is raised
• You execute in a Planning Run heuristic "Conversion SNP --> PP/DS" (SAP_SNP_SNGL or SAP_SNP_MULT). After the planning run, you notice that no Planning Logs were created and that no orders were converted
  
• You execute in a Planning Run heuristic Rescheduling: Bottom-Up (SAP_PP_009). The heuristic is terminated with error message "Product xxx in location xxx could not be planned" /SAPAPO/RRP_HEUR032
  
  

There is a program error in the selection of objects for planning in /SAPAPO/CDPSB0 and /SAPAPO/CDPSB1 and this program error affects all of the heuristics above. If you are having one of these issues, please, check whether note

1655314 - Rescheduling: Bottom Up fails during the Planning Runs

is implemented. Apply it, if necessary.

An organism like your SAP system can evolve and adapt to its particular business jungle. Become faster, more efficient and make users happier.  It requires you to be bold, to stay safe but assume the risk.

This evolution should be the next step after a successful implementation of a basic standard platform. This is the logical thing to do. Like starting building the house after the foundation is set.  Yet, you see everywhere cautions words about customization, portrayed as something to fear, a last resort option. Progress becomes a steady succession of upgrades and support packs that offer not much improvement over what you already have.

I’m a pro-customization consultant and this is the manifesto of my beliefs. I believe constant improvement techniques should be applied not only to your processes but to your system, finding new ways to help users do their jobs, supporting those characteristics that make your business particular and competitive. The blog that this post starts will explore customization ideas and projects in production planning in the hope to attract like-minded professionals and maybe converting a few nonbelievers.

SAP aims to be a platform for any industry. By adjusting its configuration it can cover many requirements and adjust to most processes. There is however a limit to what standard functionality can accomplish. The indication that SAP knows its own limitations is the wide range of customization options it offers. Its source code is there for all to see and it lets you ABAP your solutions in many ways. The list is long: user exits, BAdIs, coded queries and programs of all kinds as well as standard functionality with code-like flexibility (e.g. object dependencies in variant configuration).

We can also consider as customization the use of standard functionality in clever ways for which they were not originally intended.

There’s a place you rather be. I exhort you to step beyond the line, unmask the ghosts by the road, plan for ambushing bandits, and get on your way.

Ghosts, bandits and the NO-NO policy

Ghosts are unsubstantial characters in horror tales used by those who want to keep you boxed inside the standard functionality for their own reasons.

Depending on their role these people will suggest or impose a NO-NO customization policy because:

• They don’t know how: Consultant tend to reuse approaches that has been successful in the past, functionality they know in detail. In addition to knowledge shortage, they may lack the willingness to search, learn and try a different way.
• It requires more work: To customize you need to think and test different options and occasionally be sent back to the drawing board by the unsuitability of an idea. Maintenance is also harder than with standard functionality.
• Plain is more profitable: A lot of recycling is possible, when doing a customer after another, if standard functionality is used. Much can be saved by copy-pasting documentation. Firms can do standard implementations with cheaper consultant with little experience while customized solutions require time from their high value gurus.
• They want to cover their backs:  Risk is ever present in any implementation, but blame can be diverted to SAP when the solution is standard. Customizing requires you to assume responsibility for your decisions and actions.

You should not be afraid of ghosts. Use your time instead preparing for real bandits.As with any myth, there are aspects of truth that you should be aware of, real problems that you should plan for or situations where customization should be better avoided.

• Upgrades: Upgrades are SAP changing the rules of the game and that causes a lot of problems.  This is true even for standard functionality but bad, as in fragile, customized code can be particular sensitive as it is your job to test it and adjusted for SAP changes.
• Standard functionality can cover it: Do not reinvent the wheel. Check first if an off the shelf functionality can do it. Something you have not used before, even obscure.
• There is no need: It is frustrating to invest money and effort in a tool that no one uses because the need is not real, the solution is too complex or the benefit is not realized.
• Zombie systems: The worst use of customization is to keep alive reports, screens and procedures that should have died with the legacy system. This happens when users are unwilling to incorporate the best practices on which SAP is built on – or even try a slightly different way to do the same thing.
• They don’t know what they want: When first implemented, users don’t know what SAP is capable of or its limitations. They may ask for things they don’t need, things they won’t use or figures that cannot be derived from the data in the system no matter how much you play with it.

These are valid reasons to treat customization with respect. The way you should treat electricity even if you wouldn’t consider adopting an Amish lifestyle because of the potential danger.

Step Beyond

There is a right way to do customization and you can archive it by following a few guidelines including these:

Embrace customization: If you fear customization you will shun from it, will not dedicate the time and effort required and the result will be a half-baked solution, fragile and dangerous, that will bite you back when less expected. Give customization the importance it should have, invest time and people in it, design procedures and rules to produce valuable and resilient solutions to be proud of.

Assume the risk: Life is risky, SAP implementations are risky; manage it. Even the most standard of systems will have some risk – it can fold down your company by not being complex enough for your needs. The solution is not to dodge customization but to be prepared. Most of the points that follow will help you reduce the risk or recover from an adverse event. Eliminating risk completely is unrealistic.

Determine the real need: Some customization undertakings start with the wrong foot by jumping to the solution without properly defining the requirement. Users are particularly bad specifying what they want. Uncovering the real need behind the request is fundamental to deliver a value added solution that the user won’t abandon. The distance between users and programmers introduced by outsourcing has contributed to the proliferation of spec perfect solutions nobody uses. Analyst should be capable to challenge the users in order to give them not what they want, but what they need.

Sell it: You should be so proud of your solution to brag about it; or at least to sell it to others with confidence on the advantages it provides. Why don’t use the tested tools of marketing: surveys, focus groups, promotion during training and post implementation customer service? Make sure that a good idea doesn’t go to waste because people do not know about it. The upgrade should be optional when possible, so the user make the decision to use it because they see the benefits. This also forces the IT team to make sure that the customization has a real value that can be measured.

Get it stable first: Customization during the initial implementation of the system is necessary to adjust the system to business specific processes that are fundamental and the standard cannot support. It is however preferable to let the system stabilize for some time before starting to incorporate further enhancements, allowing the business to understand better what the system can give them and what they lack. Incremental steps giving time for the new features to get assimilated are better.

Document for maintenance: People don’t read documentation, so make it readable. As with any form of writing documentation should grab the reader attention and express ideas clearly. Don’t write to yourself; don’t assume the other knows what you do. Always start exposing the origins and the rational of the tool, selling its benefits and warning about known issues and limitations. Leave the technical details to the bottom of the document. Having the original document with changes appended at the bottom is a bad idea, it makes understanding the document a torture. Use versioning to keep track of history but keep the main document as a consolidated view of what is currently there. Make parachuting into the project easy for newcomer consultants and users with a central compilation of all the customization in the system with a link to each feature’s document. Use technologies like Wiki to let anyone expand or correct, rearrange and link what becomes no longer documentation but a useful reference and help tool.

Code for maintenance: Always choose readability over performance. People may complain about speed but it never reaches the level of hysteria caused by a problem that is taking time to fix. Segregate every step in blocks or function calls (extract_data, do_calculation, display_report). Put additional effort while commenting the code, using several lines for each step to explain what it does and the logic behind it. Make the code your main technical document.

Use resilient code: Fragile code is the result of rushing things, bad practices and poor understanding between analyst and developer. Fragile code fails during upgrades or if a special case is encountered, failure is usually unexpected, catastrophic and difficult to fix. Resilient code fails too but knows how to fold graciously instead of exploding and falling in flames. Suggestions of good coding practices – like checking if a number is zero before dividing by it – require a post of their own.

Leverage your team: Don’t allow the consultants to leave your people in the dark, make sure that the understanding of the details is passed to your team, that they make it their own. If you team is not capable of owning the solution, develop them. In particular, I believe that the most effective investment you can do in training is to teach your analysts enough ABAP to read and debug code, write specs for solutions that are feasible and discuss on the same level with the developers.

Make your customization configurable: Create a table for any new piece of code with an indicator that you can set or reset to activate the code or skip it; either as a global switch or dependant on a group (a plant, a material type, an MRP controller). If you code allows for different approaches let the configuration table define which. Avoid hardcoding, use a customized table or a selection parameter instead. By configuring your customization you can activate the functionality just for a pilot and then roll it over in a controlled way.  This also allows you to easily fall back to a previous version, or all the way to the standard, in case there are problems.

Test, test, test: It cannot be stressed enough, you should test as much as possible as many cases as possible. But also understand that real testing only starts when you move the solution to you production environment. Do not be surprised that the business has issues with your solution; you should be in alert and ready to act. Ask for feedback and adjust the code as soon as the need arises.

So these are the precepts that I have based my career on and that guide what I currently do. They are also the basis of this blog where I will promote customization by sharing ideas and giving away solutions that you can use and expand.

M. Night Shyamalan’s film “The Village” shows how people can feel a moral duty to make you fear what they fear, to keep you away from danger. You can however have a different view. Stepping beyond that line can take you to a whole new world of opportunities.

(This post was first published on the author's professional blog, see profile)

Hi all.

At the Product View, Elements tab, there is field Resource. This column displays, in general, the resource assigned to the last operation of the order (or the output resource).

Overtime, I've seen a couple of customers who wanted to display in this field the resource assigned to the first operation of the order instead.

This can be done by creating an implementation of BAdI /SAPAPO/RRP_IO_COL, Method RRP_USEX_COLS_FILL_01.

When the BAdI is reached, there is table CT_IO which contains field MAIN_RESOURCE, which is the resource id of the resource displayed in Elements tab. When we want to show a different resource, we have to assign a different main_resource.

An example of how this could be done is shown below:

method /SAPAPO/IF_EX_RRP_IO_COL~RRP_USEX_COLS_FILL_01.

INCLUDE /sapapo/constants_om.

   DATA:

   lt_rc              TYPE /sapapo/om_lc_rc_tab,

   lt_order           TYPE /sapapo/om_ordid_tab,

   lt_activities      TYPE /sapapo/om_tab_act,

   ls_gen_params      TYPE /sapapo/om_gen_params,

   lv_simsession      TYPE /sapapo/om_simsession,

   ls_exclude_fields  TYPE /sapapo/om_exclude_fields,

   ls_exclude         TYPE /sapapo/om_getdata_options.

   FIELD-SYMBOLS:

     <io> LIKE LINE OF ct_io,

     <act> LIKE LINE OF lt_activities.

* get orders

   LOOP AT ct_io ASSIGNING <io>.

     APPEND <io>-orderid TO lt_order.

   ENDLOOP.

   CLEAR <io>.

* get simsession and parameters for LiveCache call

   CALL FUNCTION '/SAPAPO/RRP_SIMSESSION_GET'

     IMPORTING

       ev_simsession = lv_simsession

       es_gen_params = ls_gen_params.

* no need to calculate pegging

   ls_exclude_fields-slacktime   = gc_true.

   ls_exclude_fields-devquantity = gc_true.

   CALL FUNCTION '/SAPAPO/OM_ORDER_GET_DATA'

     EXPORTING

       is_gen_params      = ls_gen_params

       iv_simsession      = lv_simsession

       it_order           = lt_order

       is_exclude_exports = ls_exclude

       is_exclude_fields  = ls_exclude_fields

     IMPORTING

       et_rc              = lt_rc

       et_activities      = lt_activities

     EXCEPTIONS

       lc_connect_failed  = 1

       lc_com_error       = 2

       lc_appl_error      = 3

       OTHERS             = 4.

   IF sy-subrc <> 0 AND lt_activities IS INITIAL.

     EXIT.

   ENDIF.

* only activities with assigned resources

   DELETE lt_activities WHERE resid IS INITIAL.

* so resource of GR activities will not be shown first

* unless it is the only activity of the order.

   SORT lt_activities DESCENDING BY opr_level.

* first activity of first operation with assigned resource

   SORT lt_activities BY orderid

                         oprcounter

                         group_oprcounter.

   LOOP AT lt_activities ASSIGNING <act>.

     LOOP AT ct_io ASSIGNING <io> WHERE orderid = <act>-orderid.

       <io>-main_resource = <act>-resid.

     ENDLOOP.

     " delete remaining activities of the order to keep

     " the new main resource.

     DELETE lt_activities WHERE orderid = <act>-orderid.

   ENDLOOP.

endmethod.

The Problem

Reports and Queries using the “Sap List Viewer” format are a huge improvement from the old “ABAP List” format. Columns can be moved by drag and drop, export options are better, looks are nicer and it has many other advantages.

The END-OF-SELECTION section is very handy. It runs after the records have been processed by the query but before the report is displayed. It is the right section to do aggregated calculations and actions that can only be done when data from all the selected records has been extracted.

However, there is a problem when queries use code in the END-OF-SELECTION section in combination with the Sap List Viewer format. In short, the code is never reached.

Here is a trick to make the combination work.

The Trick

When defining the query change the output format option to ABAP List. This will trigger the old source code generation that includes the code in the END-OF-SELECTION section.

Run the query and in the selection screen change the option to SAP List Viewer.

Save a default variant 

Include any other default values that you may need for the selection fields in the query.

Change the query and add the default variant as the standard variant of the query.

In this way, the query is generated internally for an “ABAP List” report and it will include the END-OF-SELECTION code. When the query is executed, the default variant will change the option and the query will display with a flexible “SAP List Viewer” format.

Enjoy.

Rules-Based Availability Check Overview and Steps to Configure

I think, RBA is one of the area in which we have highest number of questions posted on SCN.  I am posting this blog to consolidate my understanding/knowledge with RBA. Hope this blog will help our community members.

Introduction : An ordinary ATP check is restricted to the requested locationproduct and checks only the according timeseries. Using Rules Based Availability Check(RBA or RBATP) it is possible to substitute both the location and the product. In branched supply chain networks, rules-based ATP allows companies to take full advantage of multiple shipping assets to ship goods from alternative sites to customers. In addition, it permits certain products to be substituted as required to successfully satisfy customer demands. This is a functionality available in GATP

• Rules Based Availability Check is used to automatically or manually optimize the decision making process using predefined rules
• Rules Based Availability Check allows to react automatically to the incomplete availability of a product based on the following
  • Determining Alternative Locations: This automatically chooses one or more sources (= plants) from a list of supply sources that can be used to satisfy a product requirement.
  • Determining alternative products: This automatically allows to react to a shortage without producing or procuring the product. The alternative products can be chosen automatically from a predefined list.

Combination of above two methods

• Rule Based Availability Check can include basic methods as Product Availability Check and Product Allocation check per Product/Plant combination
• Rule Based Availability Check is activated via Check Instructions, triggered based on condition records maintained in APO and executed according to a
  predefined rule set.

Benefits of Rule Based Availability Check :

• Deliver product on time, right quantity to customer.
• Delivery product in most cost-effective way.
• Minimize order to delivery lead time.
• Leverage the full distribution network effortlessly.

Prerequisites: Following are the prerequisites for Rules Based ATP Check :

• Product and Location are transferred into APO along with setting up of necessary fields in ATP Tab in Product Master(/SAPAPO/MAT1)

• Check Control is setup for ATP group and Business Event combination.
• Set "Activate RBA" in the Check Instruction. Besides there are few additional(optional) settings which offers some additional functionality namely Start Immediately, Use Calculation Profile, Create Subitems and others. Please refer sample screen below.

        Go to SPRO>Advanced Planning and Optimization > Global Available-to-Promise (Global ATP) > General Settings > Maintain Check Instructions

Configuration Details: Using below SPRO Menu in APO,  Required configuration settings for Rules Based ATP Check can be done.

1. Field Catalog : With this activity, you can add new fields that you use for creating the condition tables. (/SAPCND/AO01)
2. Condition Table : In this activity, you create the condition tables used in the rule-based ATP check.(/SAPCND/AO03). You add fields from Field Catalog to create Condition Tables. FYI- Technical Name of Condition Table starts with /SAPCND/KOTO*
3. Access Sequence :  In this activity, you determine the access sequences. Using the access sequence, you determine:  Which condition tables are used to access the condition records. The sequence of these condition tables Which field contents are used as criteria for reading the condition tables. (/SAPCND/AO07). In Access Sequence, set the Exclusive indicator, only if you do not want the system to evaluate additional condition tables after the first successful access (not recommended to set the exclusive indicator).
4. Condition Type : In this step, you maintain the condition type and assign it to an access sequence. Condition types are used for determining rules in the rules-based availability check. (/SAPCND/AO06).
5. Maintain Rule Strategy : In this step, you maintain the rule strategy. The rule strategy determines the condition types and defines the sequence in which they are evaluated.
6. Assign Rule Strategy : In this activity, you determine the following activation parameters to determine the rule strategy:
   – Technical scenario (This is nothing but communication technique– EDI(DD)/Batch Input(BB)/Online Dialog(AA) etc)
   – Business transaction (Basically it is business context, You need to define a business transaction using VOV8 in the ECC system and assign it to an order type).
   – Action type (This corresponds to manipulation technique creating(A), changing(B), and copying(C))
7. Maintaining the Rules (using Integrated Rule Maintenance  /SAPAPO/RBA04):
   – Creating Product Substitution Rules : In this activity, you create the substitution chains for product substitution.
   – Defining the Rules Control : Using the rule control you can define the strategy. For example, the rule control determines whether the system checks the same product in different locations, or it checks a substitution product, first. Access Strategy is an important setting which you make in Rule Control.
   – Defining the Location Determination Procedure :  For the location determination procedure, you define a list of locations. During the availability check, SAP APO takes all listed locations   into account. If the requirement cannot be fulfilled in the original location, it is substituted by one of the alternative locations. Activity(refer below details) is assigned to Location Determination procedure for additional actions.
   – Calculation Profile: Allowed delays, Early confirmations, Consumption limit, Maximum number of partial deliveries etc.
   – Activity for Location Determination: In the Activity, you can maintain actions that are carried out if a determination is executed.  (Example – Override the Check mode with 050 to Z50 to allow different check instruction to use in ATP Check)
   – Maintaining Rules : The rule combines the possibility of location and product substitution with the rule control strategy. Location Determination Procedure, Product Determination Procedure, Calculation profile and Rule Control  are assigned to Rule.

  8. Creating the Rule Determination(/SAPCND/AO01) :  In the rule determination, you enter data for the key combination of a condition table and assign a rule to it.



Additional Resources: 

Rules-Based Availability Check - SAP Library

Global Available To Promise (GATP) Overview

Rule Based ATP with Exclusive Rule Strategy

Please do let me know your comments/feedback/input if any.

Thank you

Satish Waghmare

Introduction

APO interactive transactions for multiple products don’t usually have all the options for selection that the business may need. This article explains how to use ABAP Query functionality to extend and customize the selection for these transactions.

The article shows - as an example - how the receipts view can be selected by the ABC indicator of the products; a field not present in the standard selection screen. The technical details are explained so it should be easy to adjust the query for other fields and more complex selection requirements.

ABAP query is a powerful functionality that allows complex reporting. It can include ABAP code without the need for a developer key. In this example we combine the query selection with a transaction screen called directly from within the query.

Queries can be exported and shared easily. You can download a file with the definition of the query in this article in the original post in my professional blog (see my profile). You will also find instructions on how to load it into your system.

Interactive transactions

• Receipt view                      (/SAPAPO/RRP4)
• Requirement view              (/SAPAPO/RRP1)
• Product planning Table     (/SAPAPO/PPT1)
• Product overview               (/SAPAPO/POV1)

These are APO transactions that use the same selection screen. As you can see below the selection options are limited, even if we consider the additional tabs.

Selection screen of /SAPAPO/RRP4

“Other” tab in /SAPAPO/RRP4 selection screen

This is enough in most cases but the user may need a different selection field or approach.

Using the product-location free attributes fields in this way can be particularly useful as these fields can be populated with specific parameters from ECC not available in standard APO.

In the example presented the selection screen will look as follows and includes the ABC indicator as a selection option. The output result will depend on the interactive transaction extended. In this example it will be the receipts list for those product-locations matching the query selection.

Technical details of the interactive transactions

The transactions indicated in the previous chapter all have a similar internal structure. The transaction calls a program include that does the following:

1. Calls function /SAPAPO/PT_SELSCREEN: This function encapsulates the selection screen and brings back a selection of pegging areas that will be used in the report. Some additional conditions - like the date range - are also returned. All 4 transactions call the same function passing only a different title in a variable so that it shows at the top of the selection screen.
2. Some manipulation of the selection parameters is performed: For example converting dates into timestamps.
3. A function is called to display the transaction main screen: This can be just the order list or more complex functionality like the production planning table. This function takes as input the list of pegging areas from the function in point 1.

The following table shows for the 4 transactions the program include where the functions are called and the function used to run the main transaction.

Implementing the query

The query selection substitutes the first function call with a customized extraction of the pegging areas that is then feed to the function that runs the transaction. In this way, we can make the selection much more complex, adding any field available in the product-location master data tables and filtering the combinations before calling the transaction.

For this article we are going to use a simplified selection of product, location and ABC indicator.

First of all we create an infoset by joining the tables indicated below.

Then select the fields to be used in the query.

The “from” and “to” dates are important parameters to reduce processing time. These transactions are usually slow even for a small set of materials and any additional restriction will help performance. Create them as parameters in the query infoset.

Additional selection parameters in query

Definitions for date and time fields

Query Code

ABAP code is required to call the transaction function with the parameters determined by the query.

The following is an explanation of the code logic by sections in the query code tab.

DATA

In this section the data variables and structures are defined.

Record Processing

This is the code that is executed for each of the records returned by the query select of the data.

The query returns a list of pegging areas in table /SAPAPO/PEGKEY for those product-locations included in the selection. Each pegging area ID is copied and appended to the temporary tablelt_pegarea.

END-OF-SELECTION (Before List)

After the query has collected the pegging areas for the product-locations in the selection, the function that runs the transaction is called.

In addition to the pegging areas, the FROM and TO date timestamps and the active version (000) are passed to the function.

Query definition

The query itself (SQ01) is straightforward. The selection screen shows the parameters defined in the infoset. Add the others parameters as selection. This query will not have any list displayed as the transaction will be called first. Include the fields in the display anyway to make sure the code is executed.

It is also important that the query is set as ABAP List to make sure the code in the END-OF-SELECTION section is included and used in the query.

Stepping beyond

This basic query can be extended in different ways, for example:

• Additional fields from the product-location can be added as well as complex checks to exclude pegging areas not needed. Even if the field is included in the transaction list and can be hidden with a layout; it is much more efficient to exclude it in the selection screen.
• The planning version is hardcoded here to 000 but it can be part of the selection to allow the use of other planning versions.
• You can have 4 different queries for the 4 different transactions or a single query with a radio button in the selection screen to choose.

Have fun.

(This post was first published on the author's professional blog, see profile)

APO and ECC have different approaches to the calculation of time and capacity in a production order.

These may create different results for the same order when complex calculations or variant configuration are used, confusing the users and - in extreme cases - making a good APO plan unfeasible when dropped to ECC.

This article explains these differences in detail and explore options to align the APO calculation to the calculation done in ECC.

How ECC calculates

The core of the ECC calculation for an operation’s time, capacity and cost is the formula assigned to the workcentre. The formula calculates based on parameters that take their values from the order, the operation standard values (usually copied from the routing) and the workcentre itself in the form of workcentre constants.

The most generic formula for a workcentre is the linear formula shown below. It has both a proportional term and a fixed term.

It uses standard SAP parameters that translated to their description would be:

Where the standard value 1 is the proportional time and standard value 2 is the fixed time.

For example, let’s assume a process that requires 5 min to set the operation and 3 minutes to process 1,000 units.

The time calculated for an operation for 30,000 units would be:

30,000 units / 1,000 units x 3 min + 5 min = 95 min

The formula can work for any workcentre with any combination of proportional and fixed time, including workcentres where the time is fixed regardless of the operation quantity (e.g. an oven).

The standard approach covers many requirements but cannot handle more complex situations as is the case with nonlinear formulas or when additional parameters are involved. Nonlinear formulas require functions that are not supported by workcentre formulas. Sin(x). Log(x) and Xⁿ are some examples. The use of tables to determine a formula parameter is also nonlinear.

When used Variant Configuration (VC) the configured values for a specific order or product can be used to alter the calculations as well. Dimensions like length and surface are typical examples, for example the diameter in a pipe cutting operation.

ECC can accommodate these complex requirements with two functionalities: CAPP standard value calculation and Variant Configuration object dependencies.

CAPP Standard Value Calculation

This functionality uses formulas and rules based on characteristics values from different origins to modify the standard values of the operation. The calculation can be complex, using math functions or reference tables to determine the standard value for specific operation parameters. The standard value is then used in a regular work centre formula to determine times, capacity requirements and costs.

CAPP is being superseded by Variant Configuration (VC) as it covers the same requirement with additional advantages, like compatibility with APO’s Characteristics Dependent Planning (CDP).

Variant Configuration Object Dependencies

Variant configuration is a powerful functionality that is normally used to produce orders for customer specific requirements, for example a particular colour or cruise control option in a basic car model, in order to handle the exponential number of combinations without the need of a material record for each. Regular materials can also adopt VC functionality in order to reduce the BOM and routing master data with the use of “Super” BOMs and routings that are shared by many materials but are dynamically modified to adapt to the material or specific order characteristics.

A third use for this functionality, and the one related to the subject of this article, is to allow a more accurate calculation using parameters from multiple sources and complex formulas to modify the standard values copied from the routing into the order, as CAPP does. In addition to standard values ODs can also access and modify directly an extended number of fields both in ECC and APO.

There are different kinds of Object Dependencies but the ones used to determine the standard values (procedures) are scripts that can have conditionals, arithmetic operations and math functions. They can also determine values using reference tables or call ABAP functions. With all these options, ODs can handle complex calculations of time and capacity with accuracy. Accuracy is important in this case as small differences can accumulate to significant variations for large order quantities.

The following diagram shows ECC’s approach to the operation calculations.

A Configuration Example

Suppose there is an operation to cut a pipe to a specific length from a continuous supply. The time required to process each pipe is a combination of the time to move it into place, that depends on the length, and the time required to cut it that we assume is proportional to the square of the diameter.

Processing Time = A x Length + B * Diameter²

Where A and B are standard values that depend on the machine and material.

The diameter and length value are coming from characteristics configured in the material master if there is a limited number of length cuts. Alternatively, the length may be defined during sales order entry and transferred to the customer segment, making possible to produce a pipe of any length without having an extremely large number of material records.

We can use the OD to copy the values of length and the diameter squared into two of the remaining standard values (2 of 6 already used by A and B), then use a simple workcentre formula to calculate the operation duration or capacity using these 4 values.

How APO Calculates

APO calculate times and capacities in a simpler way. The formula is already predefined in the operation and is a linear formula of the kind explained at the beginning of this article. It has a variable term and a fixed term. You can see them for the duration of the operation (expressed in seconds) in the mode tab for the resource:

In APO there are no standard values and the duration formula is predefined for the operation as:

Duration = Dur.(V) * Operation Qty / Base Qty + Dur.(F)

The capacity works in a similar way.

APO can work with variant configuration and object dependencies as well. In APO the equivalent to Variant Configuration (VC) is the Characteristic Dependent Planning (CDP) functionality.

In APO the object dependency con modify the fixed and variable terms used in the predefined linear formula. It can also modify the duration and capacity result fields directly. This assume the use of Production Data Structures (PDS) that are compatible with object dependencies and supposed to be substituting the previous SAP approach to routings in APO (PPMs).

Deriving the Variable (V) and Fixed (F) terms for APO

If the operation has a linear formula in ECC the standard functionality has no issue delivering an accurate calculation in APO even if the approach is different in the two systems.

To do this the system takes a couple of results from the ECC formula (for example for 0 and 100 units). With those 2 points the line is defined and the variable and fixed terms for the duration in APO can be calculated. So, regardless of the complexity of the formula the calculation is perfectly replicated in APO if the ECC formula is lineal.

This approach is not good for non-linear formulas as APO tries to replicate them with a linear approximation. The error incurred by this approximation can be better explained with an example.

Let’s assume following non-linear ECC formula, with terms are in seconds for simplicity.

Duration = 5 + 10 * Quantity²

This generates the following variant and fixed terms in APO.

Calculating the ECC and APO durations for different quantities shows the variances in the result.

The difference is substantial. Graphing the formulas is clear that the two give the same result in the two points used by the system to calculate the APO linear terms (0 and 1,000 units).

This example may be exaggerated and unrealistic but it clearly shows the problem of non-linear ECC formulas when approximated by APO linear terms.

Solution Options

The way the calculations in ECC and APO can be aligned will depend on the specifics of the situation and how close you can keep to the standard. A flexible solution is usually a better approach but a hardcoded approach can also work well if the requirement is stable and well defined.

A logical place to adjust the calculation is in the BAdI at the creation of the order in APO, which allows the adjustment of the duration and capacities before the order is saved in LiveCache (/SAPAPO/RRP_SRC_EXIT method RRP_USEX_PLORD_CREATE).

It may be tricky when variant configuration and object dependencies are involved in the calculation but the functionality offers additional options to the point that you may want to consider using VC and ODs even if the material doesn’t need to be configured from the sales point of view.

In very general terms the idea is to put the complex part of the calculation in the object dependency instead of the work centre formula and use reference characteristics to get the parameters values for the formula. The object dependency is transferred to APO as a procedure in the PDS and the parameters can be passed between systems as part of the configuration.

The approach works as long as a few complications are resolved.

• The characteristics for parameters and results have to reference different fields in ECC than in APO as their internal structures are different: SAP offers a configuration table to map fields in ECC with their equivalent fields in APO. This can also be done manually after the reference characteristics are transferred to or created in APO as long as it is before they are used there.

• The object dependency is copied “as is” from ECC into a procedure in APO but sometimes it makes sense to have a different version of the formula in each: A trick can be used in this case to include two different formulas in the same object dependency. The result characteristic of the first formula references a field in ECC but no field in APO. The second formula result points to a valid field in APO but no field in ECC. Both formulas are calculated in both systems but ECC gets the result from the first and APO from the second.

• Standard values are not transferred to APO and they cannot be passed as configuration since the configuration is for the whole order and the standard values can be different for each operation: The blunt and simple way of solving this is to include the standard values as numeric values in the object dependency. This means a different object dependency for each different combination of standard values, making maintenance of the values difficult as mass tools like LSMW or the Engineering Workbench cannot be used to change the values. I designed a solution that uses a BAdI to modify the object dependency when the PDS is being transferred to APO. It substitutes in the object dependency formula the characteristics referencing standard values with their numerical value for that specific operation. This approach uses a single object dependency while allowing mass change of the standard values in ECC. The values in the APO procedure are updated when the PDS is retransferred with CURTO_CREATE.

For historical reasons it has always been difficult to align ECC and APO – the CIF wouldn’t exists otherwise - and the way they calculate is no exception. By understanding their approach, and with a little bit of work, it is possible to get them to speak the same numbers even for the most complex cases. Theirs a estrange feeling of satisfaction when they do.

(This post was first published on the author's professional blog, see profile)

Hello Dear Experts,

I came across a strange issue in APO GATP where i see the partially delivered items which was not goods issued yet(Open deliveries) consuming allocations from QTTAB in APO upon back order processing ,which is incorrect according to my opinion.I have checked all the config setting in APO GATP and every thing seems to be perfect.We are configured to consume allocations based on sales order MAD date in QTTAB.

Can you please throw some light on this issue.

Thanks

Mani

Recently, I've seen quite a few incidents in which, after upgrade to SCM 7.02 or SCM 7.13, a Planning Run executed as a background job via /SAPAPO/CDPSB1 or report /SAPAPO/BACKGROUND_SCHEDULING takes a long time.

If you experience such an issue, execute transaction SM50 while the job is running and verify whether there are Update Tasks stuck for a long time on program SAPLSENA. If that is the case, notes below should be implemented, when applicable:

1998968 Update task hangs in program SAPLSENA

2009511 Infinite wait for enqueue in a submitted program
2025948 Long processing times spent by waiting for an enqueue

When a Planning Run is executed, some planning logs have to be written in an Update Task using this program, which belongs to BC-SRV-BAL area. As the issue is not specific to PP/DS application, it's quite easy to miss these basis correction notes, thus I'm creating this blog post to increase awareness of the solution.

Well, this is very old for all APO guys out there - the procurement priority of the PDS is set to thirteen 5's (5555555555555) if the corresponding production version is locked in APO and if the orders still exist for this PDS in APO. If no orders exist in APO, the PDS simply gets deleted (note 854561).

We asked SAP recently why would we want to have the PDS not displayed in CURTO_SIMU if the corresponding production version is locked in ECC. The as usual kind and gentle support team of SAP has come up with the 9th version of this note with a simple two-line code snippet and asked us to implement this correction if we would like to have the non-deleted PDS to be seen with procurement priority 5555555555555 in CURTO_SIMU.

However, the note actually uses the CHECK statement and this means - any other logic if you had used in the BADI should have to be compromised. So, just make the CHECK as IF... ENDIF

yes, you sometimes see a short dump in SMQ1/SMQ2 but ignore it assuming it as one-off case. But note - each one has a reason, and we should police each abnormal behavior .

Let's assume you have a blocked queue in SMQ1/SMQ2 and you hold on to this screen. Someone from your team clears this error in the mean time(or yourself from CQ transaction). And then, you double-click in SMQ1/SMQ2 to see the detail of the error only to end up with a short dump MESSAGE_TYPE_X.

Fix? Implement the note 2032262 on ECC side, and 2046352 on APO side. Instead of the above short dump, you will then see the message as below:

Well, we all would have learnt of the note 1947530 which fixes the issue of double line entry creation of the PDS during the CIF in case the ‘validity from’ date of the production version is changed to the past of its currently maintained date.

But again, this note is just not enough! You will still face the problem in case you shift your validity of the production version completely away from any of the dates within its validity range.In simple words, if the new ‘valid from’> old ‘valid to’ of a production version; you have the issue again in APO

For fixing this issue, SAP has released one more note 2042931 which can be implemented.

But the problem still remains! How about the already created double PDS cases? The issue was caused by SAP code and hence they have to rectify these cases.

The note 1453522 comes to your rescue in this case – it has a clear explanation on the functionality of the report

Let’s assume a sales order is created which is integrated with APO. The delivery date for the SO, say lies on some UTC + x time-zone (the customer [ship-to] location’s time-zone). As part of the standard CIF,

1. the “UTC + x” of the ship-to first gets converted to UTC in ECC,
2. then goes to APO in UTC format,
3. converts UTC to UTC + x to map it to the ship-to location in APO,
   1. Make sure to maintain the same UTC + x settings both in ECC and APO for the ship-to location. Of course, things will remain good if you CIF across and do not disturb the UTC settings either in ECC/APO. In case they are different, the date/time gets converted to the new date/time as per the UTC settings in APO for the location consequently creating incorrect delivery date/time for the order.
   2. I believe the data in APO live cache is still saved in UTC format only – that’s the reason why I think SAP has developed this logic of converting to UTC in ECC before it passes to APO. The time you display the order, it gets displayed as per the time zone setting you maintained – like in product view, you can allow the system to display in the time zone you want.

The reason why I said point 3.2 is: SAP, instead of implementing the logic showed in the below figure

could have simply implemented the below logic where they could fool the system to understand any UTC + x time-zone as UTC (=dUTC, dummy UTC) itself and proceed further. No conversion needed anywhere

The point I am trying to make here is:

Say, if I am creating a sales order in ECC for a customer in Mexico (= “UTC-6”) with requested delivery date/time being 31/10/2014 21:00, the order goes and sits on 01/11/2014 in AC42 screen – the reason? The UTC format in APO is not being converted back to the “UTC-6” time-zone when the order is supposed to be mapped to this Mexican customer.

Similarly, if an order is created for a customer in New Zealand (= “UTC+12”) with requested delivery date/time being 01/11/2014 06:00, the order goes and sits on 31/10/2014 in AC42 screen – the reason? You now know!

This is the problem not just with us, but with the SAP support package is what we strongly believe – hence is this blog. We recently upgraded the support package of SCM release 702 from support pack 8 (SAPKY70208) to 11 (SAPKY70211). We identified this problem as part of one of our testing scenarios.

After enough investing of effort on this case, one of our consultants found that the changes in the note 1843121 are partly contained in support pack 11. There are two correction instructions 1227144 and 1227145 which are relevant for this release, but only 1227145 is contained. Not sure if this is a problem from SAP or an error from our patching team. We raised this to SAP, and are awaiting the feedback. Will update the outcome in the comment section anyways .

You have a subcontracting purchase info record in ECC (ME13), and you transfer it via the integration model – you will then have in APO:

1. the external procurement relationship,
2. the product-specific t-lane from the vendor to plant for the output components.

You have a production version assigned to the purchase info record (either directly in the info record or through CMPDS1), and if this is transferred by CIF, you will have the – 

1. PDS at the vendor location,
2. the product/location combinations at the vendor location for both input/output components,
3. product-specific t-lane from the plant to vendor for the input components.

Well, we observed that when comparing product allocation in APO, this report in APO tries to fetch also the documents prior to the initialized period of the product allocation planning area, and accordingly creates some entries in /SAPAPO/SDQTVB table and /SAPAPO/POSMAPN (during product allocation assignments for orders). After that, when running program /sapapo/sdorder_del with option “Delete obsolete records in /sapapo/posmapn table”, the system finds the records in /sapapo/posmapn are redundant and deletes them (but leaves the /sapapo/sdqtvb entries). And when I say this, it means that there is an entry in SDQTVB with no mapping entry in /SAPAPO/POSMAPN table (which contains the order numbers).

The consequence is: we end up with some allocation assignments having no order items: meaning, you may end up fining some inconsistencies in /SAPAPO/ATPQ_CHKUSG transaction for "Assignments without order items", because the table SDQTVB in fact never gets cleaned, but gets piled up always.

Why this happens? Because SAP has not given a provision of restricting the orders with delivery dates lying only within the initialized period of our allocation planning area. We may be asked to type-in the time-interval fields when we run SDRQCR21 report for allocation assignments - but this is impractical. Users who run the report are not expected to know the current initialized time period and accordingly maintain the dates. In fact, even if they know the period of initialization - it doesn't sound good to ask users to maintain some values in the time-interval field in the SDRQCR21 report.

The expectation is: SAP should somehow identify if user is running SDRQCR21 for allocation assignments and should do a check in the background to not try to reconcile any orders beyond the initialized period of the product allocation planning area.

This behaviour of trying to reconcile the very-old documents is obviously wrong over here, but the possibilities of getting a fix for this from SAP is, I have to say, difficult. In case if we raise this to SAP, there are all the chances that SAP would come back saying to maintain the time-interval, or exclude the completed documents from getting reconciled by checking "No Orders with complete Delivery" in SDRQCR21 report.

The point is: we still would like to check (and if applicable, correct) the completed documents as well by SDRQCR21. It might be the case at one point that due to CIF error or some manual mistake - all the assignments would have gone wrong by CIF, and no one noticed that. The documents are now completed with corresponding deliveries created. But yet, we do not expect the incorrect values to be lying over there in APO as we might want this to be reported elsewhere - so, we want these completed documents also to be checked by SDRQCR21 in APO and if required, corrected.

It is good if SAP understands that:

1. Customers would like to not check the option “No orders with complete Delivery” for avoiding the reconciliation for completed documents,
2. Customers are not willing to maintain manually the time-intervals in the selection screen of SDRQCR21 in APO.

and help release a note for this fix. But yes, we have our fingers crossed.

You are in SAP GUI 730 Patch Level 10.

You use the Detailed Scheduling Planning Board in APO.

You have maintained custom Context Menu entries in the customizing for the Planning Board Profile (transaction /SAPAPO/CDPSC2).

In this scenario, it is possible that, when you right click an object (like an Activity/Operation) in a chart (like the Resources Chart) and choose an option from the Context Menu, the wrong function will be executed.

Examples are:

     - you right click an activity and choose "Undo Colored Highlighting" - instead of undoing the colored highlighting, the activity is hidden.

     - you right click an activity and choose an option in the context menu, however no actions are executed

     - you right click an activity and choose "Undo Fixing" - instead of unfixing the activity, the system tries to find alternative resources instead of unfixing the activity

There is a known issue with SAP GUI 730, Patch Level 10, which can cause this.

The issue should be solved with SAP GUI 730 Patch Level 11.

SAP GUI 730 Patch Level 11 is estimated to be released in Week 46 (10th to 14th of November 2014), as per note 1053737.

Even if SAP makes its best effort to provide useful selection screens that may appeal to all its customers, the options could feel limited for your own selection needs.

In this article I explain how to use a query with code to extend the selection of almost any transactions in order to run it for a list of cases that meet a complex and non-standard criteria.

I call the approach a “variant update query” and it is fundamentally that: a query that updates a dynamic variant that is then used in the transaction where you want to apply the extended selection.

This is particularly useful for background processing where you can use one step - of the job or process chain - to run the query that updates the variant, and a second step to run the actual transaction using the newly updated query.

It can also be used while working interactively if you run the query before running the transaction with the updated variant or if the query is designed to launch the transaction from within.

Let’s see an example

This is the block of the selection screen that determines which cases will be included in an APO deployment run (transaction /SAPAPO/SNP02)

Even with the option for a profile some selections are impossible to define in general terms with this screen.

Let’s say that you want to deploy only materials that are classified as “A” for the ABC indicator in the target plant. Or maybe a combination between a condition in the source plant and a different condition on the target plant. This is only an example of a universe of complex conditions you may need to use for the very particular characteristics of your business.

In my experience I have found that this is a great approach if your want to include any customized field, values stored in LiveCache or variant configuration values that generally are not part of standard selections.

One manual option is to select the cases with other tools (e.g. extracting data to Excel to cross and filter there) and copy paste a list of materials in the product selection field.

This is basically what the variant generation query does. It uses a generic selection that produces - in this case - a list of materials and then appends the list into the deployment transaction variant.

The selection of the query can look something like this:

This selection in this screen (that includes the variant to be updated) is populated and saved in a variant for the query. Do not get confused by the fact that there are two different variants: one for the query and one for the transaction.

Running the query selects the materials that comply with the criteria and adds them as a list in the product field of the deployment transaction variant.

I use queries in this article because I love queries. I think queries are powerful and underutilized by many. You can do so many things with queries that I have focused myself and my company into the interesting niche of “query consulting”.

However, you can apply the approach with a regular ABAP program as well.

If you liked this idea, you can find some others in my blog sapppyw.co.uk. 

The technical details

The details will vary accordingly to your requirements, but the approach is similar.

1. The query functionality is used to collect a list of objects to add to the variant, in this case materials but can be orders or other objects. The functionality is so flexible that you can incorporate any criteria and complex links and rules, although you may need to add embedded code in some cases.
2. In the code block at the end of the query run (END-OF-SELECTION before list) use function RS_VARIANT_CONTENTS to extract the current parameters in the variant to be updated.
3. Add the list of collected objects into the required data structure. If you are not sure where they should be I suggest you update the variant with dummy values and debug the function to see where the values are stored.
4. I also suggest you add a value that is not real, for example “NOMATERIAL”, to the list. This is to prevent the transaction from running for all materials if the query result happens to be null.
5. Use function RS_CHANGE_CREATED_VARIANT to update the variant with the new values. Now the variant should be ready to use in its transaction.
6. SAP supports a limited number of individual values in a selection. This value varies depending on the transaction so you may need to experiment until you know what number doesn’t gives you a predefined error or causes the transaction to dump. You can then split the job into several variants. 

Enjoy

You are in SCM APO EhP3.

You use the Detailed Scheduling Planning Board in APO.

You have a resource utilization / capacity consumption / tank level /(...) chart to be displayed.

The curves on the chart do NOT appear.

This is an known issue. The issue should be solved with SAP GUI 730 Patch Level 12 / SAP GUI 740 Patch Level 02.

For more information, please visit note 2103679 - SAP GUI BARCHART: Curves are not displayed in chart.