Thursday, July 30, 2009

Configure Transfer to OLTP Systems


IMG, Advanced Planning and Optimization->Supply Chain Planning->Supply Network Planning (SNP)->Basic Settings->Configure Transfer to OLTP Systems


In this IMG activity, you set how orders that are created, changed, or deleted during SNP planning, are transferred to an OLTP system. The following options are available:

  • No Transfer: The orders are not transferred to an OLTP system.
  • Immediate Transfer: The orders are transferred to an OLTP system immediately during SNP planning.
  • Periodic Transfer: The orders are first collected together and are then able to be transferred to an OLTP system using the CIF (APO Core Interface) transaction Process Change Pointer.

You can also exclude certain types of orders from transfer, such as SNP stock transfers where no source location exists.

For the processes of aggregated planning and planning with aggregated resources, you can define which orders you want to be transferred that were created at the different levels of a location product hierarchy. The default value is that only the orders for the sub products (suborders) are transferred.

For deployment, you can also specify whether you want the deployment stock transfers generated in the deployment run to be transferred to the OLTP system as a stock transport requisition or a stock transport order.

In addition, it is still possible to choose between a Vendor Managed Inventory (VMI) scenario and a non-VMI scenario.


If you have specified that you want deployment stock transfers to be transferred as stock transport orders to the OLTP system, they cannot be planned again or changed.

Note that the settings you make in the CIF transaction User Settings, can overwrite the settings made here. The following rules are valid:

  • CIF setting Default: The settings that are made within this SNP IMG activity are valid.
  • CIF setting Collect changes: The orders are first collected (periodic transfers). The CIF setting overwrites the SNP setting.
  • CIF setting Do not collect changes: The orders are transferred immediately during planning. The CIF setting overwrites the SNP setting.

If you set No transfer in this SNP IMG activity, the orders are not transferred, even if another setting has been made in the CIF transaction.

Wednesday, July 29, 2009

How to delete material master in APO?

How to delete Material master in APO? (I have material and location)?
How do we delete the transaction data and dependent master data?

This is not a plain thing to delete a product master/location product in a production system.

You have to carry out the following steps:

1. Pre-steps:

a) Remove product from integration model

b) Delete all orders for this product-location which still exist in the APO system by running the reports /SAPAPO/RLCDELETE or /SAPAPO/DELETE_PP_ORDER (this report is not recommanded to be used in product system!!) or transactions /SAPAPO/RRP4 or /SAPAPO/RRP4.

c) Use transaction /sapapo/ccr to delete all objects in APO that are integrated with R/3. The /sapapo/ccr will show the orders as 'Not in an active integration model' and offers to delete the orders in APO

d) Delete the product from ATP tables by running the report /SAPAPO/SDORDER_DEL with the selection according to the product being deleted.

e) Delete all related product substitution and location product substitution using the transaction /SAPAPO/RBA04;

f) Delete the product from all PPMs through the transaction /SAPAPO/SCC05;

g) Remove the product from external procurement using the transaction /SAPAPO/PWBSRC2;

h) Remove the product from transportation lanes through the transaction /SAPAPO/SCC_TL1 or /SAPAPO/SCE; Note: If the lane was created with option 'All products', you should not care about this condition.

i) Remove the product from quota arrangement through the transaction /SAPAP/SCC_TQ1;

j) Remove references from the product master or the location product master using the transaction /SAPAPO/MAT1, tab 'Classification';

k) Remove the planning package from the location product master using the transaction /SAPAPO/MAT1, tab 'PP/DS';

l) Remove the product from RTO;

m) Remove the product from product split.

2. Mark deletion flag

a) In transaction /SAPAPO/MAT1, select the product (and location in case of location product);

b) In the menu bar, choose 'Product' and go to 'Mark for deletion' (Shift+F6);

c) In the popup 'Set deletion Flag' set a flag in the appropriate field: Leave the field 'Product' empty unless you want to delete the product master, i.e. in case a location product must be deleted, the flag has to be set on location only;

d) The deletion can be executed directly or be scheduled for another time.


Note 1058871 - Poor performance of product allocation check



During an ATP check in SCM with product allocation as one of the step in basic methods, bad performance or response time is too high. This is due to the number of characteristic combinations to be checked during the allocation check.

Other terms

Performance, response times, product allocation check, PAL.

Reason and Prerequisites

Number of characteristic combinations and direct connection to planning area. Product Allocation Check is performed in SCM.


If the performance of ATP check due to allocation check has longer run times please check the following -

- The number of characteristic combinations.
- Check if setting direct connection to planning area is defined in product allocation group.

When the characteristic combinations have reached 100,000 try to reduce them to improve performance. If it is not possible to reduce the number of characteristic combinations deactivate direct connection to planning area in the prodcut allocation group. This will improve the performance of allocation check.

If connection to planning area is deactivated, data between planning and allocation tables has to be synchronized by copying planning data periodically to allocation tables using transaction /SAPAPO/ATPQ_PAREA_R to reflect changes in allocation quantities (KCQTY) and also transfer data to planning area using transaction /SAPAPO/ATPQ_PAREA_W to update incoming order quantities (AEMENGE).

Header Data

Release Status:

Released for Customer

Released on:

25.05.2007 16:56:11

Master Language:



Recommendations/additional info



Primary Component:

SCM-APO-ATP-BF-PAL Check against Product Allocations

Secondary Components:

SCM-APO-ATP Global Available-to-Promise

Tuesday, July 28, 2009

Note 676128 - Product allocations: Product allocation assignment check



You execute the correction report 'Correct product allocation assignment'.
You can find the report in the SAP Menu under 'Advanced Planning andOptimization' -> 'Global ATP' -> 'Environment' -> 'Product Allocations' -> 'Repairs'.

Other terms

Product allocation, APO product allocation assignment, ATP, QUOT, report: /SAPAPO/RMQUOT_USAGE_CHECK, /SAPAPO/SAPLATPQ_REPAIR

Reason and Prerequisites

  • The incoming orders quantity is the total of the reserved product allocation quantities in a period. The incoming orders quantity cannot be assigned to any individual document. The incoming orders quantity is stored in the same time series as the product allocation quantity.

You can normally display the incoming orders quantity in the planning tool (for example, Demand Planning) together with the product allocation quantity. It should not be manually changeable there.

The incoming orders quantity is subtracted from the product allocation quantity in the product allocation check. The rest is available to the document that was just checked.

If the incoming orders quantity is greater than the product allocation quantity in a period, the product allocation quantities in the adjacent periods are reduced in accordance with the product allocation settings.

If the incoming orders quantity was manually reduced (or not fully updated), this may result in an overconfirmation when you change the document during the repeated availability check.

  • The product allocation assignment is equivalent to a where-used list of the product allocation quantity. The product allocation assignment is stored for each item (for which a product allocation check was carried out).

The product allocation assignment is created when you execute the product allocation in the availability check. The product allocation assignment is always assigned exactly to the time series (special time series or collective product allocation time series) that was used during the check.

The product allocation assignment can be displayed in the product allocation time series display (transaction /SAPAPO/AC42) by double-clicking on the incoming orders quantity. The system first displays all users of the selected period. From there, you can display the entire product allocation assignment for each item.

  • A time series is used in the product allocation to store the product allocation quantity (available quantity) and the incoming orders quantity.

It is identified by a characteristics combination. The product allocation group defines which characteristics are used for this.

  • A characteristics directory, which includes all allowed or defined characteristics combinations, is managed for each product allocation group.

The characteristics directory is used to assign the product allocation time series to the planning time series when you transfer or copy the time series from the Demand Planning.

The check terminates with an error if no defined characteristics combination is found during the product allocation. If the characteristics combination is defined, but no time series or an empty time series is maintained, no quantity is confirmed for this item.

When you search for characteristics combinations or time series, the system only takes into account those with the 'active' status (normal product allocation) and the 'neutral' status (pure update - the quantity requested in the product allocation is completely confirmed). Time series with the 'inactive' status are interpreted as undefined.

You can display and maintain the characteristics directory in transaction /SAPAPO/ATPQ_CHKCHAR. However, you can only create characteristics combinations using the planning tool.

  • Collective product allocations are time series with specific characteristic values. To avoid having to define every possible characteristic combination (as otherwise the check terminates with an error) or having to maintain time series for each of these characteristics combinations, you can use collective product allocations.

If no time series is found for the characteristics combination from the document currently being checked, the last characteristic of the combination is filled with a wildcard character and the characteristics list is then checked again. The search continues until a characteristics combination has been found or all the characteristics have been replaced.

    • If no characteristics combination is found, the check terminates with an error (see above)
    • If a characteristics combination is found, the check is carried out against this combination (see above).

The search for collective product allocation is only carried out at the beginning of the product allocation and is independent of the check result.
Therefore, if an insufficient quantity is found in a time series (the allocation is exhausted), no search is triggered for (additional) collective product allocations.

You can activate the use of collective product allocations for each product allocation step by specifying the wildcard character.
You can use transaction /SAPAPO/ATPQ_COLLECT to generate or add to the characteristics combinations of the collective product allocations.

The total of all product allocation time series (including the collective product allocation) in a product allocation group corresponds to total available quantity in a period.

  • You can change the status of a characteristics combination while the system is running. If you set the status of a special time series (no collective product allocation) to 'inactive', it is no longer visible within the product allocation. The check searches for a collective product allocation and then uses it for the check.

By hiding the time series, you also reduce the total available quantity (see above). You can therefore 'simultaneously' hide the time series and repost the allocations from the hidden time series to the collective product allocation time series (manually, in the planning tool).
However, if product allocations were already taken from the special (now hidden) time series, the corresponding portion is missing in the incoming orders quantity of the collective product allocation time series. These reposted product allocation quantities of the collective product allocation could therefore be debited again.

When you change the status of the characteristic combinations or in the case of those correction possibilities described in the following, the system asks you whether you want to repost these product allocation assignments. The system then reposts the product allocation assignment from the special hidden time series to the next more general 'active' collective product allocation time series.

This transfer posting is only necessary if the product allocation quantities were also reposted in the planning accordingly. If the system only reposted the free product allocation quantities, it is not necessary to repost the product allocation assignment.

In this case, the assignment of the product allocation assignment for the special time series does not disappear (this only applies to the product allocation assignments posted before the status change). You can reactivate the hidden time series. In this case, the correction report takes their product allocation assignments from the collective product allocation time series again and posts them into the special time series.

If a check is run against the special time series when you create a document and against the collective product allocation time series when you change a document, the product allocation assignment is reposted from the special time series to the more general time series. If you reactivate the special time series, you can no longer repost this assignment into it.
Therefore, reposting only allows generalization but not specialization. You can only achieve specialization by using another check, for example, backorder processing (BOP).

Of course, you can also set the status for collective product allocation time series. If a collective product allocation time series is 'hidden', the system searches for a more general time series during the search for a defined characteristic combination (as described above).


You can use the report to compare (and, if necessary, to correct) the product allocation assignment and the incoming orders quantity.
The sum of the product allocation assignments of a period is generally equal to the incoming orders quantity in the time series.
You can use the report to check (and, if necessary, correct) this consistency under different aspects. You have the following options:

  • Assignment without incoming orders quantity
    The total of the product allocation assignments in a period is compared to the incoming orders quantity in a time series. The result of this comparison is displayed with a traffic light.
    • green Both quantities correspond.
    • yellow The incoming orders quantity is greater than the total of the product allocation assignments.
      This situation may occur, for example, as a result of a relocation of the product allocation from R/3 into APO. The incoming orders quantity could also have been deliberately increased to reserve a product allocation quantity.
    • red The incoming orders quantity is smaller than the product allocation assignment.
      This situation may occur if you manually reduced or did not fully update the incoming orders quantity.

To correct the incorrect periods, you must select all periods of a time series. Use the 'Combine product allocation assignment' function ('Goto' in the menu, or the button) to flag the selected time series for repair.

Then use the 'Execute' function to start repairing the flagged time series.
The system asks:

    • whether you want to transfer the product allocation assignment for the incoming orders quantity.
    • whether you want to add the product allocation assignment of inactive time series for the incoming orders quantity of the more general collective product allocation time series (as described above).
  • Incoming orders quantity without assignment
    The system checks whether the time series contains incoming order quantities to which no product allocation assignment is assigned (also see the yellow traffic light under the section 'Assignment without incoming orders quantity').

The display and functions are identical to those in 'Assignment without incoming orders quantity'.

  • Assignment without order item
    The system checks whether there are product allocation assignments that cannot be assigned to any item.

This situation may occur if the order documents are incompletely deleted (for example, due to notes being incompletely imported) or already archived.

There are two different options for the repair (the deletion):

    • You can either delete only the product allocation assignment (Menu: 'Goto' -> 'Delete individual assignment') without adjusting the time series. The relevant incoming order quantities are then displayed with yellow traffic lights with one of the above options the next time you run this report.

The product allocation quantity assigned up to now remains assigned and cannot be used by other documents. If the items were archived, this procedure is correct.

    • Alternatively, you can delete the product allocation assignment with incoming orders quantity (Menu: 'Goto' -> 'Delete individual assignment with IO quantity'). The incoming order quantity of the relevant time series is reduced accordingly.

As a result, the product allocation quantity assigned up to now is released and can be used by other documents. If the item was not fully deleted, this procedure is correct. Otherwise, this may result in overassignments (if the product allocation quantity can be 'achieved' in accordance with the consumption settings).

The entries selected for repair are flagged with one of these two functions. You can then use the 'Execute' function to start deleting these characteristics combinations or to repair the affected time series.
As described above, the system asks you whether you want to add the product allocation assignment of inactive time series for the incoming orders quantity of the more general collective product allocation time series.

  • Assignment without product allocation group
    In contrast to the previous options, you cannot use the restriction by product allocation groups in this case. The specifications in the selection are ignored.

The system displays all product allocation assignments that:

    • belong to product allocation groups that no longer exist in the Customizing.

These product allocation assignments are created as a result of incomplete system copies, or if the product allocation assignments are not deleted if a product allocation group is deleted in the Customizing.

    • belong to characteristics combinations that are no longer defined in a product allocation group.

These product allocation assignments are created if you delete a characteristics combination from the characteristics directory (for example, when you transfer the characteristics combinations from a planning area (transaction /SAPAPO/ATPQ_PAREA_K), but do not delete their product allocation assignment.

You can select and delete the product allocation assignments in the display. You cannot adjust the time series in the product allocation group. The adjustment is not possible and unnecessary because the assigned characteristics combination of the time series no longer exists, which means that no relevant time series can be identified.

As described above, the characteristics combinations that you want to delete can be selected and then flagged for deletion (menu 'Goto'). You can then use the 'execute' function to delete the product allocation assignments.

You can only use manual entries or actions to execute the report described here. In the case of large product allocation groups, the runtime of an online transaction may be insufficient to execute the report.
You can also use transaction /SAPAPO/ATPQ_KCGRP_U to carry out the time series comparison (as described under 'Assignment without incoming orders quantity').
In this case, the incoming orders quantity is always set to the total of the product allocation assignment of a period (that is, the yellow and the red traffic lights of the above display disappear). You can restrict the area to be corrected to a period of the time series.

Header Data

Release Status:

Released for Customer

Released on:

04.11.2003 16:17:04

Master Language:



Recommendations/additional info



Primary Component:

SCM-APO-ATP-BF-PAL Check against Product Allocations

Affected Releases



























Related Notes

624539 - /sapapo/sdorder_del: Extended check for allocation

619525 - Display Product Allocation Group using ALV list Grid

569270 - Report /SAPAPO/ATPQ_CHKUSG returns inconsistent line items

553902 - Allocations: Improved performance for prod. allo.

553403 - Allocations: incorrect correction for incoming orders quant.

552140 - Allocations: Performance during LC recovery

527863 - Allocations: Program termination /SAPAPO/RMQUOT_USAGE_CHECK

527153 - Allocations: product allocation check - incorrect display

514199 - Prod. alloc: Order receipt quantity w/o prod. alloc. assgmt

496809 - Allocations: /SAPAPO/ATPQ_KCGRP_U terminates

494607 - Allocations: Product allocation assignment check incorrect

493015 - Allocations: Function error prod.alloc. assignment control

484199 - Allocations: Deleting incoming orders qty during correction

483370 - Allocations: Updating the product allocation assignment

481096 - Addition to consistency check TP/VS for prod. allocat. TDL s

433427 - Allocations: incorrect transfer of characts. combinations

433157 - Product allocations: comparison report (performance)

425825 - Consistency checks, /sapapo/om17, /sapapo/cif_deltareport

422669 - Allocations: Runtime error OBJECT_NOT_FOUND

422042 - Allocations: No display in the comparison report

418949 - Allocations: Incorrect display in the comparison report

412363 - Allocations: Recovery terminates with RFC error

403541 - Product allocations: Runtime error OBJECT_NOT_FOUND

384749 - Prod.allocations:Incoming orders qty not corrected

331512 - Allocations: Incoming orders qty w/o assignment

313717 - Allocations: Runtime error PARAMETER_FAILURE

195366 - Allocations: Loss of order receipt quantity

Wednesday, July 22, 2009

Product Allocation Determination

  1. Upon entry of the sales order into the OLTP system, the product allocation procedure is read from the ATP product master record.
  2. If a sequence of product allocation procedures exists, the subsequent procedures are read from this product allocation sequence.
  3. There could be a number of steps for each product allocation procedure. Each step is associated with a product allocation group.
  4. In each product allocation group there may be multiple product allocation objects that cover a corresponding data area.
  5. For each product allocation object, there is a time series of planned product allocation quantities associated with a set of characteristics.
  6. The first procedure is determined from the ATP tab page in the product master, corresponding to the product of the sales order item. If the location-dependent product allocation procedure is missing, then the location-independent procedure is used.
  7. The first step in the procedure is examined. Based on the sales order date, a valid product allocation object and its associated characteristics/time series is examined, if and only if there is a matching characteristic with or without the wildcard character. If there are matching characteristics and remaining available quantities, a product allocation is made.
  8. If the first step fails, the second/next step is examined. Each step should be designed to check for product allocation objects with fewer or more general characteristics (Example: From customer/DC level in step 1 to DC level only).

Tuesday, July 21, 2009

Product Allocatoin Object

The system takes into account different product allocation control phases during the overall constraint period.

You can assign several product allocation objects to the product allocation procedure. A validity period exists for each object. The system determines the relevant object on the basis of the check date. The system then uses this object to determine the corresponding planning hierarchy that contains the product allocations.

Objects are always valid from the end date of the last object. To switch off the product allocation for a certain period, you have to define a dummy object and set it to inactive.

The system allows three types of check dates:

Delivery date

Material availability date

Planned goods issue date

You can maintain time-dependent conversion factors for your product allocation objects in Customizing.

Monday, July 20, 2009

Sunday, July 19, 2009

R3 System Overview

Introduction of R3 system

The kernel and basis services component is a runtime environment for all R/3 applications that is hardware-, operating system- and database-specific. It is written in C and C++ and some ABAP.

Database: The applications do not communicate directly with the database. Instead, they use Basis services.

Communication: R/3 applications can communicate with other R/3 Systems and with non-SAP systems. It is also possible to access R/3 applications from external systems using a BAPI interface. The services required for communication are all part of the kernel and basis services component.

ABAP workbench is written in ABAP.

The message server is responsible for communication between the application
servers. It passes requests from one application server to another within the system.

Software layer distribution:
A common configuration is to run the database system and a single application server (containing special database services) on one host, and to run each further application server on its own host. The presentation layer components usually run on the desktop computers of the users.

Dialog step between presentation layer and application layer:

Application Server
Work Processes
An application server contains work processes, which are components that can run an
application. Each work process is linked to a memory area containing the context of the application being run. The context contains the current data for the application program. This needs to be available in each dialog step.

Each application server contains a dispatcher. The dispatcher is the link between the work processes and the users logged onto the application server. Its task is to receive requests for dialog steps from the SAPgui and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.

Each application server contains a gateway. This is the interface for the R/3 communication protocols (RFC, CPI/C). It can communicate with other application servers in the same R/3 System, with other R/3 Systems, with R/2 Systems, or with non-SAP systems.
The fact that the individual work processes work independently makes them suitable for a multi-procecssor architecuture

A mapping process projects the required context for a dialog step from shared
memory into the address of the relevant work process. This reduces the actual copying to a minimum.
Local buffering of data in the shared memory of the application server reduces the number of database reads required. This reduces access times for application programs considerably.

Database Connection
When you start up an R/3 System, each application server registers its work proceses with the database layer, and receives a single dedicated channel for each. While the system is running, each work process is a user (client) of the database system (server). You cannot change the work process registration while the system is running. Neither can you reassign a database channel from one work process to another. For this reason, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. This has important consequences for the
programming model explained below.

A dialog step from a program is assigned to a single work process for execution.
The individual dialog steps of a program can be executed on different work processes, and
the program context must be addressed for each new work process.
A work process can execute dialog steps of different programs from different users.

The SAP programming model contains a seies of bundling techniques that allow you to group database updates together in logical units. The section of an R/3 application program that bundles a set of logically-associated database operations is called an SAP LUW. Unlike a database LUW, a SAP LUW includes all of the dialog steps in a logical unit, including the database update.

Work Processes

An R/3 System is distributed across more than one application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not
often change.

Different types of Work Process:

Dialog Work Process
Dialog work processes deal with requests from an active user to execute dialog steps.

Update Work Process
Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.

Background Work Process
Background work processes process programs that can be executed without user interaction (background jobs).

Enqueue Work Process
The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.

Spool Work Process
The spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain only one spool work process.
The services offered by an application server are determined by the types of its work processes.

One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.

You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.