/sapapo/atpq_chkusg

Product allocation assignment check

/sapapo/ccr

Comparison-Reconciliation of transaction data

/sapapo/sdrqcr21

Correction report for delivery req. and sales req.

/sapapo/sdorder_del

Delete SD orders from database

/SAPAPO/CCR Comparison-Reconciliation of transaction data

Check consistency between the APO system and one or more dedicated R/3 systems.
Inconsistencies may occur if at least one of the systems crashes and cannot be fully recovered again.In the same way,
inconsistently deleting CIF queues or unwanted user settings can cause inconsistencies.

Usage:

In background, test mode only. But possible to save the results so that they can be quickly reloaded in foreground
and then the fixing of the inconsistencies can be manually done.
Iteration functionality allows to quickly recheck that the reported inconsistencies are still inconsistent or repaired

It only checks transaction data used in APO (production orders, planned orders, sales orders, stocks and so on).
Sometimes, depending on system settings in APO, data changes made in APO are not being transferred synchronously to
R/3 (for instance the VMI orders you transfer to R/3). As a result, "false" inconsistencies were being reported (change

pointers are still in /sapapo/c5).

You can run the report in parallel by creating variants for the different object types. Make sure that the different
objects selected do not overlap.

/sapapo/atpq_chkusg - Product allocation assignment check

program name: /SAPAPO/RMQUOT_USAGE_CHECK
You can use the report to compare and 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.
To make sure that the system has consistent status is of high importance and should therefore be checked on a regular
(daily or weekly depending on the number of inconsistencies) basis.
This report has to be started online and requires manual interaction to correct inconsistencies. The report is often scheduled
in the background, to evaluate the spool lists only. If there are errors, it is started manually.
It is strongly recommended to run the report online.
It is possible to run this program in the background with an automated update of the checked items using the following
workaround:
Create a Batch Input for the program /SAPAPO/RMQUOT_USAGE_CHECK via SAP Menu: System -> Services -> Batch
Input -> Record (see note 676128 for further details).

/SAPAPO/SDRQCR21- Correction report for delivery req. and sales req.

This report corrects incorrect sales order and delivery (requirements) in SAP R/3 / ECC and SAP APO/SCM.

checks precisely the SD order tables

doesn't check inactive integration models. Therefore, it is not a perfect substitute for

/SAPAPO/CIF_DELTAREPORT3
schedule the report /SAPAPO/SDRQCR21 on a weekly basis

can't be run during operation hours, its long runtime might be a bottleneck

should be used only you have reliable VBBE table

The following improvements were integrated into /SAPAPO/SDRQCR21 with note 987299:
1. The possibility to check specific order numbers or order items.
2. Iteration
The report first selects orders in SCM, then in R/3 and compares the selected orders. A new check is triggered in case of
inconsistencies until the inconsistencies disappear or the maximum number of iterations is reached.
3. Table /SAPAPO/OBREF
The report can find and correct a wrong document flow including document flow from Stock Transfer Orders to deliveries.
4. More accurate evaluation and correction of Product Allocation Assignments.
5. For performance reasons when selecting Product Allocation, it is possible to exclude fully delivered orders and/or only to
check Sales Orders or Stock Transfer Orders.
6. Redesign of the requirement recompilation
If you use the option to build requirements from the document flow, a very long runtime may occur and the requirements are
re-created without document blocks. Therefore, inconsistencies may occur during the operation. With the new version of the
report for which notes 998102 and 1023543 are prerequisites, a new logic for recompiling requirements is introduced. The
following new switches are available which allow you to use the report during system
operation. The first Flag 'Lock documents...' sets a document block if the requirements from table VBBE are rewritten in the
R/3 system. This prevents the document from being changed at the same time. The second flag writes a planning file entry
(net change per material/plant) in the R/3 system if the requirement situation has changed. The next MRP reads this and
plans accordingly.

/SAPAPO/SDORDER_DEL - ATP:Delete SD orders from database

This report can be used to delete old sales order data from the APO database tables and / or APO livecache.

should be executed regularly e.g. weekly

No system downtime is necessary to execute this report

The only side effect can be that not all records which are obsolete are removed because they are processed by

parallel transactions. But no inconsistencies should occur.

system performance might be negatively impacted, however, this should not be a major concern.

it is recommended to run this report using different variants due to performance reason

Concerning Product Allocation deletion, please note the importance of the field date (until to)
/SAPAPO/SDORDER_DEL only deletes data from tables in the SCM system. The R/3 system is not cleaned up.
First tab :
This first tab is used to delete obsolete data in the APO database. The purpose of this deletion is to prevent the tables from
growing too big which would slow down the APO system. The report should be scheduled on a regular basis typically once a
week for Selective deletion and once a month for Adjust ATP tables with /sapapo/posmapn and Delete obsolete
records in the /sapapo/posmapn table .
Second tab:
The 2nd tab should not be used in combination with the 1st tab.
The 2nd tab should be used in exceptional cases when you want to delete live data (still in Livecache) which you cannot
delete by other means (such as the deltareport or the /sapapo/sdrqcr21 report). This deletes both the Livecache data and
the database tables data.

Third tab:
This deletes all data from the database without any check !!!

Backorder Processing
Batch BOP
In Batch Backorder Processing (or backorder processing in the background), items are selected according to specific key
fields (using filters) and brought into a processing sequence for the availability check (by means of the sort). The previously
confirmed quantities are rejected and an ATP check is carried out for all selected items in the defined sequence. A new date
can thereby be determined. The results are always held in a buffer. Depending on the execution mode, the results can be
updated afterwards, processed, or rejected later.

Interactive BOP (BOPI):

With interactive backorder processing you can manually redistribute confirmed quantities of one or more products
specifically over a quantity of selected requirements. You can call the function directly or use it as a postprocessing function
of batch backorder processing.
The aim of interactive backorder processing is to manually assign a confirmed quantity to requirements schedule lines.
Schedule line dates can be changed, deleted, or created.

BOP Performance
There are many BOP entries for items that have been ran by BOP either simulation or update.
Delete as many as possible BOP runs existing in the system. This will eliminate the entries in tables: /SAPAPO/BOP
This you can perform in transaction: /SAPAPO/BOP_DELETE:
use it to delete BOP results older than 7 days; if necessary the date can be set even closer to the current date
to delete BOP results in status 'U' this status has to be selected explicitely
/SAPAPO/BOP_RESULT performance
The 'Original Requirements/Confirmation Situation' variant displays the ATP situation BEFORE and AFTER the bop. This
situation is stored on the data base table and will never change.
The 'Current Requirements/Confirmation Situation' display version will select the AFTER values from another set of data
base tables (the passive ATP trees) and compare it to what is currently in Live cache.
SAP recommend to use the BOP_RESULT display variant 'original requirement/confirmation situation' for two reasons:
1.) It is much faster since it reads directly from the data base and does not recalculate the change in the confirmation
situation item per item
2.) It is more comphrehensible since it always displays the same situation BEFORE and AFTER the BOP

ATP log
The availability check process can be logged by activating the ATP application log for error analysis by technically oriented
users, developers or consultants.

It collects information about customizing settings, the technical and time aspects of the check as well as warnings and errors
that occurred.
The ATP log should only be switched on for a short time (considerable performance decrease of the system!) and only for
specific users.
Transactions:
Create ATP log for a user: /SAPAPO/ATPLOG
Display the ATP log: /SAPAPO/ATPLOG_DSP
Delete ATP Log: /SAPAPO/ATPLOG_DEL

Application classes:
BAP: BAPI interface of the APO

BOP: Treatment of arrears

EAS: Explanation and simulation component

EVR: Rule evaluation

FCK: Basic method examination against vorplanung

PAC: Basic method product liquidity check

PAL: Basic method imposition of quotas

PAT: Persistente ATP Baumstuktur

PRD: Production

SCH: Time limitation

TQA: temporary quantity allocations

TRC: ATP CONTROLLER

Capable-To-Promise (CTP)
You can configure if Production Planning and Detailed Scheduling is called automatically when a product is not completely
available.
If the former product availability check fails, GATP can trigger production directly.
In this case corresponding method in PP/DS will be called which creates planned orders for all ressources in PPM and also
checks the availability of the components.
The result will be transferred to ATP which makes the neccesery changes in the sales order (after accept the delivery
proposal).
APO makes changing in ATP time series and PP/DS transfers the simulated planned order to R/3.

Correlation

Added by Tibor Nagy, last edited by Tibor Nagy on Jul 26, 2011
Correlation
The correlation is about gathering results from lower level objects to a higher level object in the ATP object structure stored
in the memory.

This can be done from component groups to the finished product level, and e.g. from substitutions to main item level.
Propagation is the other way round, it takes the results of a higher level objects, and updates the related lower level objects'
results to correspond to the higher level.
Correlation Services:
The Correlation Service provides correlation functionality for delivery groups and sales BOMs. Normally this is done during
the availability check, but if the caller application needs only new correlation, it can call the Correlation Service.
Example:
In the Extended Warehouse Management the picking of a KIT fails. One product has less quantity in the warehouse than the
needed, so less KIT can be transported. This case the EWM calls the Correlation Service to determine the reduced
quantities for the other components.

CTP

Added by Anjali Butley, last edited by Anjali Butley on Jul 27, 2007
Capable to Promise (CTP) : is a GATP method calling PP/DS during ATP check.

EDQA Event-Driven Quantity Assignment

Added by Tibor Nagy, last edited by Tibor Nagy on May 19, 2011 (view change)

EDQA

System should be able to react instantly on positive changes in the stock/requirements situation by distributing
the free quantity to backordered sales items waiting to be confirmed.
Depending on the events mentioned above, the system has to distribute the quantity according to particular rules:
Range of order items that have to be confirmed

Sort sequence of selected order items in the range

If all waiting sales orders are confirmed, the still available quantity may have to be deployed to other facilities via
push deployment
Supporting different Goods receipt status

Uses Order Due Lists (ODL) where backorders are stored and filtering and sorting of the sales order items is
possible

EDQA Process is triggered by activities

Change Purchase Order Document

Change Sales and Distribution Document

Change Stock Data

Selection criteria can be defined for the EDQA Process

EDQA triggers via a workflow event an ODL based backorder (BOP) processing

can do a Reassignment of Order Confirmations (ROC)

Transactions:

Define Processes for Event-Driven Quantity Assignment (TA /SAPAPO/EDQA_PD)

Assign Events of Event-Driven Quantity Assignment (TA /SAPAPO/EDQA_ED)

Processes of Event-Driven Quantity Assignments (TA /SAPAPO/EDQA)

Forecast Check
You execute a check against the forecast if you want to know if enough planned independent requirements are available for
the incoming sales orders.

GATP Product Allocation

Added by Anjali Butley, last edited by Anjali Butley on Jul 23, 2007 (view change)
Building Block
S57 ATP for Product Allocation
http://help.sap.com/bp_scmv150/BBLibrary/documentation/S57_BB_ConfigGuide_EN_DE.doc
Building Block
S59 Demand Planning for Product Allocation
http://help.sap.com/bp_scmv150/BBLibrary/documentation/S59_BB_ConfigGuide_EN_DE.doc
Help :
Product Allocation Settings:
http://help.sap.com/saphelp_scm50/helpdata/en/26/c2d63b18bc7e7fe10000000a114084/frameset.htm
Product Allocations Settings
Purpose
You make all the relevant settings to carry out product allocations in APO.
Process
Before you make the settings for product allocations, you must first analyze the business process on which this check is
based. You should ask the following questions:

1.

Which criteria are used for assignments and allocations?

For example, sales organization, customer or distribution channel

2.

Do unused quantities from earlier periods, which could be used in an availability check for the current period,
exist?
If yes, how long is the consumption period? How many past and future periods should be included in the current product
allocations check?

3.

Should product allocations be carried out in one or more steps? Example:

1. Step: Evaluate product allocation quantities at plant level
2. Step: Evaluate product allocation quantities at customer level
We recommend that you group the periods and consumption periods together as described in the following example in order
to obtain consistent results between the individual steps. Note: the flexibility of the product allocations check is increasingly
restricted with each step. The steps must be sorted in descending order - similar to a funnel - according to the length of the
consumption period. The periodicity is thereby insignificant.
Example
01.01.9

Periodicit

Consumption period

STEP 1

Monthly

from -1 to +3 (12/97-4/98)

STEP 2

Weekly

from -2 to +5 (50/97-6/98)
Calculation Example For which period should the allocation be active?For example,

STEP 3

Daily

from -4 to +4

01.01.99-05.31.99.Theplanning areas should be structured similarly to the product

(27.12.97-

allocation groups. Planning areas may be more detailed, but not rougher in structure than

05.01.98)

the product allocation groups.

Before planning begins, you should prioritize the product allocations (that is, decide
which characteristics combinations receive what percentage of the total product
allocation quantity).
See also:Maintaining Field CatalogsCreating Product Allocation ObjectsCreating
Product Allocation Groups Creating Product Allocation Procedures Creating Sequences
of Product Allocation Procedures Maintaining Check InstructionsConnection to the
Planning Area

MATP

Added by Anjali Butley, last edited by Anjali Butley on Jul 23, 2007 (view change)
Link of the Building Block of the Multi Level ATP is as below:
http://help.sap.com/bp_scmv150/BBLibrary/documentation/S31_BB_ConfigGuide_EN_DE.doc
Help Doc of Multi level ATP :
http://help.sap.com/saphelp_scm50/helpdata/en/26/c2d63b18bc7e7fe10000000a114084/frameset.htmhttp://help.sap.com/sa
phelp_scm50/helpdata/en/26/c2d63b18bc7e7fe10000000a114084/frameset.htm

Multilevel ATP Check

Added by Tibor Nagy, last edited by Tibor Nagy on Nov 05, 2009 (view change)

Multilevel ATP Check (MATP)

MATP will be used in cases when a large part of the value-added activity arises at final assembly.
Already at the time of order entry all components will be checked which are necessery for the production of the final product.
During MATP an ATP-Tree Structure is getting created during saving of the sales order in the APO-Database and represents
the BOM Structure, enhanced with Material/Location substitutions (RBA).
Receipt elements are only generated later when the ATP tree structure is converted in PP/DS.

Transactions
/SAPAPO/RRP_ATP2PPDS: Conversion of ATP tree structures to receipt elements

ODL Order due list

An order due list is a list of the most important orders you have taken that have not been confirmed, or the least important
ones that have been confirmed.
The systems goal is to confirm the orders that havent been (that are on the ODL), or to potentially de-confirm the ones that
have been, if higher priority orders come in for the same product.

Transactions:

Configure Order Due Lists (TA /SAPAPO/ODLC)

Process Order Due Lists (TA /SAPAPO/ODL)

Display Change Log (TA /SAPAPO/ODL_LOG)

Initial ODL Creation / Reorganization (TA /SAPAPO/ODLR)

Further informations
http://help.sap.com/saphelp_scm70/helpdata/en/45/8e2c9855de40c0e10000000a1553f7/frameset.htm

Product Allocation
With PAL you can allocate products for specific customers or regions depending on the period.
If you use product allocations in situations in which a product is in short supply, you can avoid allocating the entire available
quantity to the first customer, which either delays the confirmation of subsequent sales orders, or makes confirmation
impossible.

In Product Allocation delivery dates and quantities will be checked against the allocation quantities in certain periods.
If delivery proposal will be accepted, the corresponding allocation quantities will be reduced with the delivery quantity.

Transactions

/n/SAPAPO/AC42

to get overview of Product Allocation Situation (needs: product, location, PAL group, PAL object)
/n/SAPAPO/ATPCQ_CHECK

to check the customizing (needs: PAL procedure)

/n/SAPAPO/ATPQ_CHKCUST
to check product allocation assignments for one sales order

/sapapo/atpq_chkusg - Product allocation assignment check

program name: /SAPAPO/RMQUOT_USAGE_CHECK
You can use the report to compare and 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.
To make sure that the system has consistent status is of high importance and should therefore be checked on a regular
(daily or weekly depending on the number of inconsistencies) basis.
This report has to be started online and requires manual interaction to correct inconsistencies. The report is often scheduled
in the background, to evaluate the spool lists only. If there are errors, it is started manually.
It is strongly recommended to run the report online.
It is possible to run this program in the background with an automated update of the checked items using the following
workaround:
Create a Batch Input for the program /SAPAPO/RMQUOT_USAGE_CHECK via SAP Menu: System -> Services -> Batch
Input -> Record (see note 676128 for further details).

Product Availability Check

Checking the availability of a product based on the ATP quantity.
The ATP quantity is calculated based on storage stock, planned receipts and planned issues.
Parameters for PAC are defined mainly in the check instruction, the ATP group and the check control.
You can specify the following check parameters:

Cumulation (/SAPAPO/V_ATP01-ONVBA)

How to deal with shortages (no cumulation = no shortage check)

where to customize: ATP group (spro: APO > gATP > PAC > Maintain ATP Group)

Check control
various customizing:

o
o

scope of check (what receipts to check)

consider past receipts? (use receipts with due dates in the past for confirmation?)

check horizon? (any amount can be procured after a certain amount of days?)
check sublocation or batches? (how detailed a check should be)

o
o

where to customize: ATP group (spro: APO > gATP > PAC > Maintain Check Control)

business event + ATP group => check control

ATP check using the time series vs. pegging network

To do this characteristic-based PAC, the production type in the check mode has to be set to

"characteristic evaluation"
whether to create internal deltas/TQAs (/SAPAPO/V_ATP00-ACENQ)
whether to create temporary quantity assignments (TQAs) to keep track of requirements in a sales order

in process/not yet saved

RBA

Added by Anjali Butley, last edited by Sudhir Gulati on Oct 17, 2008 (view change)
Rule based ATP Check: ATP Check based on Rule set by user as per the business processes to select the alternate
product, location

Rules-based availability check (rules-based ATP)

If the requested product is not available, the system automatically searches for the product in an alternative location or looks
for a similar product using user- specific predefined rules.

1.

SAP Help : http://help.sap.com/saphelp_scm50/helpdata/en/f4/b877377fae0261e10000009b38f842/content.htm

2.

For Building Block check the GATP building block

a.
i.

ATP-GATP : http://help.sap.com/bp_scmv150/BBLibrary/HTML/ATP_EN_DE.htm
3.

Business Scenario for application of RBA : https://forums.sdn.sap.com/thread.jspa?threadID=194807&tstart=0

Rules-Based ATP Check

The rule-based availability check is an iterative process, meaning that each step defines the subsequent check step based
on the rules saved in the system.

Possible steps:

Determining alternative locations (location determination),

Determining alternative products (product substitution),

Determining alternative production process models (PPM).

Searching for substitutions will be stopped if an acceptable result of the check is available.
Some possibilities with RBA:

Only one substitution is also possible.

Production can be triggered in alternative locations.

Stock transfer can be triggered in alternative locations.

Transactions

/SAPAPO/RBA04: Integrated Rule Maintenance

/SAPCND/AO11: Create Rule Determination

Sales Integration
Sales Integartion deals with:

the saving from R/3 to APO of:

Quotations, sales orders, contracts, scheduling agreements, normal deliveries, stock transfer deliveries (=Replenishment

deliveries), VMI Sales orders, VMI deliveries

the saving from APO to R/3 of:

VMI sales orders, sales orders processed by /SAPAPO/BOP

several reports:
/sapapo/cif_deltareport3 (for sales docs only) = transaction /sapapo/ccr
/sapapo/sdrqcr21
/sapapo/sdorder_del
SCM-APO-INT-SLS deals only with the applicative part of the transfer of sales documents.
Technical communication problems of the CIF interface or problems with the status of queues (RETRY, SYSFAIL...) belongs
to the SCM-APO-INT component.
The coding of the SCM-APO-INT-SLS component is located on both R/3 and APO side.

Transactions

/n/SAPAPO/SDORDER_DEL to delete obsolete data from LiveCache and APO Database.

/n/SAPAPO/SDRQCR21 to check and fix sales documents requirements inconsistencies between R/3 and APO.

/n/SAPAPO/CCR - external consistency check for requirement inconsistencies between R/3 and APO Livecache.

/n/sapapo/om17 - internal consistency check between Livecache and APO Database.

Temporary quantity assignments (TQA)

They are used to inform ATP checks executed in parallel transactions about given confirmations. They are necessary to
span the time between the check and the final saving of the confirmation (thru saving the requesting order item). There are
internal deltas, which are used to keep track of changes in own transactions and external deltas (or TQAs) which keep track
of external transactions.

Frequent problem:
Documents with number "<unknown>" in ATP are always temporary quantity assignments. If the order number was known at
the time of running the ATP check, the TQA carries the order number,
otherwise it carries <unknown>. The TQA carries order number <unknown> until either the item is converted or a new ATP
check is executed.

The system behaviour should be fine after the deletion of the hanging TQA's
Deletion of TQA-s:
You can delete the old assignements with the report /SAPAPO/om_delta_remove_older (via SE38).
Alternatively you can delete the TQA's manually. Use transaction /SAPAPO/AC06.
You must be careful not to delete quantity assignments that are still required. These vary

according to the scenario used.

The CTP temporary requirements are not integrated to either the transaction /SAPAPO/AC06 or to the report
/SAPAPO/OM_DELTA_REMOVE_OLDER, like the normal TQA.

Third-Party Order Processing

In this process, you do not supply the customer yourself. Instead, you assign another supplier or dealer to deliver the
products requested by the customer. In third-party order processing, you can ensure that the requirement is confirmed as
quickly as possible without accepting cancellations or backlogs.
The following types of third-party order processing are available:

Third-party order processing by source determination (TPOP)

Third-party order processing by product allocation (TPOPD)

Transactions
/SAPAPO/TPOP_POREL

Conversion of Planned Purchase orders

/SAPAPO/TPOP_ASSIGN Create product location assignments for the vendors

The TPOPD scenario is called as Dealer-to-dealer scenario, as it was developed for car dealers. It is also called as third
party order processing with product allocations.

Time and Scheduling Functions

In the Transportation- and Shipment Scheduling the following dates and durations (activities) are used:
Dates:

ELDAT (Unloading Date) (only APO)

LFDAT (Delivery Date)

WADAT (Goods Issue Date)

LDDAT (Loading Date)

MBDAT (Material Availability Date)

TDDAT (Transportation Planning Date)

Activities:

UNLD (Unloading) (only APO) source: conditions

TRAN (Transit) source: 1. lane, 2. conditions, 3. dist.

LOAD (Loading) source: conditions

PICK (Picking) source: conditions

LEAD (Planning) source: conditions

Generally we have 3 phases during the scheduling: 1. shipping, 2. transportation, 3. receiving

The first is for the activities(and dates) what are carried out in the location-from.

The second is for activity what is carried out during the transportation.

The third is for the activities(and dates) what are carried out in the location-to.
From SCM 4.0:

The shipping calendar of the location-from is used for the 1. phase

The calendar of the transportation lane(or route) is used for the 2. phase.

The receiving calendar of the location-to is used for the 3. phase.

Transactions

/n/SAPAPO/SCHED_TEST to simulate the scheduling in APO

/n/SAPCND/AU13 to check the Scheduling Condition Types

/n/SAPAPO/CALENDAR to check the calendar

/n/SAPAPO/SCC_TL1 to check the transportation lane

CIF - Frequently Asked Questions

Attachments:1
Added by Somnath Manna, last edited by Wilian Segatto on Feb 16, 2012 (view change)

Purpose

The purpose of this page is to present the Frequently Asked Questions (FAQ) in the Core Interface (CIF) Area (SCM-APOINT*).

Questions and Answers

List of Questions

What does CIF stands for?

How should I start on the Integration of the Systems?

How do I generate Integration Models?

How do I activate my Integration Models in foreground?

How do I activate my Integration Models in background?

My Material Master objects have changed. What do I do?

My Transactional Data has changed. What do I do?

I have created new data. Will this be transferred automatically to APO?

How do I transfer all data again?

Can I schedule a job to update my Integration Models and transfer new data?

Which operations of a routing or recipe in R/3 or ERP are transferred to APO PPMs?

What determines the validity period of a resource in liveCache?

What needs to be done to debug CIF related enhancements?

How can transaction data be reconciled with APO from R/3 or ERP side?

Which table stores Change Pointers in ERP or R/3?

Which report can be used to clear Change Pointers in ERP or R/3?

What is Customer Consignment Stock and how is it transferred to APO?

What is Vendor Consignment Stock and how is it transferred to APO?

How is Stock information stored in APO?

What are the userexits for Integration of Stocks?

How is Inspection Lots handled in APO?

How is Cross-company Stock In Transit handled in APO?

What does CIF stands for?

CIF stands for Core Interface. It is the interface for data transfer between an ERP system (SAP R/3 or SAP ERP) and a
connected SCM system, such as SAP Advanced Planning and Optimization (SAP APO) or SAP Supply Network
Collaboration (SAP SNC).
The basis for the data transfer is the Integration Model on the ERP side.

How should I start on the Integration of the Systems?

The Integration is made by using Integration Models, which are packages of data to be transferred.
Examples of objects an Integration Model can contain:

Material/Plant information

Planned Orders and Production Orders

Purchase Requisitions and Purchase Orders

Sales Orders

Stocks

Batches

You should generate Integration Models for all data you want to be present in the SCM system.
Depending on the volume of data, you might have to split your Integration Models.

How do I generate Integration Models?

To start, go to transaction /CFM1 (report RIMODGEN) on the R/3 side.

Select your logical system (maintained in /SM59 and in /CFC1).

Name your Integration Model (e.g. "EMEA Data") and its Application (e.g "Sales Orders", "Prod. Orders").

Select the data you want to send. Maintain additional information in the right panels (Material, Plant, etc.).
You might have to click the right arrow to expand specific panels for each option.

Click Save. Models will be generated.

Please note that the Models are generated in a inactive mode. You have to activate the models to transfer the data.

How do I activate my Integration Models in foreground?

Go through transaction /CFM2 (report RIMODACT) on the R/3 side.

Enter your Integration Model data (Logical System and Model name is enough)

Execute

Double click in the model you want to activate

Click the red "X" icon. It will change to a green checkmark.

Press "Start"

Data will be transferred and Model will be active.

How do I activate my Integration Models in background?

Go through transaction /CFM3 (report RIMODAC2) on the R/3 side.

Enter your full Integration Model data (Model name, Logical System and Application)

Choose the option "Activate Newest Version"

In the Program Menu, select the option "Execute in Background (F9)".

Data will be transferred and Model will be active.

You can also create a (periodic) job for this task in /SM36

My Material Master objects have changed. What do I do?

The objects already in an active Integration Model are automatically transferred to APO when changed in R/3 if you have
activated the Immediate Transfer of Objects in the /CFC9 transaction. In this case the objects are immediately updated in
APO.

My Transactional Data has changed. What do I do?

All transactional data that refers to a Material Master object that is in an active Integration Model is automatically transferred
to the APO system.

I have created new data. Will this be transferred automatically to APO?

No. Your new data must be in an active Integration Model. For this, you will have to generate and activate your Integration
Model again.
By generating the model again and by activating it, you will be able to transfer the objects that were changed or created
since the last run.
Important! Note that the activation of the IM must be done in one step.

Generate new IM (/CFM1)

Enter RIMODACT (/CFM2). In the next screen, click on the red "X" of the first entry (just created).

Hit save.
If you do this procedure in two steps (deactivate old model, save, activate new model, save), you will be doing an initial
transfer one more time, which can lead to high volumes of data being transferred again.

How do I transfer all data again?

Using the two-step Integration Model activation explained above or

Running report RIMODINI

Can I schedule a job to update my Integration Models and transfer new data?
Yes, you can!

Create a /CFM1 Variant

Create a /CFM3 Variant

In transaction /SM36, create a new job

Add as step 1 the RIMODGEN execution

Add as step 2 the RIMODAC2 execution

It's recommended that you also create a job for report RIMODDEL. There is no need create a variant to execute it. This job will c
Inactive IMs in Table CIF_IMOD

Which operations of a routing or recipe in R/3 or ERP are transferred to APO PPMs?
When PPMs are created in APO from Receipes in R/3 only those phases containing non-zero machine times are brought
over. Other phases having only labour (resource category 003) or machine time (resource category 001) = 0 does not come
through.

What determines the validity period of a resource in liveCache?

CFC9 parameter in R/3 does not set the From/to validity date for Resources when Work Centres are CIFed from R/3 to
APO. Actually that is set as per entry in table /SAPAPO/RESLCT - Length of Time Stream or Bucket Vector in liveCache.

What needs to be done to debug CIF related enhancements?

In order to debug CIF related user exits or other CIF queues, set the R/3 RFC user (e.g. STGUSER) to Dialog user and then
set queues to Debugging On/Record T/QRFCs in the transaction CFC2 in R/3. This is for queues coming inbound to APO.
For queues coming inbound to R/3 set the APO RFC user id (e.g. APSUSER)

How can transaction data be reconciled with APO from R/3 or ERP side?
Program RCIFORDT can be used to reconcile transaction data form R/3 side. Refer 733110 - as a long term solution
implement this BADI on APO side
OSS Notes 627630, 804034 on R/3 side and with the BADI OSS note 800286 to be applied

Which table stores Change Pointers in ERP or R/3?

The table BDCPV is to store Change Pointers in both APO and R/3. Refer OSS Note 329110.

Which report can be used to clear Change Pointers in ERP or R/3?

Program RBDCPCLR can be used to clear change pointers from the Change Pointer table. The message type CIFSRC is
for changes to Source of Supply (i.e. Purchasing Inforecords). The CIF Change Transfer program (CFP1) can fail due to a
large number of records in the Change Pointer table. Other message types are CIFMAT for material, CIFVEN for Vendor
Master, CIFCUS for Customer master.

What is Customer Consignment Stock and how is it transferred to APO?

Consignment stock at Customer is stock at customer premises but owned by the supplier. Prerequisite to have Consignment
Stock at Customer is Customer as a Location and Product Master at that Customer Location. To transfer Customer
Consignment Stock from ERP to APO both "Customer" and "Special Stock at Customer" should be part of an Integration
Model during Initial Transfer. For Consignment Stock Batches "Storage Location Stock" object must be included in the
Integration Model.
Reference: Note 409298

What is Vendor Consignment Stock and how is it transferred to APO?

Vendor Consignment stock is stock at the plant location and treated as normal storage location stock but owned by vendor.
Vendor Consignment Stock is transferred from ERP to APO as part of "Storage Location Stock" Integration Model. However
the Vendor must be part of an active Integration Model.

How is Stock information stored in APO?

Stock in SCM APO system (upto 4.1) consists of Stock Anchor stored in Database and Stock Item stored in liveCache. The
liveCache Consistency Check (transaction /SAPAPO/OM17) carries out the consistency check between the APO Database
and liveCache. It should be executed periodically to delete obsolete stock anchors from the database.
Reference: Note 492591
As of SCM 5.0 Stock information is stored in liveCache table /SAPAPO/STOCKANC.
Reference: Note 837744

What are the userexits for Integration of Stocks?

On R/3 side the userexit is enhancement CIFSTK01 while on APO side it is enhancement APOCF011. The source code in
the userexit should be copied to the CIF Compare/Reconcile Report (Delta Report) BAdI (method
RELEVANT_FOR_COMPARE_R3_STOCK of BAdI definition /SAPAPO/CIF_DELTA3) for correctness of the report.
Reference: Note 492591

How is Inspection Lots handled in APO?

From SCM 4.0 Inspection Lots are separate objects in APO retaining the end dates. Hence Inspection Lots quantities does
not shows up as Stock in Quality Inspection.

How is Cross-company Stock In Transit handled in APO?

Cross-company Stock In Transit is determined dynamically in R/3 and hence not transferred to APO. In APO Stock In Transit
at the receiving plant can be handled by transferring Inbound Shipping Notification or Goods Confirmations from R/3.

SCM-APO IMPORTANT TRANSACTION CODES

Added by Sankar M, last edited by Michel Bohn on Feb 14, 2012 (view change)
/SAPAPO/AMON1 - Alert Monitor
/SAPAPO/AMON3 - Alert Overview by Objects
/SAPAPO/AMONMSG_SEND - Send Alerts
/SAPAPO/AMONMSG_SEND - Send Alerts
/SCMB/ANOT_PROF - Create/Change Alert Notification Profile (User)
/SCMB/ANOT_PROF - Create/Change Alert Notification Profile (User)
/SCMB/ANOTMP - Create/Change Message Profile
/SCMB/ANOTMP - Create/Change Message Profile
/SCMB/ANOTMP - Create/Change Message Profile
/SAPAPO/PE_LOG_DISP - Display PSM Application Log
/SAPAPO/PE_SEL - Define Selections
/SAPAPO/PE_SEL - Define Selections
/SCMB/TDL_BO_COPY - Define Service Profile for Copying Time Series
CCMS Related
RZ20 - CCMS Monitor Sets
RZ23N - Central Performance History (CPH)
RZ03 - Control Panel
SM66 - Global Process Overview
SM49 - Execute External Commands

performance related Tcode:

ST03N - Aggregated Statistics Records - Local
ST03G - Aggregated Statistics Records - Global
STAD - Individual Statistics Records (ABAP Only)
STATTRACE - Individual Statistics Records (All) and Traces
ST07 - User Distribution
ST02 - Buffers
ST10 - Table Accesses
TU02 - Parameter Changes
OS06 - Activity
OS04 - System Configuration
OS03 - Parameter Changes
OS07 - Activity
OS05 - System Configuration
OS03 - Parameter Changes
OS01 - LAN Check with PING
AL15 - SAPOSCOL Destination

Database:
ST04N - Activity
DB01 - Exclusive Locks
DB02 - Tables/Indexes
DB03 - Parameter Changes
SM21 - System Log
ST22 - ABAP Runtime Errors
AL11 - SAP Directories
SM50 - Process Overview
SM66 - Global Process Overview
SM51 - SAP Instances
SM04 - Local Users
AL08 - Global Users
RZ10 - System Profile
SMLG - Logon Groups
SM69 - Display/Change External Commands
DB Admin:
DB12 - Backup Logs
DB13 - Local
DB13C - Central
DB14 - Operations Monitor
DB20 - Create Statistics
DB21 - Configuration

print related:
SP01 - Output Controller
SPAD - Spool Administration
SE73 - Font Maintenance
SP11 - TemSe Contents
SP12 - TemSe Administration
background Processing:
SM37 - Jobs - Overview and Administration
RZ01 - Job Scheduling Monitor
*Process
Process Chain relatedChain related Transaction codes: Transaction codes:*
RSPC - Process Chain Maintenance
RSPC - Process Chain Maintenance
RSPC_RESTART - Restart Process Chain Run
RSPC1 - Process Chain Display
RSPC1_NOLOG - Process Chain Maintenance
RSPC2 - Process Chain via Process
RSPCM - Monitor daily process chains
RSPCP - Process Log
RSPC_RESTART - Restart Process Chain Run
RSPC1 - Process Chain Display
RSPC1_NOLOG - Process Chain Maintenance
RSPC2 - Process Chain via Process
RSPCM - Monitor daily process chains
RSPCP - Process Log

RSIMPCUST : regularly synchronize the Factory Calendars between ECC and APO by using program RSIMPCUST
in APO.
The timestreams can be regularly updated using program /SAPAPO/TIMESTREAM_UPDATE
Batch Job
SM50

You can also check the ST06 --Detail analysis --> compare recent day --> CPU load. Are the CPU utilisation fine
Check ST03N to find out what is causing the problem
- You can run the performance trace by ST05
SM65 .. Goto ... Additional Tests
note #48400:
RSPO0041 (or RSPO1041), RSBTCDEL: To delete old TemSe objects
RSPO1043 and RSTS0020 for the consistency check.