CIF Customizing in the ERP System

Step
Check ALE settings and
activate, as required:

Transaction
SALE

Obligatory?
Obligatory

Define the logical system

Assign logical system to
client
Define the RFC destination SM59
Set up the target system and CFC1
assign the queue type
If you set the Inbound
Queue queue type in the
ERP system, you have to
register CIF queues (CF*)
in the QIN scheduler in the
SCM system.
Maintain SCM release
Set number ranges for
parallelization
Activate BTEs for
integration
Register CIF queues in the
QIN scheduler if you have
changed to inbound queues
in the SCM system

Obligatory
Obligatory

NDV2
CFC7

Obligatory
If needed

BF11

If needed

SMQR

If needed

CIF Customizing in the SCM System

Step
Check ALE settings

Transaction
SALE

Obligatory?
Obligatory

SM59
/SAPAPO/C1

Obligatory
Obligatory

/SAPAPO/C2

SNSCLNT001 to BSG_01

CFC1

Obligatory

Define the logical system

Assign logical system to
client
Define the RFC destination
Maintain business system
group
Assign Logical System to
Business System group
Assign logical system and

queue type
If you set the Inbound
Queue queue type in the
SCM system, you have to
register CIF queues (CF*)
in the QIN scheduler in the
ERP system.
Register CIF queues in the SMQR
QIN scheduler if you have
changed to inbound queues
in the ERP system
Register CIF queues in the SMQS
QOUT scheduler, if you
have configured outbound
queues in the ERP system
Maintain distribution
/SAPAPO/CP1
definitions
Create customer exits for
CMOD (Customer Exits)
uniquely identifying master
data. For more information, SE19 (Business Add-Ins)
see the Implementation
Guide (IMG) for SCM
Basis.
Posted by Hai Zeng (James) at 8:33 PM
Labels: CIF, SNC

If needed

If needed

Obligatory
If needed

1 comment:
Hai Zeng said...
CIF related Transaction:
Cfc1 Maintain Queue Types
Cfc2 User specific settings for Queues
Cfc9 Master Data Settings for Online Transfer or Periodic Change Transfer
Cfm1 Create Int.Model
Cfm2 Activate Int. Model
Cfm4 Display Int.Model
Cfm5 Search for Int.Model
Cfm6 Change Int.Model
Cfm7 - Delete Int.Model
Smq1 Outbound Queue Monitor
Smq2 Inbound Queue Monitor
Smqr QIN Scheduler
Bd50 Activate change pointers for message type

Bd52 Define master data fields for message type.

Bd61 Activate change pointers generally.
Bd22 Delete Obsolete change pointers.
ALE customizing - Transaction : SALE
sapapo/c1 BSG
Sapapo/c2 Queue Types for BSGs
Sapapo/c3 Application log
Sapapo/c4 User specific settings for Queues
sapapo/loc3 Location
sapapo/mat1 Product
sapapo/res01 Resource
sapapo/scc05 PPM
Sapapo/rrp3 Product View
Sapapo/rrpcust1 customizing for integration strategies.
Smq1 outbound queue monitor
Smq2 inbound queue monitor
Sapapo/cq SCM Queue Manager
SALE ALE Customizing

Suggestion for the Structure of the Master Data Integration Model

The following objects should each be grouped together in a separate integration model and
activated in the sequence given:
1. ATP Customizing and product allocation Customizing
2. Plant (plant + distribution centers)
3. Classes and characteristics
4. Material masters
5. Networks
6. Maintenance orders
7. MRP areas + material masters for MRP areas
8. Planning product (this is a special case, see 'Transfer of Data Changes' for more information)
9. Availability check
10. Product allocation

11. Customer and vendor data (these may need to be separated. See below, Suggestion for the
Structure of Transaction Data Integration Model, Stocks)
12. Work centers (this is a special case, see 'Transfer of Data Changes')
13. Production process model (this is a special case, see 'Transfer of Data Changes')
14. Delivery schedules, contracts, and purchasing info records (this is a special case, see
'Transfer of Data Changes')
Suggestion for the Structure of the Transaction Data Integration Model
The following objects should each be grouped together in a separate integration model and
activated in the sequence given:
1. Stocks (if you hold special stocks at the customer or vendor, the relevant customer or vendor
must be contained in the same integration model)
2. Sales orders (contains sales orders, deliveries, scheduling agreements, quotations, and
customer independent requirements)
3. Purchase orders and purchase requisitions
4. Production/process orders + planned orders (these may need to be separated). These have to
be activated before production campaigns
5. Manual reservations and planned independent requirements
6. Production campaigns + process/planned orders
7. Shipments

1. Introduction
APO core interface (CIF) is a standard interface which connects an APO & a standard R/3
system. CIF interface enables the data exchange between an SAP ERP system (SAP R/3, SAP
R/3 Enterprise, or SAP ECC), and a connected SAP SCM system. CIF enables the integration of
master data from SAP ECC to SCM APO (one way only) and the integration of transactional
data in both ways, from ECC to APO and vice versa. The basic idea of the integration is to write
events for each planning relevant change e.g. the creation of an order and use these as trigger
point for the data transfer. Technically the transfer is performed via qRFC. Which objects (i.e.
planned orders, stock) should be transferred from SAP ECC to SCM APO is controlled by the
integration models, which could be regarded as something like the master data of the CIF.

2. Business Objective
The main objective of configuring the ECC core interface is to integrate the centralized source of
master data from ECC to APO & publishing planning result from SCM planning system (APO)
to SAP OLTP system (ECC) & vice versa. It is essential to maintain the consistent data & its
flow between planning and execution system for better planning result & optimum inventory
level. This configuration also suffices the objective of real time transactional data transfer
between planning and execution system & delta transfer for master data changes.
CIF provides the following central functions:
1. Supply the master and transaction data, relevant for planning, in SCM APO system.

2. Techniques for initial, incremental, and real-time data transfers from ECC to
SCM APO
3. Techniques for publishing planning results back from SCM APO to ECC system

3. Key Design Areas

Technical Integration between ECC and APO (CIF Configuration)

Integration of Master data and Transactional data (Design of Integration Models)

CIF Error Handling and Queue Management

4. Technical Integration between ECC & APO (CIF Configuration)

As of SAP ECC 6.0, CIF is an integrated part of the system. (If you use SAP SCM 5.0
with ERP systems up to SAP ECC 5.0, you receive CIF via the relevant SAP R/3 Plug-In.
The SAP R/3 Plug-In is a combined Plug-In used to link SAP components such as SAP
SCM to the ERP system up to and including SAP ECC 5.0) .
SAP ERP Central Component 6.0 (SAP ECC 6.00) and later releases will directly
contain all the interfaces necessary for the technical integration with other SAP
components. These interfaces were previously part of the SAP R/3 Plug-In.

5. CIF Set-up & Related Configuration Task

5.1.

Configuration in R/3
Define logical system (Transaction code- BD54)

We defined logical system for both ECC and APO system. To enable the transfer of data via APO Core Interface
(CIF), you need to name both
the ERP system in which you are working and the SAP APO system to
which you want to transfer data as logical systems.

Note:-The above activity is dependent upon the target system concerned. For this reason, there is no
transport to the production system. As a result, you need to also make the settings for the relevant
target system in the production system manually, Or Alternatively, you can maintain the entire
ECC & APO logical system name (as per SAP system landscape & client strategy) in
Development client and include them in a transport. This will make all the logical system
available across ECC system landscape & minimize the manual activities.

Assign logical system to client (Transaction code- SCC4)

In this step, assign the logical system to a client. All the fields like City, Std. currency, logical system
should be maintained. Otherwise there will be
some futile CIF error during the data transfer from
ECC to APO.

Note: - These settings cannot be transported. When a new system is being set up, these settings must be
made after the system installation has been completed.

Specify APO release (Transaction code- NDV2)

In this step, you have to specify the release level of the SAP APO system that is defined
as the target system. The release level will activate the compatible functionality for the
data transfer.

Note: - The above activity is dependent upon the target system concerned. For this
reason, there is no transport to the production system. As a result, you need to also make
the settings for the relevant target system in the production system manually or

Alternatively, you can maintain the all of the logical system name (as per SAP system
landscape) in Development client and include them in a transport. This will make all the
logical system available across ECC system landscape & minimize the manual activities.

Setup RFC destination (Transaction code- SM59)

In this step, create the RFC destination which has the same name as the target logical
system. This RFC enables the connection to the SCM APO system.

Performance Tip: - By activating the load balancing & defining the logon group, you
can use the load balancing procedure while connecting to the APO system. This logon
group needs to be assigned to the various servers in transaction code RZ12.

When ECC is connected to APO system it always uses ALEREMOTE user in order to
process any CIF queues.

Assign RFC destinations to various application cases (Transaction

code- CFC7)

You assign various application areas to the logical system and the RFC destination. This
is optional configuration & purely depends on the business requirement & guidelines for
the type of RFC user to be used for security reasons. Some of the applications only work
with RFC dialog user e.g. GATP availability check, but from security point of view, most
of the clients e.g. life science, FMCG doesnt allow to create the RFC user as dialog user
which can be misused.
To meet the business requirement, there is a need to create a new RFC destination with
different RFC user of type either Dialog or Service user with very limited & restricted
authorization. The authorization has to be provided for the type of application to be use.

The below applications can be triggered from ECC into APO

Set target system and queue type (Transaction code- CFC1)

In this step, you can set the queue type for the target system specified. It is always
recommended to use the inbound queues in the target system to control the processing of
the CIF queues with heavy data load.
The queue type (inbound or outbound) determines whether the queues processing is
controlled by the sending or receiving system

Set user parameter (Transaction code- CFC1)

In this IMG activity, you can make user-specific entries for the following parameters:

You can use this to set whether and how data records should be logged in the
application log for the user specified
User can use this functionality to debug in case of any queues get created for
that user. Any master data or transactional date created by that user will be
stuck in the CIF queue which the user can debug and analyze the issue

Here, you should maintain entry for user name as * for normal or detailed
logging of the application log.

RFC user should be maintained with the normal logging.

CIF administrator id should be maintained for detailed logging along with

Debugging mode ON.

Determine Number Ranges for Parallelization (Transaction codeCFC8)

Define filter and selection block size (Transaction code- CFC3)

o

You determine the number of filter objects that are processed in one block in the APO
Core Interface.

Also you determine the number of data objects that are transferred to SAP APO in a
remote function call (RFC) at the initial data transfer.

In normal cases, it is recommended not to change the above Filter & Block size.

You can use these settings to improve system performance during the initial data transfer.
The optimum values for improved performance vary from case to case and are largely
dependent upon the client data situation. Therefore, you are recommended to experiment
with the settings in individual cases in your system.

Note: - Refer to OSS note # 436527 for the block size recommendation.

Configure Change transfer for master data (Transaction code- CFC9)

o

All the master data changes e.g. material, customer, vendor & resources are
configured as periodic transfer to APO.

During the initial transfer of the resource, it is defined to create external

capacity for the resource for 30 days in past and 730 days in future.

It is recommended to create single-mixed resource in APO for the resources

having single capacity and for which the indicator can be used by several
operation is not set.

It is recommended to configure to create Multi-Mixed resource in APO for the

resources having multiple capacities or for capacities for which the indicator
can be used by several operations is set.

Note:

Master data change transfer from ECC to APO can be configured as

immediate or periodic, which is completely depends on client
requirement.
If SNP & PP/DS both are in scope then it is always recommended to use
the resource type as mentioned above. This is very critical setting &
cannot be altered later neither in ECC nor in APO. You need to delete
the resource in APO to change the resource type. This cleanup can be a
mini project.

Activate ALE Change Pointers Generally (Transaction code- BD61)

This configuration is a prerequisite for transferring master data changes with change pointers.

Activate ALE Change Pointers per Message Type

The following change pointers are important to be activated e.g. Vendor master, Customer master, Set-up
group and Source of supply, material
MRP area, Subcontracting PDS.

Note: - Activation of change pointer is only needed if the corresponding master data is
used in system.

Activate online Transfer Using BTE (Transaction code- BF11)

o We activate BTE for the integration with SAP APO in order to activate the
online transfer of both transaction data changes and some master data
changes like Material master and Resource. We Set the ND-APO (New
Dimension Plug-In APO) and NDI (New Dimension Integration) application
indicators to active.

Note: - This is not the default setting; hence make sure both the above mentioned
indicators are set.

QIN Scheduler (Transaction code- SMQR)

o When APO sends the planning results to the connected ECC system, it
generates the CIF queues in the inbound of the ECC system as per the
configuration. Those inbound Queues that are to be automatically processed
by the target system must be registered in the QIN scheduler.
o

The below settings used for QIN scheduler worked for most of the clients.
Changes can be done based upon the queue processing.

QOUT Scheduler (Transaction code- SMQS)

o

Outbound qRFCs (outbound queues) are processed by the QOUT scheduler.

The QOUT scheduler is configured using transaction code SMQS. The targets
system to which the outbound qRFCs are to be sent are registered in the
QOUT scheduler.

The below settings used for QOUT scheduler worked for most of the clients.
Changes can be done based upon the queue processing.

5.2.

Configuration in SCM APO System

Define Logical System (Transaction code- BD54)

We defined logical system for both ECC and APO system. To enable the transfer of data
via APO Core Interface (CIF), you need to name both the ERP system in which you are
working and the SAP APO system to which you want to transfer data as logical systems.

Note: - The above activity is dependent upon the target system concerned. For this

reason, there is no transport to the production system. As a

result, you need to also
make the settings for the relevant target system in the production system manually, Or
Alternatively, you can maintain the all of the logical system name (as per SAP system
landscape) in Development client and include them in a transport. This will make all the
logical system available across ECC system landscape & minimize the manual activities.

Assign logical system to the Client (Transaction code- SCC4)

In this step, assign the logical system to a client. All the fields like City, Std. currency,
logical system should be maintained. Otherwise there will be some futile CIF error during
the data transfer from ECC to APO.

Note: - These settings cannot be transported. When a new system is being set up, these settings
must be made after the system installation has been completed.

Setup RFC Destination (Transaction code-SM59)

In this step, create the RFC destination which has the same name as the target logical
system. This RFC enables the connection to the ECC system.

Performance Tip: - By activating the load balancing & defining the logon group, you
can use the load balancing procedure while connecting to the ECC system. This logon
group needs to be assigned to the various servers in transaction code RZ12.

When APO is connected to ECC system it always uses ALEREMOTE user in order to
process any CIF queues.

Assign RFC Destinations to Various Application Cases (Transaction

code- SPRO)
o

You assign various application areas to the logical system and the RFC destination. This
is optional configuration & purely depends on the business requirement & guidelines for
the type of RFC user to be used for security reasons. Some of the applications only work
with RFC dialog user e.g. display application log from APO into ECC system, but from
security point of view, most of the clients e.g. life science, FMCG doesnt allow to create
the RFC user as dialog user which can be misused.

To meet the business requirement, there is a need to create a new RFC destination with
different RFC user of type either Dialog or Service user with very limited & restricted
authorization. The authorization has to be provided for the type of application to be use.
So that while accessing the data from the target system through a Remote function call,
the system will use the specified RFC destination specified in the configuration of Assign
RFC destinations to various Application cases.

Maintain Business System Group (Transaction code- /SAPAPO/C1)

o

This configuration determines the assignment to a business system group of this system
and the respective ECC systems that are to be connected.

If this APO system is connected with multiple ECC system using the same number range
of material master, plant, vendor & customer master, then we need to define multiple
BSG groups to bring master data from each system.

Assign Logical system to Business System Group (Transaction

code- /SAPAPO/C2)

In this step, to enable error-free communication, every source system (ERP system) must
be assigned to a BSG. We assign the logical system to the BSG group & the queue type.
Here, we have also activated the CIF post processing functionality for CIF error handling
of transaction data.

Note: - It is recommended to use the Inbound Queues if transferring a large amount of data to the
ERP system to ensure an even load on the ERP system. Ensure to maintain settings for the
Queue-In (QIN) Scheduler in the qRFC monitor on the ERP side.

Set User Parameter (Transaction code- /SAPAPO/C4)

In this IMG activity, you can make user-specific entries for the following parameters:
o
o

You can use this to set whether and how data records should be logged in the
application log for the user specified.
User can use this functionality to debug in case of any queues get created for
that user. Any master data or transactional date created by that user will be
stuck in the CIF queue which the user can debug and analyze the issue.

Here, you should maintain entry for user name as * for normal or detailed
logging of the application log.

RFC user should be maintained with the normal logging.

CIF administrator id should be maintained for detailed logging along with

Debugging mode ON.

QIN Scheduler (Transaction code- SMQR)

o

When ECC sends the master and transaction data to the connected ECC
system, it generates the CIF queues in the inbound of the APO system as per
the configuration. Those inbound Queues that are to be automatically
processed by the target system must be registered in the QIN scheduler.

The below settings used for QIN scheduler worked for most of the clients.
Changes can be done based upon the queue processing.

QOUT Scheduler (Transaction code- SMQS)

o

Outbound qRFCs (outbound queues) are processed by the QOUT scheduler.

The QOUT scheduler is configured using transaction code SMQS. The targets
system to which the outbound qRFCs are to be sent are registered in the
QOUT scheduler.

The below settings used for QOUT scheduler worked for most of the clients.
Changes can be done based upon the queue processing.

Maintain Distribution Definition (Publication) (Transaction code/SAPAPO/CP1)

In order to publish the planning results from APO system to ECC system, we have
maintained all the publication types for the required locations for which we wanted to
publish the order to ECC system. This is maintained for both in-house and external
procurement.

Note: - If the distribution definitions are not maintained then the planning results will
not transfer back to the connected ERP system. The data
inconsistency between
ECC & APO system will even not be captured in CCR report.

5.4. qRFC queue names for CIF

QRFC queue names for the CIF are always set up according to the following rules:
CF<CIF object ID><serialization character string>
The CIF objects that are transferred from an ERP system to the APO system are
listed below:
CIF object
Batch

ID
BTC

Serialization Character string

CHARG+(10) + MATNR+(9)

Resources

CAPA

NAME+(18)

Characteristic

CHR

ATNAM+(19)

Class

CLA

KLART+(3) + CLASS+(16)

Inspection lot

LOT

PRUEFLOS+(17)

Material master

MAT

WERKS+(4) + MATNR+(14)

Planned order

PLO

ORDNR+(12)

Confirmation

PPC

ORDERNR

Reservation

RSV

ORDNR+(12)

Purchase order

PO

DOC+(10)

Purchase Requisition

PO

DOC+(10)

The CIF objects that are transferred to an ERP system from SAP APO are listed below:
CIF object

ID

Serialization Character string

Delivery confirmation

CD

ORDERNO

Confirmation

CF

GUID or ORDERNO

VMI Sales order

CO

ORDERNO

Delivery

DLV

001

Purchase requisition

EP

GUID or ORDERNO

Purchase order

EP

GUID or ORDERNO

Planned order

IP

GUID or ORDERNO

Process/Production Order

IP

GUID or ORDERNO

Production campaign

PC

GUID or ORDERNO

RV

GUID or ORDERNO

Shipment

SHP

001

Stock transport order

TO

GUID or ORDERNO

A. Man. Reservation

5.4. CIF Interface Configuration Checklist

Below is the CIF configuration checklist or tracker which can be maintained to monitor the
CIF configuration in ECC & APO system
simultaneously. This will avoid any configuration
to get missed.

A. S.no

Configuration Nodes

APO

APO Status

ECC

ECC S

Name Logical System

Basis

Completed

Basis

Compl

Assign Logical System to a

Client

Basis

Completed

Basis

Compl

A. S.no

Configuration Nodes

APO

APO Status

ECC

ECC S

Specify SAP APO Release

NA

NA

Basis/Functional

Compl

Create RFC User

Basis

Completed

Basis

Compl

Set Up RFC Destination

Basis

Completed

Basis

Compl

Set Target System and Queue

Type
CIF Functional Completed

CIF Functional

Compl

Set User Parameters

Basis/CIF
Functional

Basis/CIF
Functional

Compl

Configure Application Log

CIF Functional Not Started

CIF Functional

No Cha

Determine Number Ranges

for Parallelization

NA

NA

Basis

No Cha

10

Set Filter and Selection Block

Size
No Change

No Change

No Change

No Cha

11

Configure Change Transfer

for Master Data

NA

NA

CIF Functional

Compl

12

Activate ALE Change

Pointers Generally

NA

NA

CIF Functional

Not Sta

13

Activate ALE Change

Pointers for Message Types NA

NA

CIF Functional

Not Sta

14

Activate Online Transfer

Using BTE

NA

NA

CIF Functional

Compl

16

Activate Cross-System
Update Logic

NA

NA

CIF Functional

Compl

17

Maintain Business System

Group

CIF Functional Completed

NA

NA

18

Assign Logical System and

Queue Type

CIF Functional Completed

NA

NA

19

Maintain Object-Specific

CIF Functional Not Started

NA

NA

Completed

A. S.no

Configuration Nodes

APO

APO Status

ECC

ECC S

Settings
20

Maintain Publication Settings CIF Functional Not Started

A. S.no

Activities

APO

NA

APO Status

NA

ECC

Setup Outbound scheduler

Basis

Completed

Basis

Comple

Setup Inbound scheduler

Basis

NA

Basis

NA

Activate outbound scheduler

for CIF
Functional

Completed

Functional

Comple

Activate Inbound scheduler

for CIF

Functional

NA

Functional

NA

Create Integration model

NA

NA

Functional

Comple

Activate Integration model

NA

NA

Functional

Comple

Maintain Publication Settings

Functional
(After Master Data transfer)

Completed

6. Integration of Master data and Transactional data (Design of Integration Models)

The integration model controls the transfer of master data and transaction data. It is generated in the ERP
system and contains all data that is to be transferred to the SCM system. It is uniquely identified by name and
application. There are 2 steps in integration models

Create & Generate Integration models (Transaction code- CFM1)

When you generate an integration model, you specify which data objects are to be selected from the total
dataset in the ERP system for the
transfer. To create the integration model, follow the below steps:
o

ECC S

First select the object types (for example, material masters) to be selected on the Create
Integration Model selection screen.

NA

Next, you select specific selection criteria (in most cases, a material/plant combination)
that further restrict the object types you have already selected. If you have already
selected Material Masters, for example, you could now enter an MRP controller. In this
way, you define filter objects

. Filter objects are used to select which data objects are transferred to a specified SCM
system. In the example, all material masters for a particular MRP controller are selected.

Activate Integration model (Transaction code- CFM2)

o

The activation of integration models results in an initial transfer. If you work with SAP
APO, the online transfer of transaction data is released.

As standard, the integration models to be activated are compared with the integration
models that are already active. You can generate multiple integration models. However,
only one version can be activated for each model at a time.

You can activate and deactivate several integration models simultaneously.

Integration models must remain active to enable online transfer.

Activation of master or transaction data integration model should be followed a logical

sequence & recommended to grouped as below

ATP Customizing, Setup groups (group/key) and product allocation

Plants & distribution centers

Change master records

Class & characteristics

Material master (+ classes, characteristic)

Batches

MRP area and material master for MRP areas

Planning Products

Materials for GATP check

Product allocation

Vendors

Customers

Work Centers

Production data structure

Purchase Info Record, scheduling agreement, contracts

Note: - Normally, there are some challenges to generate & activate the material dependent
integration model for master & transaction data during initial transfer, when the master data
objects to be transferred are huge. In that case we need to do some work to design the integration
model to have the optimum no of data objects per IM.
The critical data objects are:
o
o

Material master
Purchase Info record/source list

Sales Orders

Stocks

Batches

The following are the recommendations which can be used to do the initial data transfer
successfully.
o
o

Split the material master integration model by either material type / MRP
controller/ material master number range or in combinations
If the data split is not feasible then add data objects in the sequential
manner. It means, first create & activate the IM for e.g. material type FERT.
Next time, add some more material type in the same variant & activate it.
This way, there will not be heavy load on the system at a time & it will be
distributed over multiple IM transfer.

6.1. Data Flow between ECC to APO & its Frequency

o

Master Data flow from SAP (ECC) --> APO

Master Data

Daily Batch Job- Once in a

Day

Manually

Plant

No

Periodic, Need basis

Vendor, Customer

Yes; Create new, Change

existing

Need basis

Material

Yes; Create new, Change

Need basis

existing
Info Record

PDS

Yes; Create new, Change

existing

Need basis

Yes; Create new, Change

existing

Need basis

Transaction Data Flow SAP (ECC) --> APO

Transactional Data

Daily Batch Job- Once in a

Day

Real Time

Purchase Requisition's

Yes; Activate IM for new APO Create, Change

relevant materials

Inspection lot

Yes; Activate IM for new APO

relevant materials
Create, Change

Purchase Orders

Yes; Activate IM for new APO

relevant materials
Create, Change

Stocks

Yes; Activate IM for new APO

relevant materials
Create, Change

Stock Transfer Orders

Yes; Activate IM for new APO

relevant materials
Create, Change

Sales Orders

Yes; Activate IM for new APO Create, Change

relevant materials

Note: - The above mentioned data flow frequency from ECC to APO is just a
recommendation based on various project experiences. Still, these can
vary from project to
project depends on business requirements .

6.2. Publication of procurement proposal from APO to ECC (Transaction code/SAPAPO/C5)

Transactional Data can be transferred from APO to ECC in two ways

Periodically it is recommended to use the periodic transfer of SNP planning

result to ECC. It improves system performance, locking issues, & time to
review & correct the planning results before publishing to ECC.
Immediately/Real Time This ensures real time data transfer and better
consistency between APO & ECC. It is recommended to use this method for
short term planning method e.g. PP/DS, CTM.

7. CIF Error Handling and Queue Management

7.1. Activate CIF Error Handling in SCM APO System

Transaction code- /SAPAPO/C2

Here we choose the error handling method as Post-processing of errors. No splitting

of LUW in order to activate the post-processing of the
logical systems.
If you are transferring a large amount of data from SAP APO to SAP R/3, and you want to be ensure that an even
system load is placed on SAP R/3, choose Inbound Queues.

Since we choose Inbound Queues in SAP APO, We did the necessary settings for the QIN
Scheduler (Queue-In Scheduler) in the qRFC monitor in SAP R/3(As explained above). Queues
that are to be processed automatically by SAP R/3 must be registered in the QIN Scheduler.

7.2. CIF Error Handling (Post Processing)

o

Transaction code- /SAPAPO/CPP1

This functionality in APO will allow the CIF user to see all the logged CIF error
messages centrally in APO. This process is independent of the queue type (inbound or
outbound) and CIF errors in both the system (ECC and APO) can be handled from this
one transaction in APO.
CIF error handling ensures that all CIF queue entries are processed during the data
transfer. Faulty queues no longer lead to queue blocks. Instead, they are logged in post
processing records in the relevant target system for the data transfer. You can then call
these post processing records at a later point in time in CIF Post processing. Once the
error has been corrected you can then send the objects to the relevant target system again.
If a change to transaction data cannot be posted in the target system due to an error, the
system creates a post processing record with the error status Faulty for the object
concerned.
CIF error handling is not available in the following situations, which means that CIF
queues hang when errors occur:
o
o

At the initial data transfer(Master Data and Transactional Data)

At the transfer of master data (initial and change transfer)

At short dumps or when liveCache is unavailable

When the target system is unavailable

When an object is locked in the target system (as before for the
repetition of the transfer)

If errors occur in customer exits or BAdIs that run in CIF inbound

function modules during integration

You can find information about restrictions to CIF error handling when using certain
applications and functions in SAP Note 602484.
Since not all errors are included in CIF error handling, faulty queue entries may continue
to exist once CIF error handling has been activated. Faulty queue entries can also block
objects that are resent by CIF post processing. Therefore, you still need to monitor CIF
queues by using the qRFC monitors for inbound or outbound queues, or by using the
SCM Queue Manager.

Steps for CIF Post Processing

o Invoke transaction /SAPAPO/CPP1 in APO. Choose the target system and this
should be the connected ECC system. Make sure that the indicator Select

Data from R3 is turned on. Processing status should be 1 for selecting the
data which needs to be processed. However you can select the other statuses
like processed, obsolete etc. depending upon the requirement.

o
o

The navigation tree on the left side shows the system connection and the transfer
directions; under each transfer direction, there are different order categories.
Select and process the records for each group of the order categories, e.g. In-House
Production, External Procurement, etc.

These messages appear in detail on the right side of the screen and by double clicking
on the rows for External procurement or In House Production.

On the right side of the screen there are two sections. One is worklist of the inbound
system (top) and second is objects processed in this session (bottom)

Select the records to be processed. If there are too many records to be processed, you
may sort them into different groups and process one group at a time. You may sort them
by products and by location, and select a few product/location in a group.

Depending upon the object types and the direction of the record, you can either select
send to R/3 or Send to APO.

Once the records are in process, they will be moved from the Worklist window to
Objects Process window.

Refresh the Object Processed window by click on the refresh button. If the errors are
still persistent, it will be reflected in the status. Sometime this does not provide the actual
error occurred.

So To resolve the issue, you may select a desired entry and click on the application log
button.

The application log will be displayed

Once the issue has been resolved, move the records back to the Worklist
window to be processed again by selecting the record in Object Processed
window and the click on the icon. Then you can process the object once again.
Resolve all the issues until the Objects Processed window is clear if its
possible.

You use the Set Entry as Obsolete indicator to set the processing status of the
post processing record to Obsolete (Set Manually); for example, if you do not
want an object to be sent again. The object itself is unaffected by this action.

You use the Remove Obsolescence Indicator to reset the processing

status to Still for Processing. As a result, the post processing record is
displayed in yellow.

7.3. Queue Management

As mentioned in the restrictions of CIF post processing, all the errors did not get captured
in the CIF post processing. We still need to monitor the CIF queues.

CIF Queue Monitoring Steps and Procedure

Transactions to check for Errors (R/3 and APO)

SMQ1 - qRFC Monitor (Outbound Queue)
SMQ2 - qRFC Monitor (Inbound Queue)

Click on Change View.

This will show you only the error (SYSFAIL) queues with the error
message.

/SAPAPO/CQ - CIF queue manager

Note: The indicator for expand mode is performance incentive. The Transaction will
take little bit longer time if you set this indicator.

Double click on the error message on the left side box so that the details of the
error will appear on the right side box:

Please do not delete any queue from this screen as this will delete the
error queue as well as the queues which are waiting for the error
queue.
Please select the queue and click on ENGINE ICON. This will take you
to the same SMQ2 and SMQ1 screen where you can delete the single
queue as well as you can reprocess the waiting queues once you
delete the error queue.

Note:

Evaluate CIF Application Log

Sometime the error message does not provide the detail information like product, location etc. The additional
detail information can be seen in the
CIF application log. Please proceed as following:

> In APO: Double click on the CIF error message within the CIF entry(Transaction SMQ2 and SMQ1) or
execute transaction : /n/SAPAPO/C3

> In R/3:

In order to get the details of the Error message:

Transaction in R/3: CFG1 - Display CIF Application Log

In both the cases copy the External or Transaction ID to get

the details of the error message.

Enter the External ID, From Date (Yesterday) and To date (Today) and Execute
It.

It will give the details of the error message displayed in the SMQ2 or SMQ1
transaction.

CIF Error Resolution Process

o Each CIF error should be evaluated against the list of errors and actions below.
Any new errors should be investigated and resolved if possible with the list of
known errors and actions updated.
o

When the product, location and order number (if relevant) have been recorded
along with the error message and necessary action then the CIF entry can be
deleted.

If there is any new error comes up and needs some time to investigate, the
same queue can be saved by selecting the option edit

Once the saved queue is investigated and completed with the root cause
analysis, then the saved queue can be restored (edit

An email should be sent to the Key User clearly detailing the product, location
and order (if relevant) and the action(s) to be taken.

When the Key User confirms that the action has been completed, an ad-hoc
CIF reconciliation report should be run for the relevant product(s) to correct
any differences between ECC and APO.

If no confirmation from the Key User is received, then differences will be

picked up in the weekly CIF reconciliation report.

8. Practical Challenges
There are various challenges which CIF admin or functional consultants will encounter while
integrating the ECC & APO systems. Based on various project experiences, the following are
some of the issues which are encountered.

8.1. Huge CIF queue build up in APO in-bound

If you are using the inbound queues both in ECC & APO system, then you might get into
this issue.

When the data is transferred from ECC to APO the data is not visible in APO. Similarly,
when the planning results from APO are transferred to ECC, the results are not visible in
ECC & not returned to APO with ECC order number range. This is applicable for master &
transaction data, both.
All the transferred data will be blocked in CIF inbound queue (SMQ2) with Ready status
& you need to manually activate each LUW individually. This may take long time to clear
all the queues
These queues will not be displayed in CIF queue manager (/SAPAPO/CQ). If you will run
the reconciliation report (/SAPAPO/CCR) report, the differences between ECC & APO
changes will reflect. But if will again transfer the differences from CCR report then it will
again add one more record in the APO inbound. So it is always recommended to check the
CIF blocks, clear them & then use the CCR for reconciliation.
.

Root Cause: - This issue mainly pops up when the inbound schedulers are either not
registered in SMQR or if registered but inactive (Type= U, it should be R) in ECC &
APO system.

Example: - Inbound scheduler is registered but inactive (Type-U) in APO.

You have made some changes in the existing purchase requisition in ECC & saved. This
change should transfer to APO immediately. But when
you look into APO, the changes
are not reflecting.
The changes are blocked in the APO inbound with Ready status & need manual
intervention to clear them

8.2. Master & Transaction Data change transfer to APO is not real time
This issue is applicable for all type of transaction data & only those master data objects which are
configured as immediate transfer, e.g. material master, vendor & customer master, resource.

When there are any changes in the existing master data objects or transaction data which are
integrated with APO & part of active integration model, still the changes are not reflecting in APO. You
will not find any queue blocks for these changes. If you will run the reconciliation report in APO for
transaction data consistency check (/SAPAPO/CCR), you will not find any record with differences.
These changes will transfer to APO when the CIF job will run for respective integration model.

Root Cause: - This issue mainly pops up when you have not activated the online transfer using
business transaction events for application ND-APO & NDI.
For master data, you can additionally check the change pointers are active or not, for the message
type for the objects mentioned above.

8.3 Change pointers for master data changes are not recorded
This issue is applicable for all type of master data objects which are relevant to APO planning.

When there are any changes in the existing master data objects which are integrated with APO & part
of active integration model, still the changes are not reflecting in APO. You will not find any CIF queue
blocks for these changes. These changes will not even transfer to APO when the CIF job will run for
respective integration model.
If you will check the table BDCP & BDCPS (for change pointer), you will not find the change pointer
that you are looking for.

Root Cause: - This issue mainly pops up when you have not activated the ALE change pointers
globally in the transaction code BD61, or the change pointer for specific message type for the master
data object in the transaction code BD50 shown below.

8.4 Master Data Changes are not getting transferred to APO

This issue is applicable for all type of master data objects which are relevant to APO planning.

When there are any changes in the existing master data objects which are integrated with APO & part
of active integration model, still the changes are not reflecting in APO. You will not find any CIF queue
blocks for these changes. These changes will not even transfer to APO when the CIF job will run for
respective integration model.
You have checked that the master the change pointers are active globally & for all the required
master data message types.

Root Cause: - This issue mainly pops up when you have multiple integration models active for the
same object. You should check the active integration model for the master data object by using the
transaction code- CFM5 in ECC.
Conclusion:

- you should have only one active integration model for any unique master data object.

8.5 Custom field value change in material master is not triggering change
transfer to APO

This issue is applicable for all type of master data objects which are relevant to APO planning and
enhanced by adding Z custom fields.

When there are any changes in the Z custom field value (Enhanced master data objects with Z fields
relevant to APO planning) in the existing master data objects, the changes are not recorded &
transferred to APO. The objects are integrated with APO & part of active integration model. There are
no CIF queue blocks for these changes. These changes will only transfer to APO when there is an
initial transfer for the respective master data objects.

You have checked that the change pointers are active globally (T.code-BD61) & for all the required
master data message types (T.code-BD50).

Root Cause: - This issue mainly pops up when there is Z custom fields added in the APO relevant
master data object but these tables & fields are not added in the transaction code BD62 for the
specific message type.

Conclusion: - All fields of the required master data objects should be maintained in the transaction
code- BD62, which should trigger the change transfer upon any change in ECC.

8.6 APO orders are not getting transferred from APO to ECC
This issue is only applicable to the transaction data which are planned in APO & to be sending back
to ECC system.

Planning run has created procurement proposals in APO. These procurement proposals have to be
send back to ECC. The new or changed proposals are not reflecting in ECC system. The transaction
data is integrated with APO & part of active integration model. There are no CIF queue blocks for
these changes. These changes are not reflecting even in the reconciliation report (/SAPAPO/CCR).

You have checked that the all the basic CIF configuration is maintained.

Root Cause: - This issue mainly pops up when the publication definition have not been maintained
for the Plant & ECC logical system combination in APO. /SAPAPO/CP1

8.7 Poor performance of CIF background job

First, check the setting in transaction CFC2. It is recommended to use the Normal logging to
keep the system performance better. For administrator, who is responsible to resolve interface
issues, can be given detailed logging access with debugging on.
Second, schedule the performance improvement CIF batch jobs on regular basis, at least once in
a week.

Archive logs using t.code CFGD

Configure the application log using t. code CFC6

Third, check the block size settings of the filter objects using t.code CFC3. The size of the filter
object improves system performance.

The block size that should be used in each individual case is largely dependent upon the current
data situation.

There is no thumb rule to define the block size. Its a judgmental, hit & trial method to find the
optimum filter size. It is recommended to use the default settings as a starting point.

Fourth, use Parallelized process wherever available .

8.8 Common configuration objects are not in sync between ECC & APO
There are various common configuration objects in ECC & APO which should in sync. This
is one of the prerequisites before you initiate the master data transfer from ECC to APO. If
the configuration is not in sync (object missing in APO) then there will be initial error in
CIF data transfer.
Some of the common configuration objects are:
o
o

Insert Regions
Currencies

Calendar

Unit of Measure

Time Zones

Root cause: Standard configuration has been changed in ECC for the UOM, Calendars, or
new configuration objects have been added. These changes must be updated in APO.

Solution: - you can update the UOM, Currency & Calendars using the RSA1 transaction if
the connected ECC system is created & active under the SAP source systems. You can use
the Transfer global settings from the context.

For other configuration object, either compares and maintains it manually, if missing, or use the
compare tool under the Utility menu bar to
compare the objects from concerned ECC system &
update all differences in one shot.

9. CIF Housekeeping Job

Report RAPOKZFX

Detect and correct inconsistencies between material master and integration models with report RAPOKZFX. In
rare cases, inconsistencies can occur
between data in integration models and field APOKZ in table MARC. They
may occur if you activate a model that refers to a material master that is
being changed at the same time. In this
case, the activation is finished successfully but the APOKZ is not set correctly, and an error message is
displayed.
The inconsistency can result in an error during the ATP check and when transferring production and planned orders

Report RCIFMAX

As of R/3 Plug-In 2002.1, report RCIFIMAX should be scheduled regularly to find Inconsistencies between the
integration model sources and their
runtime versions. This report must not be run in parallel with activations of
integration models.

Report RSQOWKEX & RSQIWKEX (Exceptional use only)

You can activate qRFC queues using the reports RSQOWKEX (outbound queues) and RSQIWKEX (inbound
queues). In normal operation, however, it is not necessary to run these programs regularly because almost all queue
entries are processed without errors. In case of queue errors, these should be detected by the procedures described
below, and analyzed and corrected accordingly. The error analysis should suggest preventive measures to reduce the
number of future exceptions. In exceptional cases, or, for example, on test systems, you can use reports
RSQOWKEX and RSQIWKEX. If you start these reports at an inappropriate time or with too many queues selected,
they may cause an excessive additional system load.

Report - /SAPAPO/CIF_DELTAREPORT3

Detect and correct external inconsistencies between APO and R/3 with report /SAPAPO/CIF_DELTAREPORT3
(transaction /SAPAPO/CCR). To ensure that all relevant transaction data objects (such as purchase, production or
sales orders, and stocks) for which there are active integration models exist in both APO and R/3, this report should
be scheduled to run:
o

Periodically, and preferably daily, to detect and reconcile possible

inconsistencies as soon as possible. This is important because otherwise
further inconsistencies can be generated and cause subsequent planning to
be based on incorrect data.
In case a recovery of your liveCache or your APO database had to be
executed, but was incomplete (point-in-time recovery, loss of data,)

In case you have evidence of inconsistencies between your APO and your R/3
OLTP system

In case queue entries have been deleted.

Report - /SAPAPO/OM17 - ( In case of Recovery only)

Internal consistency between APO DB and live-Cache is checked by transaction

/SAPAPO/OM17. If it is necessary to reconcile the internal consistency, for example in case of a
recovery, we recommend doing this first before checking and reconciling external consistency.

10. Performance Optimization Job

To optimize the performance of the data transfer between the APO and the connected R/3
OLTP system(s) and to prevent accumulation of useless data in the systems, several
reorganization jobs must be scheduled to run regularly.

Administration Jobs Related to Data Transfer (R/3)

1. Delete application log with report RDELALOG. If writing of application logs is
enabled in (R/3) transaction CFC2 or APO transactions /SAPAPO/C4 or
/SAPAPO/C41) and this should be done in a production system for certain
users and for problem analysis only old logs must be deleted regularly. It is
recommended to run this job daily and delete logs older than 7 days.
2. Delete ALE change pointers with report RBDCPCLR. If changes to master data
are transferred periodically via ALE (as it is recommended), processed change
pointers must be deleted regularly. After completing this, if your database
system on the R/3 side is Oracle, run report RBDCPIDXRE to reorganize the
Oracle indexes on tables BDCP and BCDPS. See SAP Note 328355.
3. Delete old inactive integration model versions with report RIMODDEL. Every
time an integration model is generated, a new version is created,
distinguished by a timestamp. The old version is deactivated and the new one
is activated. Old versions must be deleted regularly.

Administration Jobs Related to Data Transfer (APO)

1. Delete application log with report /SAPAPO/RDELLOG. Same as RDELALOG in
R/3 (see above).
2. Check processing of APO change pointers with report
/SAPAPO/RDMCPPROCESS. To verify that all change pointers created are
processed, after publishing of planning results to R/3 run report
/SAPAPO/RDMCPPROCESS without restricting the selection of orders and
confirm that message No change pointers were selected is displayed. If
change pointers remain unprocessed, contact the application support team to
clarify whether these change pointers are necessary and why they are not
processed.

3. Deletion of R/3 data those are no longer required in APO with report
/SAPAPO/SDORDER_DEL.
4. Delete old results of CIF delta report using report
/SAPAPO/CIF_DELTAREPORT3_REORG. As it is now possible to save the results
of a Delta report run, it is necessary to delete outdated results from the
database. The spool list from this report contains the number of records
deleted.
5. Delete post-processing records with report /SAPAPO/CIF_POSTPROC_REORG.
Processed and obsolete post-processing records are no longer required and
should be deleted. This report is used to do so. Non-deletion of these records
will have an increasingly negative impact on CIF performance over the time.
The deletion is a two-step process. In a first run, outdated records that meet
the selection criteria with the status still to be processed are set to status
obsolete (set manually). In a second run, all processed and all obsolete
records are deleted.

Note:

a) Deleting change pointers may cause inconsistencies, as the corresponding order changes are not
transferred to R/3.

In SAP APO database tables, the tables expand with data from SAP R/3 documents. However, this data is no longer
required; no corresponding information exists in liveCache. In addition, the performance of the initial data supply or
of other transfer processes with a high data volume is affected negatively. The obsolete records need to be deleted
regularly to control the size of certain tables (e.g. /SAPAPO/SDFIELD and /SAPAPO/POSMAPN) and to improve
the performance of the Sales order updates on SAP APO side. For details, see SAP Note 504620.\

11. Real CIF Error encountered in various project

Error: CFEP000000043548 ED1CLNT120

number assignment not defined

@OJ@

Internal

Cause:- There is no internal number range maintained for purchase requisition document
type NB.
Solution:- Create pur req no range in ECC & enter it into the Document types under purchasingPur Req for
type NB internal no rng

Error: CFEP000000043548 ED1CLNT120

Purch. group

@OJ@

Enter

Cause:- Purchasing Group is not maintained in ECC system for the given material.
Solution:- Maintain the Purchasing group in the material master & reactivate the queue.

Error: CFIP009000001374 ED1CLNT120

@OJ@
21.12.2015 date comes after end of valid factory calendar

Cause:-The planning calendar validity is ending in 2010 while the orders dates are lying in
2013.
Solution:- Extend the planning calendar.

Error: CFIP000100000896 ED1CLNT120

@OJ@
Messages for WM staging: Check order 100000896

Cause: The Production supply area has not maintained in the resource or in the BOM.
System first picks the Prod Supply area from the resource master & if that is not maintained
in the Resource then it will look in the BOM component.
This is used if the Warehouse management is active.

Note:- In the SPRO (Log Exe:--Wh mgmt interfacedefine production) production supply
area is maintained or use trxn code OMK0.

Solution:-Maintain the Production supply area & should be assign to the Resource (for the master recipe for
which component is assigned) or assign directly to the BOM component. Ensure that the storage location
assigned in the Production supply area for a component should be assigned in the MMSC trxn.

Error: CFIP0000072359
EQ1CLNT210
@OJ@
Backflushing only possible for materials kept in stock

Cause: The Backflush indicator in the material master is 1 always backflush. While the
valuation class in the material master is WIPS WIP inventory stock.
Hence while converting planned order into process order system reads the accounting view
data to calculate the cost & determine the accounts using the valuation class. That time
system is giving the CIF error.
Note:- The Qty & value updating field in the material type config is not relevant to this error.
Solution:-Either changes the Valuation class in the accounting view of material master or
else change the back flush indicator from 1 to blank.

Error: CFPLO000100000382
MQ1CLNT210
@OJ@
Two constraints that exclude each other or create unrealizable
situation

Cause:
Process Order directly created in ECC system & sent to APO. In ECC Master Recipe is
created but the production version is not created & also not CIFed to APO. Hence the error
occurred.

Note: - Following observations:

Delete the queue.

Create the production version in ECC but dont CIF to APO.

Now if you will create the Process order in ECC system then it will go to APO
without any error. But there will not be source of supply in the process order
in APO. The reason is that the PPM is still not CIFed to APO.

All the operation will also appear in APO but without any operation
description.

You can also schedule the order in APO without PPM availability but the dates
will calculate based on ECC master data not as per APO.

Resolution:-Create the Production version in ECC & send it to APO.

Source of supply () not in source list (Material/Plant) despite source list

requirement
o Vendor is not included in the source list (if it is purchase info record).
o

Vendor /scheduling agreement is not included in the source list for the
material plant.

The validity dates are not in the range of the purchase requisition.

The validity dates of the Pur Info record maintained in the info record
is different then valid in the source list.

The validity date of the source of supply in APO is inconsistent with the
validity dates in ECC system.

Source list indicator is set in the material master Purchasing view.

Source list is maintenance is mandatory at plant level irrespective of

the material type (In-house or External)

Solution:o
o
o

Maintain the vendor or scheduling agreement in the source list with the
consistent validity date in ECC & APO.
The validity dates should be same in ECC & APO for the outline
agreement & the purchase info record.
If after removing the Source list indicator from the material master
still the same error is reflecting that means in the source list
configuration the Source list indicator is mandatory for that location.

Not possible to determine shipping data for material MAT1 at YYYY

Check the Sales organization data of Material master and it should be

maintained with correct sales area which is maintained in customizing

Setup for Stock Transport Order.

Make sure that the Customizing for Set Up for Stock Transport Order
is correctly maintained. Ask the user to check the same and if
necessary take the help of R/3 Support team.

In order to check the Customizing for Set Up for Stock Transport

Order , follow the path : SPRO Material Management Purchasing
Purchase Order Set Up for Stock Transfer Order.

Here please make sure that

1.
2.

Receiving plant is assigned to correct customer Number created

by the Sales area of supplying plant.
Also check correct delivery document type (NL-Intra Company
and NLCC-Inter Company) has been assigned to the supplying
plant.

3.

A correct purchasing document type should be assigned to the

combination of receiving plant and supplying plant.

No sales area is assigned to sold-to party XXXXXXXXX and plant YYYY

o Check in the customizing of R/3 that whether any sales area is

assigned to this VMI customer and plant combination. The Path to

check this is SPRO Integration with Other SAP Components
Advanced Planning and Optimization Application Specific Settings
and Enhancements Settings and Enhancements for Sales Order
Settings for Vendor Managed Inventory Assign Sales Area and Order
Type to Ordering Party/Plant.

This setting is required if the customer is a VMI customer for one plant
for some products without which the sales orders will not get any
numbers from R/3.

12. CIF- Important T-codes

R/3:
Transaction code

Description

CFM1

Create integration model

CFM2

Activate/deactivate integration models

CFG1

View CIF application log

CFC2

User parameters for CIF

CFC3

Block sizes for initial transfer

CFM5

Filter object search in integration models

CFC1

Define logical systems as APO systems

NDV2

Setting of release level of APO systems

SMQ1/SMQ2

qRFC monitor incl. functions start, stop,

execute

SM59

Definition of RFC destinations

SALE

Definition of logical systems

APO:
Transaction code

Description

/SAPAPO/C3

View CIF application log

/SAPAPO/C4

Setting of user parameters CIF

/SAPAPO/C5

Send planning results to R/3

/SAPAPO/C1

Create business system group

/SAPAPO/C2

Assign logical systems to a business

system group

/SAPAPO/CQ

SCM Queue Manager

/SAPAPO/CCR Comparison/reconciliation tool

SMQ1/SMQ2

qRFC monitor incl. functions start, stop,

execute

SM59

Definition of RFC destinations

SALE

Definition of logical systems

/SAPAPO/CPP CIF Post processing

References

SAP Note: 563806

SAP Note: 369007

SAP note: 786446

SDN: www.sdn.sap.com

SAP Help: www.help.sap.com

For more information, visit the Supply Chain Management homepage

2935 Views
inShare14

Comments

5 Comments

Actions
Login to follow, like, comment, share and bookmark content.
Login Register

Incoming Links

Re: Core Interface between APO and ECC

APO Useful Documents on SCN

Comment on 'SCM Core Interface- Handbook (PART-1)'

Follow SCN