Note 358330 - Delete old temp. qty assignments with pers. ind.

Symptom
You want to delete temporary quantity assignments, which exceeded a predetermined date and which have a determined persistence indicator.Additional key words
Delta records, /SAPAPO/OM_DELTA_REMOVE_OLDERCause and prerequisites
You can use report /SAPAPO/OM_DELTA_REMOVE_OLDER to delete old temporary quantity assignments (refer to Note 315507). However, up to now this report was able to delete old quantity assignments only according to user and type (product availability, product allocation, planning, network).Solution
This correction extends report /SAPAPO/OM_DELTA_REMOVE_OLDER so that you can also include persistence indicators (not persistent, pre persistent, persistent) The system will then only delete temp. quantity assignments, which correspond to one of the transferred persistence indicators.For this correction, you first have to import a new COM object (SAPAPO COM build 24 or higher) for the liveCache. The procedure is described in Note 359074. You do not need to re-initialize the liveCache.In addition to the attached source code corrections, the following measures are required:
1. Call Transaction SE11. Select Data type and enter /SAPAPO/PERSIND_LIST. Choose the Create button. Select Structure. As Short text, enter 'List of Boolean values, determines the persistence indicator'. Enter the following components with component type:
2. NORMAL XFELDPREPERS XFELDPERSIST XFELDChoose the Activate button. Enter /SAPAPO/ATP as Development class.
3. Call Transaction SE37. Enter /SAPAPO/OM_DELTA_REMOVE_DATE and choose the Change button. Choose tab title Import. Enter new parameter:IS_PERSINDLST TYPE /SAPAPO/PERSIND_LIST X
4. Choose the Activate button.
5. By using Transaction SE38, start the Editor and enter /SAPAPO/OM_DELTA_REMOVE_OLDER. Choose Change. In the menu, choose Goto->Text elements->Text symbols. In the table, make the following entry: 007 Persistence indicator. Choose the Activate button.In the menu, now choose Goto->Text elements->Selection texts. If the attached source code corrections are already made, three table entries appear, having the names PI1, PI2 and PI3 at which the text is missing. Enter the following:
6. PI1 not persistentPI2 pre persistentPI3 persistentThen choose the Activate button.
Implement the attached program corrections.Source code corrections

Note 506393 - Conversion exits when creating characteristics combinations

Summary
Symptom
You would like to create or generate characteristics combinations for a planning object structure. The planning object structure contains one or more characteristics that have been assigned a conversion exit in the information object definition. This note describes how to deal with this situation.Solution
When characteristics combinations are created manually using transaction '/SAPAPO/MC62', the InfoObject conversion routines run. This means that you enter the external display of the characteristic value on the screen. However, only the internal display of the characteristic value that is determined by the conversion routine is stored.During the generation of characteristics combinations from an InfoCube using transaction '/SAPAPO/MC 62' no conversion routines are executed. This means that the characteristic values must be saved in the internal format in the InfoCube. You can display the InfoCube data in the 'LIST CUBE' using the option 'Do not use any conversion' in the internal display.If the data in the InfoCube is not saved in the internal format and the characteristics combinations are generated from this, different problems may occur in demand planning. One typical problem is that you cannot select your products in Interactive Planning. If you have generated your characteristics combinations with an incorrect internal display, you must delete the characteristics combinations and generate the characteristics combinations again with correct InfoCube data.
Related Notes

1025196 - Navigation attribute values are not loaded with CVC creation

540926 - Collective consulting note on planning object structures

Consistency Check between SCM and R3

Checks for Internal Consistency:
/SAPAPO/DMOPR_REORG_CTP - Backorder Elimination in Capable-to-Promise, Note: 426563,
Process:
You can plan report /SAPAPO/DMOPR_REORG_CTP to run regularly (for example, weekly) in the background. You cannot and must not define variants. There does not need to be parallel processing because the runtime is not critical.
Result:
The program run deletes the reservations of components and capacities. A results list is not created — there is no need to process or work through the results.

/SAPAPO/OM17 - Internal Consistency Check for Setup Matrixes
/SAPAPO/MATRIX_TO_LC_SEND - generate the inconsistent setup matrices in liveCache
Prerequisites
As well as the case described above (connection error to liveCache), we also recommend running the report before each consistency check for resources
Process
Report /SAPAPO/MATRIX_TO_LC_SEND must not be run in parallel. This is not necessary because the runtime is not critical. You can run other activities in the system.
Result
You can view the results list in the application log (transaction SLG1). Note that this log is not stored under the user name. You can find it under the object APO and sub-object PPDS.

/SAPAPO/REST02 - Internal Consistency Check for Resources

/SAPAPO/OM11 - Livecache Application log

/SAPAPO/ATPQ_CHKUSG - Internal Consistency Check for Product Allocations.

Note 416909 - Allocations: Backward consumption, next quantities first

Summary

Symptom

During the backward consumption in the allocation, the oldest accessible free product allocation quantities are always used first.
If the backward consumption is limited (number of periods), the free product allocation quantity in the past will not be used, or will only be used to a limited extent, for the next customer order (with a later delivery deadline).

Requirement: In the allocation of quotas those free product allocation quantities should be used up first during the backward consumption that are closest to the check deadline (depending on the setting of the material availability date, goods issue date or delivery date).

Other terms

Transaction: VA01, VA02
Allocations, product allocation, ATP, APO

Solution

With the following modification the behavior of the allocation of quotas in the backward consumption can be changed according to the request.

This note is a modification up to and including Release 5.1.
As of Release 7.0, this function is contained in the standard SAP system and can be controlled using the consumption period of the product allocation group.

Header Data

Release Status:	Released for Customer
Released on:	18.02.2009 22:12:23
Master Language:	German
Priority:	Recommendations/additional info
Category:	Advance development
Primary Component:	SCM-APO-ATP-BF Basic Functions

Affected Releases

Software Component Release From Release To Release And subsequent SAP_APO 20 20A 20A SAP_APO 30 30A 30A SAP_APO 310 310 310 SCM 400 400 400 SCM 410 410 410 SCM 500 500 500 SCM 510 510 510

Corrections Instructions

Correction Instruction Valid from Valid to Software Component Last Modifcation 280090 30A 310 SAP_APO 13.01.2006 17:38:52 768193 400 510 SCM 31.01.2009 00:51:51

Note 412429 - Defining jobs with macros

Summary

Symptom

• You have defined macros and you execute them in a background job, for example. It appears that these marcos produce incorrect results (or no results at all). If, however, you run these macros in interactive planning, everything works correctly.

• (Apparently,) no historical data is saved.

• The system does not issue the message "Data saved", although you would expect it to.

Other terms

Mass processing, macro, job, background

Solution

Ensure that you have taken the following points into account:

• You can define both start and default macros in interactive planning and these, of course, are automatically executed before all other macros. If your user-defined macro accesses data that is only available when these start or default macros are executed, then it works correctly in interactive planning. However, it is essential that you take this dependency into account when defining the corresponding background job. This means that you must ensure that all macros that provide your macro with data are executed in the background job before your user-defined macro is executed. You must ensure that the sequence is correct, because, obviously, a macro cannot return correct (output) data if the correct (input) data was not available.

Therefore, when you define the background job you must specify which start or default macros must run in which sequence to ensure that your user-defined macro can function correctly.

• If your historical data is ready for input and you also want to change data in the past, you must implement Notes 350061, 386089, and 387486 in your system. All three corrections are delivered as of Support Package 11 (APO Release 3.0).

• You execute a macro for a second time (it was previously executed in the background or directly in interactive planning) so no data changes. Therefore there is no data to save either. As a result, the message "Data saved" does not appear in the log either.

In other words, the system only issues the message "Data saved" if new data is actually saved.

• If a macro runs successfully in the background, this is recorded in the log with a corresponding message (with a green traffic light).

If data is saved successfully, this is also recorded in the log with a message (with a green traffic light). The system does not issue this message if an error occurred or if the situation described above occurs.

• You must select the correct aggregation level when you define your job. That is the level that contains the required data. This is particularly important for key figures that are not aggregated. If you select the incorrect level (for example, a level that does not contain any data), then your macro cannot access any data either.

• If you defined navigation attributes for one or more characteristics in your planning object structure, then you must also take them into account when you select the aggregation level.

If Note 591112 is on your system (the note is automatically included as of SCM 4.0), then the system does not automatically add the navigation attribute to the selection of aggregation level, if you selected the relevant characteristic as a detail characteristic. The reason for this is that there may be considerable performance problems if you have defined a large number of navigation attributes.

We therefore recommend that you only enter navigation attributes in the aggregation level in the following situations:

• You want the hit list to be grouped according to the navigation attribute (in this case, you do NOT select the related basis characteristic).

• The navigation attribute is used in the selection (for performance reasons, we recommend that you also include the navigation attribute in the aggregation level, see also Note 374681).

• The related basic characteristic is selected and the navigation attribute is used, for example, in the execution of the macro (such as ACT_IOBJNM_VALUE, AGG_LEVEL, DET_LEVEL, DRILL_DOWN, DRILL_UP, and so on). For performance reasons, you should include the navigation attribute when you define the aggregation level, so that the system does not need to read the characteristic values of the navigation attribute during the execution of the macro.

• Note that the system does not save user-defined auxiliary key figures, this means that when your job calculates auxiliary key figures in macro A, these can be used in macro B (which is executed after macro A). However, these auxiliary key figures are not saved. Thus, they cannot be displayed later in interactive planning, for example.

• In APO 3.0, it is only possible to save time series key figures in the background. Saving order liveCache key figures in the background is not supported. It is only possible to save order liveCache key figures in the background as of APO 3.1 (using a batch job). You must bear this in mind when you schedule a macro in the background.

• You cannot use macro functions that change cell, row or column properties (such as CELL_BG, ROW_VISIBLE, and so on) in a macro that runs in the background. This is obvious, because cell, row or column properties cannot be saved. If you use attribute functions in background processing, however, the system issues warning message /SAPAPO/ADV 100: "It is not possible to use function "macro function" in background processing". The system usually continues processing the macro, but you notice a certain drop in performance due to the unnecessary function calls.

One important example where problems may easily occur are alert macros. It is extremely important that you consider all of the points mentioned above when you define your job. Otherwise, your alert macros may not work correctly and in some cases there may be no alerts.

And of course, the points mentioned apply for all other macros too.

Header Data

Release Status:	Released for Customer
Released on:	20.02.2006 13:07:14
Master Language:	German
Priority:	Recommendations/additional info
Category:	Consulting
Primary Component:	SCM-APO-FCS-MAC MacroBuilder
Secondary Components:	SCM-APO-SNP-MAC MacroBuilder

Affected Releases

Software Component Release From Release To Release And subsequent SAP_APO 30 30A 30A SAP_APO 310 310 310 SCM 400 400 400 SCM 410 410 410 SCM 500 500 500 SCM 510 510 510

Related Notes

	1045639 - Consulting notes in SNP/CTM
	546079 - FAQ: Background jobs in Demand Planning
	539797 - Collective consulting note on macros
	521639 - Generation of DB Alerts in Background
	495166 - Tips and Tricks for Handling Alert Monitor

Note 433166 - MacroBuilder: Use of DRILL_DOWN, DRILL_UP functions

Summary

Symptom

You use the macro functions DRILL_DOWN() and/or DRILL_UP() in your macros. One or several of the following symptoms occur:

1. After execution you get unexpected results.

2. Executing a macro where the function DRILL_DOWN() or DRILL_UP() is used causes runtime problems.

3. You run the macros in interactive planning (TA /SAPAPO/SDP94). The macros work as desired without any errors. If you schedule the same macros in a background job, the macros provide completely different results or a short dump occurs.

Other terms

Macrobuilder, /sapapo/advm, Interactive Planning, /sapapo/sdp 94

Reason and Prerequisites

Incorrectly defined macros.

Solution

Adapt the definition of the macros used, taking the following points into account:

Note, in general, the following: When macro functions DRILL_DOWN() and DRILL_UP() are executed, the system internally carries out the same actions as when a user chooses the navigation functions "Details all" and "Total" using the header information for a characteristic in interactive planning. This also includes the execution of all default and level change macros.
However, note the additional remarks regarding macros in background further below in this note.

For 1. and 2.

• Make sure that the functions DRILL_DOWN() and DRILL_UP() are only called if the current planning situtation allows the relevant action. A check makes sense as to whether you are currently on an aggregated level or a detailed level for a characteristic. The check can be carried out using macro function AGG_LEVEL() (see the documentation and the delivered macro information 9AEXAMPLES (MacroExamples)).

• Make sure that the functions DRILL_DOWN() and DRILL_UP() are not executed repeatedly after each other by mistake. This also includes ensuring that the macro properties are maintained correctly and that the macrofunctions DRILL_DOWN() and DRILL_UP() are executed only once within a macro step (the macro step must have one iteration only).

• We urgently recommend that you put macro functions DRILL_DOWN() and DRILL_UP() in individual macros, thus separating them from the actual calculation. This is always possible on principle. Instead of one single macro which carries out the actions drill-down, calculation 1, drill-up, calculation 2 for example, you should define five macros in total. One collective macro and four partial macros executing the above-mentioned actions drill-down, calculation 1, drill-up, calculation 2. Define the collective macro so that it calls the four partial macros one after the other.

• Never execute functions DRILL_DOWN() and DRILL_UP() in a default or level change macro.

• In a situation including several planning objects (drilldown for at least one characteristic), make sure that data changes are not implemented simultaneously on different hierarchy levels. For example, aggregate data and details must not be changed at the same time. This is required to prevent inconsistencies.

• Check whether your intended logic has been displayed by the existing macros: Instead of using the functions DRILL_DOWN() and DRILL_UP(), execute the required navigation and macros manually (this is easily possible, if you considered the above recommendation and put the macro functions DRILL_DOWN() and DRILL_UP() in separate macros). Only add the functions DRILL_DOWN() and DRILL_UP() (refer to points 1 and 2) when this 'manual' process has achieved the required result.

• Compare the performance of the macro execution with the performance of the 'manual' process. Execution by macro should be slightly faster than 'manual' execution.

• You can, for example, increase the performance in the scenario; drill-down, calculation, drill-up, by calling up the macro functions DRILL_DOWN() with the additional optional parameter 'INTERNAL'. In this way, the sending of data to the GUI after executing the macro function DRILL_DOWN() that is not needed later on is prevented, since at the end of the scenario another drill-up is made and the details never need to be displayed in the GUI.

For 3.

To use of the macro functions DRILL_DOWN() and DRILL_UP() in macros which are to be executed in batch, additional, stricter conditions apply beyond the notes above. Ensure that the following points are observed when defining your macros:

• You have read and observed Note 412429 in the definition of your macros.

• Within a job, data can be changed and saved on only one hierarchy level. It is generally NOT possible to change and save data on different hierarchy levels within a single job. This strongly restricts the use of the macro functions DRILL_DOWN() and DRILL_UP(). After changing data on a certain hierarchy level, the hierarchy level must not be changed by executing the macro functions DRILL_DOWN() or DRILL_UP() under any circumstances.

• The use of the macro function DRILL_UP() in background does not make sense. The only imaginable scenario would be drill-up, calculation. Instead, a job definition is recommended that uses the aggregate level directly, so that no drill-up is required before the calculation.

• To use the macro function DRILL_DOWN() in background, there is only one practical scenario, that is drill-down, calculation. Contrary to the drill-up scenario, this drill-down scenario can thoroughly be practical, for example in the following situation:

You have the characteristics LOCATION and PRODUCT and the two following characteristic values combinations exist:

L1, P1

L1, P2

You want to execute calculations on a detailed level (LOCATION and PRODUCT). There are two possibilities for this. To explain these, let us suppose you have defined three macros. One macro CALCULATION that executes the desired calculations, one macro DRILL_DOWN that only executes the drill-down for PRODUCT and one collective macro COLLMACRO that first calls up the macro DRILL_DOWN and then the macro CALCULATION.

a) You define a job that is to work on a detailed level (LOCATION and PRODUCT) and execute the macro CALCULATION. Then the processing in background is done in such a way that the macro CALCULATION is executed for every characteristic combination one after another.

b) You define a job that is to work on the level LOCATION and to execute the macro COLLMACRO.

In this case, the macro COLLMACRO is called up once, that is on the level LOCATION. Then, a drill-down by PRODUCT is done, so that the macro CALCULATION has access to all detailed data and processes them internally step by step. In this way, a performance gain can be achieved, because the job needs to call up the macro only once with a single characteristic combination and everything else is processed internally by the macro itself.

In addition, the macro CALCULATION is provided with the data for the two products P1 and P2 at the same time, and it can access both. This allows for the realization of more complex calculations than in the first case.

• Always use the macro function DRILL_DOWN() with the additional, optional parameter 'INTERNAL', if the macro is to be executed only in the background.

• The restrictions that apply for use of the macro functions DRILL_DOWN() and DRILL_UP() in macros executed in the background can be avoided by appropriate definitions of the jobs and the respective macros. For this, define macros which conform to the restrictions above. Use the macro function DRILL_DOWN() only when it is absolutely necessary (see above). Note that the macro function DRILL_DOWN() must never be executed after a calculation on a certain level within one job.

If you want to execute calculations on different levels, use several jobs and define the level on which you want to work already in the job itself. If you have to comply with a certain processing order, concatenate the different jobs by defining the completion of the desired predecessor job as the start condition when scheduling a subsequent job.

• Ensure the aggregate level of the job has been defined appropriately when you use the DRILL_DOWN() macro function in a background job. If you want to excecute a 'drill-down' on a certain characteristic in the background, under no circumstances can you select this characteristic when you choose the characteristics for the aggregate level. If you do select this characteristic, then the planning data relating to this characteristic is already read in detail when the background job is excecuted. Consequently a corresponding 'drill-down' is no longer possible.

Header Data

Release Status:	Released for Customer
Released on:	04.02.2005 12:38:01
Master Language:	German
Priority:	Recommendations/additional info
Category:	Consulting
Primary Component:	SCM-APO-FCS-MAC MacroBuilder
Secondary Components:	SCM-APO-SNP-MAC MacroBuilder

Affected Releases

Software Component Release From Release To Release And subsequent SAP_APO 30 30A 30A SAP_APO 310 310 310 SCM 400 400 400 SCM 410 410 410 SCM 500 500 500 SCM 510 510 510

Related Notes

	1045639 - Consulting notes in SNP/CTM
	954223 - Mass processing: Not possible to run only at aggregate level
	674238 - MacroBuilder: Start, final, level change and default macros
	539797 - Collective consulting note on macros
	495166 - Tips and Tricks for Handling Alert Monitor