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

External Consistency Checks Using /SAPAPO/CIF_DELTAREPORT3

source: Best Practice: Data Consistency Between SAP R/3 and SAP APO 3.0/3.1

Report CIF_DELTAREPORT3 can be used to check the external consistency of the majority of transaction data used in APO (such as production orders, planned orders, sales orders, stocks, and so on).
It makes the following data checks:
• It only checks transaction data.
• It only checks that the data exists. It then compares important quantities and times. The level of detail varies between the different transaction data compared.
• The quantity is also checked for stocks.
Goal and Prerequisites
Report /SAPAPO/CIF_DELTAREPORT3 ensures that the data transferred using the Core Interface (CIF) is or remains consistent between SAP R/3 and SAP APO. If inconsistencies between the systems are detected, you can also use this tool to repair them. This report corrects problems quickly and easily. In the majority of cases, CIF can be used to resend the missing data. However, you need to completely understand the CIF model and integration between SAP APO and SAP R/3. This includes knowledge about master and transaction data in the relevant SAP R/3 and SAP APO systems. If inconsistencies occur between the systems, it is always advisable to analyze the causes of the error, to be able to rule out software errors, for instance. Knowledge of ABAP is also useful to be able to perform on-site error analyses.
Depending on the system settings in SAP APO, changes to transaction data are only listed and are not transferred synchronously to SAP R/3. This results in these changes being identified as inconsistencies, although they are not. Therefore, it is necessary to set a change pointer when the data is transferred from SAP APO to SAP R/3 before running /SAPAPO/CIF_DELTAREPORT3. You use transaction /SAPAPO/C5 to do this.
Technical System Prerequisites
• SAP APO Support Package 19
• PI.2001.1 with the associated note prerequisites. See SAP Note 458164.
Use
To start the report in SAP APO 3.0, you use transaction SE38, program name /SAPAPO/CIF_DELTAREPORT3. As of APO 3.1, you can use transaction /SAPAPO/CCR.
Online processing: The only field of the entry screen in which you have to make an entry is the Partner System field. You can choose any individual object types that you want to be checked.
Important Notes
• Making fewer restrictions when selecting data and choosing a large variety of object types will cause the runtime of the transaction to be longer. If the quantity of data you have chosen is too large, there is the possibility that a short dump (‘TIME_OUT’) will occur. In this instance, you have to run the report in background processing or reduce the quantity of data.
• You should start the compare/reconcile report only if there is a small data load in the Core Interface. For instance, you could do this during the night, when no planning runs that would generate CIF-relevant documents are taking place. Otherwise, the report could display ‘false’
inconsistencies due to runtime problems. You can use SAP Note 496779 or SAP APO 3.0A to prevent this from happening.
• You should not start the compare/reconcile report during initial data transfer or a delta compare/reconcile.


Background Processing
Before you can start a background processing run, you have to create suitable variants for program /SAPAPO/CIF_DELTAREPORT3. Note the following when doing this:
• Compare/reconcile reports can be run in parallel. Create multiple variants for report /SAPAPO/CIF_DELTAREPORT3 (see above). When defining the variants, note that the selected object types cannot overlap. To ensure this, you can assign a dedicated variant to each object type (sales order, production order, purchase requisition, and so on).
• You should start the compare/reconcile report only if there is a small data load in the Core Interface. For instance, you could do this during the night, when no planning runs that would generate CIF-relevant documents are taking place. Otherwise, the report could display ‘false’ inconsistencies due to runtime problems. See SAP Note 496779 from SAP APO 3.0A Support Package 21.
• You should not start the compare/reconcile report during initial data transfer or a delta compare/reconcile.
Verification/Subsequent Processing
Online Processing
Once the compare/reconcile is complete, an output screen appears, displaying an overview of the results. This is done separately according to documents (orders) and stocks. A line is displayed for every object type selected on the screen for testing, showing the following information:
• Total: The number of SAP R/3 objects that have been selected for comparison
• Error: The total number of errors found
• All other columns: Distribution of errors to individual error areas
A tab page displaying detailed lists of the individual faulty orders or stocks is displayed for every object type that is shown to have errors in the results overview.
In the case of orders, there is an additional tab page on every tab page for an incorrect object type listing the orders that were found in SAP R/3 but that are missing from SAP APO.
If required, execute a reconcile.
• Choose a tab page showing a detailed list of incorrect objects and select the lines you wish to reconcile (to make multiple selections, hold down the CTRL button at the same time).
• Choose the Send to APO button to start the reconcile.
• In the dialog box that appears, confirm that you have initiated the Send.
The current state of the data is read from the database. Then, the data is transferred asynchronously using the standard CIF interface of the object type.
A selection icon appears beside the selected lines in the Sent/Action column indicating that the Send has been initiated for the relevant objects. An object that has a selection icon cannot be resent, even if it is reselected for this purpose.

Background Processing
The spool list is the result of the compare function in background mode. To view the spool list for a job that ended without errors, choose your job in the job overview (transaction SM37), choose Spool, choose your spool list from the spool list overview, and choose Display (F6). As of APO Support Package 7, you also have access to all detailed lists of the faulty objects. To view these, see the spool list beside the summary results overview of the comparison for documents and stocks.
Compare/Reconcile Report Performance
In general, the consistency compare/reconcile of /SAPAPO/CIF_DELTAREPORT3 has four stages.
Stage 1: It evaluates the integration models to be checked. The runtime of this stage is linearly related to the size of the integration model.
Stage 2: It selects the data. We cannot provide a blanket statement about performance for this stage. The runtime is determined by the relationship between filter objects and the data objects to be checked. We cannot provide a general recommendation. For more detailed information, see SAP Note 439438.
Stage 3: It checks that the data exists in APO. After the integration models are evaluated and the corresponding data is read from SAP R/3, SAP APO is checked to see that the corresponding data exists here. The runtime is linearly related to the size of the integration model.
Stage 4: It checks whether the APO data does NOT exist in the SAP R/3 system. If you have a large integration model, this step will have a shorter runtime.
Important notes:
　
• For more information, see SAP Notes 439438 and 451446.
• To optimize the runtime, change the block size of the filter object. We cannot provide a general recommendation for the block size of the filter object since the ideal setting is always based on the relationship between the filter objects and the data objects to be checked.

Safety Stock Planning

The standard methods of safety stock planning are used to build stock on hand
according to the safety stock values that you define in the location product master,
depending on previous experience. In contrast to model-based safety stock planning, forecast errors are not considered when you use the standard methods. You can maintain the safety
stock value as a static or time-dependent value. You can change the safety stock
values manually in interactive Supply Network Planning.

The advanced methods of safety stock planning are used to calculate the
time-dependent safety stock for finished products and components. In this type
of planning, the system takes into account the demand forecasts and forecast
errors within your supply chain.

Supply Network Planning (SNP) allows you to consider the actual supply
when planning safety stock. This means that, not only can the system take
forecast demand and actual demand into account, but it can also consider the
deviations between the planned Replenishment Lead Time (RLT) and the actual
Replenishment Lead Time.

The calculated safety stock is displayed in an SNP key figure in interactive
planning and can be changed manually or copied into another planning version, if
required. The calculated safety stock can also be used in both Production Planning
and Detailed Scheduling (PP/DS) and in Capable-to-Match.

If you keep safety stock both in the plant and in Distribution Centers (DCs), the
system uses the model-based calculation to take this into account. The system
always calculates the replenishment lead time starting from the last safety stock
leading location.

Calculating Safety Stock
Safety Stock Calculation Methods
• Available safety stock methods:
– SB Safety stock from location product master
– SZ Safety days' supply from location product master
– SM Maximum of SStk and SZ from location product master
– MZ Safety days' supply (maintained on a time-dependent basis)
– MB Safety stock (maintained on a time-dependent basis)
– MM Maximum of MB and MZ (maintained on a time-dependent basis)
– ATα service level and reorder cycle method
– ASα service level and reorder point method
– BTβ service level and reorder cycle method
– BSβ service level and reorder point method
If you want to use the standard methods (methods 1-3), go to the lot size tab page
of the location product master and enter the relevant data in the following fields:
• Safety stock
• SB method (safety stock method)
• Safety days' supply

To manually create safety stock on a time-dependent basis (methods 4-6), use a
macro to enter the safety stock or safety days' supply - on a time-dependent basis -
in the interactive planning table of SNP, and save the SB method on the lot size tab
page of the location product master. Mass maintenance of time series was put in
place for Release SCM 4.1 (transaction /SAPAPO/TSKEYFMAIN). Time-dependent safety stocks are stored in time series of the key figure
9ASAFETY. If you also want to plan these stocks in PP/DS, you must
assign this key figure in PP/DS Customizing.

The advanced methods of safety stock planning take the accuracy of Demand
Planning forecasts into account. To calculate the safety stock, you need to enter the demand planning key figures of your planning area that contain both past forecasts and realized demand.
The forecast errors are determined from the past data. Safety stock planning uses
relative forecast errors and the relationship from forecast errors and forecasts,
which can differ from one time bucket to the next. For the realized demand, select a key figure that contains the actual demand realized. These values can be updated from sales orders or invoiced sales quantities, etc., from the OLTP systems. For the planned demand, select a key figure that contains the forecast figures generated in the past.

As an alternative, errors for forecasts and replenishment lead times can be predefined in the location product master record (on the Lot Size tab page).

Note 428147 - Extraction of data from an SNP planning area

Note 428147 - Extraction of data from an SNP planning area

Summary

Symptom

When extracting data from an SNP planning area, you must take account of some special features. These are explained in this note.

Solution

1. Data can be extracted only for existing SNP aggregates.
Existing SNP aggregates are:

• 9AAC (9AACTNAME - APO Activity)
  

• 9AACPR (9AACTNAME, 9APPMNAME - APO PPM/PDS Name)

• 9ALA (9ATRNAME - APO Transportn Lane)

• 9ALO (9ALOCNO - APO Location)

• 9ALORE (9ALOCNO, 9ARNAME - APO Resource)

• 9AMA (9AMATNR)

• 9AMALA (9AMATNR, 9ATRNAME)

• 9AMALARE (9AMATNR, 9ARNAME, 9ATRNAME)

• 9AMALO (9ALOCNO, 9AMATNR)

• 9AMALORE (9ALOCNO, 9AMATNR, 9ARNAME)

• 9AMAPR (9AMATNR, 9APPMNAME)

• 9AMARE (9AMATNR, 9ARNAME)

• 9APR (9APPMNAME)

• 9ARE (9ARNAME)

• 9AREPR (9APPMNAME, 9ARNAME)

Only the characteristic/characteristic combinations contained in these aggregates may be used in the InfoSource, transfer structure and transfer rules.The simplest way of doing this is by always generating Export-DataSources for SNP planning areas to one of the aggregates and not to the Basis planning object structure '9ASNPBAS'.A typical result of using the Basis planning object structure '9ASNPBAS' without correcting the transfer structure is that, while data is transferred to a RemoteCube, it cannot be extracted in a BasisCube.
As of APO 3.0 Support Package 17 (or note 443613), only export DataSources for aggregates can be generated in SNP planning areas, they are no longer generated for the Basis planning object structure.
Furthermore, note that the navigation attributes 9ATTYPE, 9ALOCTO, and 9ALOCFROM up to APO 3.0 Support Package 17 (or note 441653) must be deleted from the transfer structure for the SNP aggregates '9AMALA' (9AMATNR/9ATRNAME) and '9AMALARE' (9AMATNR/9ATRNAME/9ARNAME). These navigation attributes can be used from the specified correction.
Due to technical restrictions the characteristics '9ATRNAME' and '9ATTYPE' can only be restricted with single values in the selection for the data extraction.The use of intervals and formatting characters (+/*) is not allowed for these characteristics.

2. For an SNP aggregate, only the key figures assigned to it can be extracted. You can see which key figures are assigned to an aggregate in transaction /SAPAPO/MSDP_ADMIN on the Key figure assignment tab of the relevant planning area. As of APO 3.0 Support Package 17 (or note 439366), only the key figures assigned to this aggregate are taken into account when an export DataSource is being generated for aggregates.

3. During the definition of queries, the following restrictions apply:

In the case of queries for the aggregate '9AMALA', certain key figures can only ever be extracted with another key figure.The key figure combinations that can only be extracted together are:

• (9AFSHIP, 9ADMDDF, 9ADMDDFVMI)

• (9AFSHIPLP, 9ADMDDFLP)

• (9AFSHIPVMI, 9ADMDDFVMI)

• (9APSHIP, 9ADMDDI, 9ADMDDIVMI)

• (9APSHIPLP, 9ADMDDILP)

• (9APSHIPVMI, 9ADMDDIVMI)

• (9ATSHIP, 9ADMDDT, 9ADMDDTVMI)

• (9ATSHIPVMI, 9ADMDDTVMI)

Header Data

Release Status:	Released for Customer
Released on:	02.01.2003 09:56:17
Master Language:	German
Priority:	Correction with medium priority
Category:	Consulting
Primary Component:	SCM-APO-FCS-EXT Extraction
Secondary Components:	SCM-APO-SNP Supply Network Planning (SNP)

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 415 415 415 SCM 500 500 500 SCM 510 510 510

Related Notes

	1045639 - Consulting notes in SNP/CTM
	837004 - Values from auxiliary key figures are not extracted
	657774 - SNP data extraction: Error "Invalid data status"
	549184 - FAQ: What is important for extraction
	540571 - Collective consulting note on data extraction in DP
	453644 - No use of navigation attributes in SNP
	441653 - SNP: Data extraction to transportation lanes
	373756 - Data extraction from a planning area

SNP Planning Area Aggregates

Aggregates is nothing but storing the data at that particular aggregate level,say for example 9ALORE is aggregate at your location and resource level.

If some of keyfigures assigned to this aggregate then you can store the data at this combination.(example 1) your capacity value of resource at plant level).

If you add new keyfigure in planning area that keyfiure by default assigned to 9ABAS level ,then you need to assign this keyfigure to your particular aggregate level by using table /sapapo/tspaplob.

IF you add any time series Key figure, in SNP planning Area then it will automatically assigned to all the Aggregates.
---------
Purpose of Aggregates:

Data can be saved in aggregates as well as on the lowest level of detail. An aggregate contains a subset of the characteristics in the master planning object structure.

the purpose of aggregates in APO is : to speed up data access and therefore increase performance.

Below aggregate are provided by sap with standard SNP functionality as soon as you make your MPOS SNP possible it add below aggregate in your PA.

9ALA
9ALORE
9AMALA
9AMALARE
9AMALO
9AMALORE
9AMAPR
9AMARE
9ARE
9AREPR

you can also create your own aggregate in a master planning object structure of APO by clicking with the right mouse button on the master planning object structure in S&DP Administration and choosing Create aggregate.
Source:https://www.sdn.sap.com/irj/scn/message?messageID=6027404


Another purpose for SNP aggregates is for data backup purpose:

 Data can be extracted only for existing SNP aggregates. Existing SNP aggregates are:

• 9AAC (9AACTNAME - APO Activity)

• 9AACPR (9AACTNAME, 9APPMNAME - APO PPM/PDS Name)

• 9ALA (9ATRNAME - APO Transportn Lane)

• 9ALO (9ALOCNO - APO Location)

• 9ALORE (9ALOCNO, 9ARNAME - APO Resource)

• 9AMA (9AMATNR)

• 9AMALA (9AMATNR, 9ATRNAME)

• 9AMALARE (9AMATNR, 9ARNAME, 9ATRNAME)

• 9AMALO (9ALOCNO, 9AMATNR)

• 9AMALORE (9ALOCNO, 9AMATNR, 9ARNAME)

• 9AMAPR (9AMATNR, 9APPMNAME)

• 9AMARE (9AMATNR, 9ARNAME)

• 9APR (9APPMNAME)

• 9ARE (9ARNAME)

• 9AREPR (9APPMNAME, 9ARNAME)

Only the characteristic/characteristic combinations contained in these aggregates may be used in the InfoSource, transfer structure and transfer rules.