Cross Co Code

7/28/2019 Cross Co Code

http://slidepdf.com/reader/full/cross-co-code 1/32

EHP4 for SAP ERP6.0

June 2010

English

Central Contract Sourcing(798)

SAP AGDietmar-Hopp-Allee 1669190 Walldorf Germany

Building Block Configuration Guide



SAP Best Practices Central Contract Sourcing (798): Configuration Guide

Copyright

© 2010 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without theexpress permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z,System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390,OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+,POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, SystemStorage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks

of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarksof Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarksor registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web

Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technologyinvented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjectsExplorer, and other SAP products and services mentioned herein as well as their respective logos aretrademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions,Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as wellas their respective logos are trademarks or registered trademarks of SAP France in the United States

and in other countries.

All other product and service names mentioned are the trademarks of their respective companies. Datacontained in this document serves informational purposes only. National product specifications mayvary.

These materials are subject to change without notice. These materials are provided by SAP AG and itsaffiliated companies ("SAP Group") for informational purposes only, without representation or warrantyof any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. Theonly warranties for SAP Group products and services are those that are set forth in the expresswarranty statements accompanying such products and services, if any. Nothing herein should beconstrued as constituting an additional warranty.

© SAP AG Page 2 of 32




Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Typographic Conventions

Type Style Description

Example text Words or characters that appear on the screen. These include fieldnames, screen titles, pushbuttons as well as menu names, paths andoptions.

Cross-references to other documentation.

Example text Emphasized words or phrases in body text, titles of graphics and tables.

EXAMPLE TEXT Names of elements in the system. These include report names,program names, transaction codes, table names, and individual keywords of a programming language, when surrounded by body text, for example, SELECT and INCLUDE.

Example text Screen output. This includes file and directory names and their paths,messages, source code, names of variables and parameters as well asnames of installation, upgrade and database tools.

EXAMPLE TEXT Keys on the keyboard, for example, function keys (such as F2) or theENTER key.

Example text Exact user entry. These are words or characters that you enter in thesystem exactly as they appear in the documentation.

<Example text> Variable user entry. Pointed brackets indicate that you replace thesewords and characters with appropriate entries.





Content

1 Purpose................................................................................................................................. 5

2 Preparation............................................................................................................................ 6

2.1 Prerequisites................................................................................................................... 62.2 Alignment and Distribution of Customizing and Organizational Data...............................6

2.3 Setting up the Subsidiary System....................................................................................7

2.3.1 Maintaining Logical Systems in the Subsidiary ........................................................7

2.3.2 Assigning Subsidiary’s Logical System to Client.......................................................8

2.3.3 Defining RFC Destination in Subsidiary....................................................................8

2.3.4 Maintaining Distribution Model..................................................................................9

2.3.5 Generating Partner Profiles.....................................................................................10

2.3.6 Maintaining Partner Profiles ...................................................................................10

2.4 Setting Up the Headquarters System............................................................................12

2.4.1 Maintaining Logical Systems in the Headquarters .................................................12

2.4.2 Assigning Headquarters’ Logical System to Client..................................................12

2.4.3 Defining RFC Destination in Headquarters.............................................................13

2.4.4 Maintaining Distribution Model ...............................................................................13

2.4.5 Generating Partner Profiles.....................................................................................14

2.4.6 Maintaining Partner Profiles....................................................................................15

2.5 Setting Up the Integration Platform ...............................................................................15

3 Configuration....................................................................................................................... 173.1 Headquarters System....................................................................................................17

3.1.1 Defining Central Contract........................................................................................17

3.1.2 Defining Cross-Company Code..............................................................................21

3.1.3 Defining Setup for Automatic Transfer of Central Contract Changes......................22

3.2 Subsidiary System.........................................................................................................27

3.2.1 Defining Central Contract........................................................................................27

3.2.2 Defining Cross-Company Code..............................................................................30

3.2.3 Assigning Purchasing Organization of Headquarters as Reference for Purchasing

Organization of Subsidiary...............................................................................................31





Central Contract Sourcing: Configuration Guide

1 Purpose

The purpose of this document is to describe the general configuration steps required tomanually set up the configuration within the system landscape that has already been installedusing the corresponding installation or configuration guides for installation.

The configuration described in this document is not specific to any particular country. However, some of the data that appears within the document is specificto Germany, because the examples are taken from the SAP Best PracticesBaseline package for Germany. In cases where this country-specific dataappears, you must replace the data valid for Germany by data valid for your country.





2 Preparation

2.1 PrerequisitesBefore you start installing this scenario, you must install prerequisite building blocks.

These include:

• Technical Foundation for Business Network Integration (704)

• One of:

o Business Network Integration for SAP PI (705) if you choose to use SAP Process

Integration as integration technology, or

o Business Network Integration for B1iSN (706) if you choose to use SAP Business

One Integration for SAP NetWeaver as integration technology, or

o Business Network Integration for ALE (707) if you choose to use Application Link

Enabling as integration technology

• Procurement Contract (133)

2.2 Alignment and Distribution of Customizing andOrganizational Data

For each integration scenario, it is important that the customizing and master dataare harmonized between the headquarters and the subsidiaries. This can bedone manually, or by BC Sets, or by data migration when setting up thesubsidiary system, or using explicit data mapping.

The alignment and distribution content depends on how the systems are individually set up.This fact has to be considered for each integration project, before the technical connectionsbetween any systems are started.

For each headquarters-subsidiary pairing, check and align at least the following entities:

1. Company codes

2. Plants

3. Purchasing organizations

4. Purchasing groups

In order to be able to distribute contracts, you must set up identical purchasing organizationsand purchasing groups in the central and local systems. This means that in the headquarters’system the purchasing organization and related company code of the subsidiary must be setup, and in the subsidiary’s system the purchasing organization and related company code of the headquarters. Additionally, the purchasing group in the headquarters, which isresponsible for the contract creation, must be recognized in the subsidiary’s system.

As far as the customizing of transaction data is concerned, the following data should beharmonized between headquarters and subsidiary:

• Procurement contract type (for central contract)

• Detailed configuration setup of this procurement contract





o Number interval used

o Pricing procedure (including condition types)

In addition to the customizing and organizational alignments, some master data also has tobe aligned between the headquarters’ system and the subsidiary’s system in order to run thisscenario. In the preceding configuration guides Business Network Integration for SAP PI

(705) or Business Network Integration for ALE (707), only example data is included (andindeed required in order to be able to run this scenario). Adjust the following data to meetyour requirements.

• Material master data

o Create material master data in headquarters and subsidiary with identical

material group

• Business partner data created in subsidiary and headquarters

o Create vendor/supplier master data in headquarters and subsidiary

2.3 Setting up the Subsidiary System

2.3.1 Maintaining Logical Systems in the Subsidiary

Use

In SAP, a logical system corresponds to a client. Logical system names have to be set up andassigned to the clients in an SAP system. Use the following naming convention <system

name>CLNT<client number> for logical systems representing SAP systems.

Some of the logical system names listed below may already exist. If so, you canignore this procedure.

This maintenance is cross-client. This means you perform it only once for eachSAP system. If all your logical systems are clients of the same SAP system, youonly need to perform this step once.

You need to create logical systems for headquarters, subsidiaries, and(depending on the integration technology) for the appropriate server.

Procedure





1. For further details on how to set up the headquarters and subsidiary, refer to the followingconfiguration guide:


Sections: Maintaining Logical System for Subsidiary

2. If you are using SAP PI as integration technology, refer to the following configuration

guide for further details on how to the set up the appropriate server:

• Business Network Integration for SAP PI (705)

Section: Maintaining Logical System for SAP PI Server

3. If you are using B1iSN (SAP Business One Integration for SAP NetWeaver) as integrationtechnology, refer to the following configuration guide for further details on how to the setup the appropriate server:

• Business Network Integration for B1iSN (706)

Section: Maintaining Logical System for B1iSN in Subsidiary

2.3.2 Assigning Subsidiary’s Logical System to Client

Use

To enable communication between SAP systems, you must assign the SAP client to a logicalsystem. This enables the logical system representing your SAP client to communicate withexternal systems.

Here we will assign the logical system for a subsidiary’s system to a client.

Procedure

1. For further details, refer to the following configuration guide:

• Technical Foundation for Business Network Integration (704)Section: Assigning Subsidiary’s Logical System to Client

2.3.3 Defining RFC Destination in Subsidiary

Use

The purpose of this activity is to define the RFC destinations. Here we define the RFCdestinations with the same names as the logical systems created previously.

Procedure

1. For further details on how to define the RFC destination to the headquarters, refer to thefollowing configuration guide:


Section: Defining RFC Destination to Headquarters

2. If you are using SAP PI as integration technology, refer to the following configurationguide for further details on how to the set up RFC for the appropriate server:


Section: Defining RFC Destination to SAP PI Server

3. If you are using B1ISN as integration technology, refer to the following configuration guidefor further details on how to the set up RFC for the appropriate server:






Section: Defining RFC Destination for B1iSN in Subsidiary

Result

An RFC destination is defined for the logical systems. This destination can transfer data fromSAP ERP/SAP Business All-In-One to the integration platform server directly.

The settings can be tested using the Connection Test and Unicode Test buttons.

2.3.4 Maintaining Distribution Model

Use

The purpose of this activity is to define the message flow in order to specify the applicationsthat communicate with each other within an ALE business process, or an ALE-basedbusiness process via SAP PI. A message flow depicts the sending and receiving systems and

the message type involved. The message flow is defined in the distribution model, both for inbound and outbound messages, and for the sender and the receiver systems.

Here we define, for example, a distribution model with the same name as that of the logicalsystem and the RFC connection created previously. As an alternative, we could also definethe distribution model description with more granularity, as a combination of the integrationtechnology and scenario description.

This activity defines the distribution model at the subsidiary for all messages sent from asubsidiary to the headquarters (and vice versa) for this scenario.

Prerequisites

• You have specified the logical systems. For more information, refer to the section

Maintaining Logical Systems.

• The model view names in the organization’s complete distribution environment are

unique.

You cannot set up more than one distribution model with an identical sender,receiver, and message type assignment.

If you are using the distribution model previously set up, no further configurationsteps are necessary for the distribution model and partner profiles.

ERP systems do not allow the multi-issuing of certain IDocs. You must ensurethat only one receiver is available for the outbound IDoc BLAREL in thesubsidiary.

Otherwise, ERP does not create the corresponding documents due to thelimitations of the IDoc distribution. You must therefore use the filter mechanism inthe distribution model to filter by the business partner number of the receiver system (10 digits, complete numerical BP numbers with leading zeros).

Procedure

1. For further details, refer to one of the following configuration guides, depending on theintegration technology chosen:






Section: Maintaining Distribution Model for Scenario Central Contract Sourcing



• Business Network Integration for ALE (707)


2.3.5 Generating Partner Profiles

Use

The purpose of this activity is to generate the partner profiles for the outbound and inboundmessages, based on the information in the distribution model. This needs to be done both for inbound and outbound messages, and for the sender and the receiver systems.

This activity generates the partner profiles for communication with the headquarters’ system.

Procedure



Section: Generating Partner Profiles for SAP PI


Section: Generating Partner Profiles for B1iSN


Section: Generating Partner Profiles for Scenario Central Contract Sourcing

Result

The system now creates the partner profiles and other required entries for the logical systemsand message types previously defined. If some of those entries existed already, this will bereported too. The following information will be displayed:

• Partner systems

• Port with an auto-generated port number and the name of the logical system of the

remote system to be communicated with

• Outbound parameters

• Parameters for message control

• Inbound parameter

2.3.6 Maintaining Partner Profiles

Use

The purpose of this activity is to maintain the partner profiles for the model view as generatedpreviously by checking the generated entries for complete and correct data and by extendingthe outbound parameters with message control information where necessary.

This activity checks the partner profiles at the subsidiary for communication with the

headquarters’ system via the integration technology used.





Procedure



Section: Maintaining Partner Profiles for SAP PI for Scenario Central Contract Sourcing Section: Maintaining Partner Profiles for Headquarters for Scenario Central Contract Sourcing


Section: Maintaining Partner Profiles for B1iSN in Subsidiary Section: Maintaining Partner Profiles for B1iSN in Headquarters


Section: Maintaining Partner Profiles for Scenario Central Contract Sourcing





2.4 Setting Up the Headquarters System

2.4.1 Maintaining Logical Systems in the Headquarters

Use

In SAP, a logical system corresponds to a client. Logical system names have to be set up andassigned to the clients in an SAP system. Use the following naming convention <system

name>CLNT<client number> for logical systems representing SAP systems.

Some of the logical system names listed below may already exist. If so, you canignore this procedure.

This maintenance is cross-client. This means you perform it only once for eachSAP system. If all your logical systems are clients of the same SAP system, youonly need to perform this step once.

You need to create logical systems for headquarters, subsidiaries, and(depending on the integration technology) for the appropriate server.

Procedure

1. For further details on how to set up the headquarters and subsidiary, refer to the followingconfiguration guide:


Section: Maintaining Logical System for Headquarters

2. If you are using SAP PI as integration technology, refer to the following configurationguide for further details on how to the set up the appropriate server:


Section: Maintaining Logical System for SAP PI Server

3. If you are using B1iSN as integration technology, refer to the following configuration guidefor further details on how to the set up the appropriate server:


Section: Maintaining Logical System for B1iSN in Headquarters

2.4.2 Assigning Headquarters’ Logical System to Client

Use

To enable communication between SAP systems, you must assign the SAP client to a logicalsystem. This enables the logical system representing your SAP client to communicate withthe external system.

Here we assign the logical system for the headquarters’ system to a client.

Procedure





1. For further details, refer to the following configuration guide:


Section: Assigning Headquarters Logical System to Client

2.4.3 Defining RFC Destination in Headquarters

Use

The purpose of this activity is to define RFC destinations. Here we define the RFCdestinations with the same names as those of the logical systems created previously.

Procedure

1. For further details on how to define the RFC destination to the subsidiary, refer to thefollowing configuration guide:


Section: Defining RFC Destination to Subsidiary

2. If you are using SAP PI as integration technology, refer to the following configurationguide for further details on how to the set up RFC for the appropriate server:


Section: Defining RFC Destinations for SAP PI Server

3. If you are using B1iSN as integration technology, refer to the following configuration guidefor further details on how to the set up RFC for the appropriate server:


Section: Defining RFC Destination for B1iSN in Headquarters

Result

An RFC destination is defined for the logical systems. This destination can transfer data fromSAP ERP/SAP Business All-In-One to the integration platform server directly.

The settings can be tested using the Connection Test and Unicode Test buttons.

2.4.4 Maintaining Distribution Model

Use

The purpose of this activity is to define the message flow in order to specify the applications

that communicate with each other within an ALE business process, or an ALE-basedbusiness process via SAP PI. A message flow depicts the sending and receiving systems,and the message type. The message flow is defined in the distribution model, both for inbound and outbound messages, and for the sender and the receiver systems.

Here we define, for example, a distribution model with the same name as that of the logicalsystem and the RFC connection created previously. As an alternative, we could also definethe distribution model description with more granularity, as a combination of the integrationtechnology and scenario description.

This activity defines the distribution model at the headquarters for all messages sent via theintegration technology from a subsidiary to the headquarters (and vice versa) for thisscenario.

Prerequisites





• You have specified the logical systems. For more information, refer to the section

Maintaining Logical Systems.

• The model view names in the organization’s complete distributed environment are

unique.

You cannot set up more than one distribution model with an identical sender,receiver, and message type assignment.

If you are using the distribution model previously set up, no further configurationsteps are necessary for the distribution model and partner profiles.

ERP systems do not allow the multi-issuing of certain IDocs. You must ensurethat only one receiver is available for the outbound IDocs BLAORD andCOND_A in the headquarters.

Otherwise, ERP does not create the corresponding documents due to the

limitations of the IDoc distribution. You must therefore use the filter mechanism inthe distribution model to filter by the business partner number of the receiver system (10 digits, complete numerical business partner numbers with leadingzeros).

Procedure



Section: Maintaining Distribution Model from Headquarters to SAP PI for ScenarioCentral Contract Sourcing

• Business Network Integration for B1iSN (706) Section: Maintaining Distribution Model for Scenario Central Contract Sourcing



2.4.5 Generating Partner Profiles

Use

The purpose of this activity is to generate the partner profiles for the outbound and inbound

messages based on the information in the distribution model. This needs to be done both for inbound and outbound messages, and for the sender and receiver systems.

This activity generates the partner profiles for communication with the subsidiary systems viathe integration technology.

Procedure







Section: Generating Partner Profiles for SAP PI


Section: Generating Partner Profiles for B1iSN


Section: Generating Partner Profiles for Scenario Central Contract Sourcing

Result

The system now creates the partner profiles and other required entries for the logical systemsand message types previously defined. If some of these entries existed already, this will bereported too.

The following information will be displayed:

• Partner systems

• Port with an auto-generated port number and the name of the logical system of the

remote system to be communicated with

• Outbound parameters

• Parameters for message control

• Inbound parameters

2.4.6 Maintaining Partner Profiles

Use

The purpose of this activity is to maintain the partner profiles for the model view as generatedpreviously by checking the generated entries for complete and correct data and by extendingthe outbound parameters with message control information where necessary.

This activity checks the partner profiles at the headquarters for communication with thesubsidiary systems via the integration technology.

Procedure



Section: Maintaining Partner Profiles for SAP PI for Scenario Central Contract

Sourcing

• Business Network Integration for B1iSN (706 )

Section: Maintaining Partner Profiles for B1iSN in Headquarters


Section: Maintaining Partner Profiles for Scenario Central Contract Sourcing

2.5 Setting Up the Integration Platform

Procedure





1. If you are using SAP PI as integration technology, refer to the following configurationguide for further details:


Section: Setup SAP PI Server

2. If you are using B1iSN as integration technology, refer to the following configuration guide

for further details:


Section: Setup B1iSN System

Cross-Company-Code Configurations

Step1: T Code: OBYA

We have to maintain Receiver Company Code as Customer in Sender Company Code and Sender

Company Code as Vendor in Receiver Company Code. Then problem will be solved.

Step2: T Code: OB60

There you can find 4 line items, Copy all the 4 Line Items using Copy As button and customize to your

company code.

Cross-Company-Code Transactions

1. To Change Cross Company Code Document: T Code: FBU2 - Change

2. To Display Cross Company Code Document: T Code: FBU3 - Display

3. To Reverse Cross Company Code Document: T Code: FBU8 - Reverse





3 Configuration

3.1 Headquarters System

3.1.1 Defining Central Contract

Use

The purpose of this activity is to define all the settings for the central contract, which will –during processing – be distributed to the subsidiary system(s).

Prerequisites

Since the central contract will be replicated to the subsidiary system(s), it is essential that the

key setup data of the contract should be harmonized between headquarters and subsidiarysystems. If this data cannot be harmonized, it has to be mapped during replication.

The setup described in this configuration guide is based on the assumption that both systemsare configured in the same way with respect to central contract sourcing.

The Central Contract Sourcing scenario is based on the building block Procurement Contract (133), so the central contract’s basis is the same document type (including configuration) asthe procurement contract in the Procurement Contract scenario. It will therefore be copiedfrom the document type MK (quantity contract).

3.1.1.1 Defining Number Ranges

Procedure

1. Access the activity using the following navigation option:

SAP System SAP Headquarters’ System

IMG Menu Materials Management → Purchasing → Contract → Define

Number Ranges

Transaction Code SPRO

2. Choose Change Intervals.

3. If you want to use internal numbering for central contracts, check whether an adequateinterval already exists. If one does, note the number of the interval and go to step 6. If youneed a new interval, proceed with step 4.

4. On the Intervals screen, select a row, and choose Insert Interval . Then make the followingentries on the Insert Interval screen:

Field Name Description User Action and Values Comment

No Number rangenumber

Any new alphanumericnumber

From number Lower limit of theinterval

Any number that has not yetbeen assigned to an interval

Ensure thatlower and upper limits of theinterval together do not conflictwith any existinginterval






To number Upper limit of theinterval


Ensure thatlower and upper limits of theinterval together

do not conflictwith any existinginterval

Currentnumber

Last number assigned

Leave as initial value

Ext Internal (‘ ‘) or external (‘X’)number rangeindicator

Do not select

5. Choose Save.

6. If you want to use external numbering for central contracts, check whether an adequate

interval already exists. If one does, note the number of the interval and go to step 9. If youneed a new interval, proceed with step 7.







Ensure thatlower and upper limits of theinterval together

do not conflictwith any existinginterval




Currentnumber




Select

8. Choose Save.

9. The subsidiary’s system will inform headquarters about every release order (purchaseorder) posted relating to the central contract. The purchase order number from thesubsidiary’s system is not unique in the headquarters’ system. This number therefore hasto be supplemented by a new number, which is assigned to it in the headquarters’system. The original purchase order number is also recorded in the release order documentation. This number range is provided for the new purchase order number that is

to be assigned. A separate number range, which is not used by any other document type,should be set up for this purpose.














Ensure thatlower and upper limits of theinterval together do not conflict

with any existinginterval

Currentnumber




Do not select

11. Choose Save.

Result

All number ranges needed for the new central contract are defined.

3.1.1.2 Defining Document Type of Central Contract

Procedure




Document Types


2. Select document type MK (quantity contract) and choose Copy As…

3. On the Document Types Contract Change screen, make the following entries:


Type Purchasingdocument type

<YBCS>

Doc. TypeDescript.

Short descriptionof the purchasingdocument type

<Central Contract>






ItmInt Item number interval

Leave default value Determines thesize of stepsbetween defaultitem numbers

(default is 10)NoRgeInt Number range in

the case of internal number assignment

Enter the number rangeinterval ID youcreated/selected in theprevious step for internalnumbering

NoRgeExt Number range inthe case of external number assignment

Enter the number rangeinterval ID youcreated/selected in theprevious step for externalnumbering

NoRgeALE Number range inthe case of internal number assignment for ALE

Enter the number rangeinterval ID youcreated/selected in theprevious step for releaseorders from subsidiary’ssystem

ALE Dist Distributedcontract (ALE)

Select

<other fields> Leave all other fields withtheir default values

4. Choose Enter .

5. On the Specify object to be copied screen, choose Copy All .6. On the Information screen (shows number of dependent entries copied), choose Enter .

7. Choose Save.

8. Since only the item categories standard, material unknown, and material group aresupported for distributed contracts, all other item categories assigned to the centralcontract should be deleted. These three item categories are the maximum that issupported by any distributed contract. Depending on your needs, you can of coursefurther restrict the item categories allowed. For the current scenario, for example, only theitem categories standard and material unknown are required.On the Document Types Contract Change screen, select the procurement contract withthe type <YBCS> .

9. In the Dialog Structure subscreen, double-click Allowed item categories.

10. Select all the item categories apart from standard, material unknown, and materialgroup.

11. Choose Delete.

12. On the Specify objects to be deleted screen, choose all entries.

13. On the Information screen, choose Enter .

14. Choose Save.

Result

The new document type for central contracts is defined on the headquarters’ system.





3.1.2 Defining Cross-Company Code

Use

The purpose of this activity is to define a global (or cross-company) company code for thecompany code of the subsidiary. This is necessary to enable the transfer of release orders

from the subsidiary to the headquarters’ system.

There is only one cross-system company code for each company in the distributedenvironment (a company is represented by a company code in a system). This company codehas to be assigned to its cross-system company code in each system involved in thedistribution.

When sending an IDoc with company code-specific data, the company code is replaced withthe cross-system company code in all company code fields (in this scenario, the sender isalways the subsidiary system). When receiving this kind of IDoc, the reverse conversion takesplace in the target system (in this scenario, the headquarters’ system).

This kind of mapping is especially necessary when, for example, the company code for onesingle subsidiary is different in the subsidiary’s own system and in the headquarters’ system

to which some of the subsidiary’s data is transferred.

Cross-system company codes are used in the distribution with financial accounting. Althoughno financial accounting is involved on the headquarters’ side in the current scenario, thissetup has to be done.

In this scenario, the IDs of the cross-company code and the related company code will beidentical, both in the headquarters’ system and the subsidiary’s system. So for the subsidiarywith company code 1000 a cross-company code of 1000 will be created and assigned. If thecompany code in the headquarters’ system representing the subsidiary is different from thecompany code of the subsidiary in the subsidiary’s system, the mapping on the headquarters’side has to be adapted accordingly.

Prerequisites

Define a structure (in concept form) for all global company codes that are used in a distributedenvironment. These global company codes must be named the same in all systems to avoidany errors occurring in the distributed environment. Local company codes are assigned toglobal company codes in the individual systems.

3.1.2.1 Creating Cross-Company Code

Procedure

1. Access the activity using one of the following navigation options:


IMG Menu SAP NetWeaver → Application Server → IDoc Interface /

Application Link Enabling (ALE) → Modeling and Implementing

Business Processes → Global Organizational Units → Cross-

System Company Codes → Cross-System Company Codes

Transaction Code OB72

2. Choose New Entries.





3. On the New Entries: Overview of Added Entries screen, make the following entry:


Global CoCde Name of globalcompany code

1000 Global companycode of thesubsidiary

4. Choose Save.

3.1.2.2 Assigning Subsidiary Company Code to Cross-System Company Code

Procedure






System Company Codes → Assign Company Code to Cross-

System Company Code

Transaction Code OBB5

2. In the row for the company code of the subsidiary, make the following entry:




3. Choose Save.

3.1.3 Defining Setup for Automatic Transfer of CentralContract Changes

Use

The purpose of this activity is to ensure that new and changed central contracts areautomatically transferred from the subsidiary to the headquarters.

Basically, contracts can either be distributed manually using transaction ME308 (Send

Contracts with Conditions) or by setting up an automated process based on changedocuments and background jobs, which verify the changes and distribute IDocs to thesubsidiary.

Prerequisites

When setting up the distribution model in the headquarters’ system, the dependency betweenIDoc COND_A and IDoc BLAORD must be set.





Procedure



Section: Activating Data Filter for Message Type COND_A


Section: Activating Data Filter for Message Type COND_A

3.1.3.1 Maintaining Number Ranges for Change Pointers

Procedure



Transaction Code BDCP

2. Choose Change Intervals. If no number range exists, continue with the following steps.

3. Choose Insert Interval .

4. On the Insert Interval screen, make the following entries:


No 01 Identifies a number range interval

From number 1 Lower limit of aninterval

To number 9999999999 Upper limit of aninterval

5. Choose Save.

3.1.3.2 Activating Change Pointers Generally for Contract-Related IDocs

Procedure


SAP System SAP Headquarters’ SystemIMG Menu SAP NetWeaver → Application Server → IDoc Interface /


Business Processes → Master Data Distribution → Replication

of Modified Data → Activate Change Pointers - Generally

Transaction Code BD61

2. On the Activate Change Pointers Generally screen, select Change pointers activated –generally .

3. Choose Save.





3.1.3.3 Activating Change Pointers for Contract-RelatedIDocs

Procedure

1. Access the activity using the following navigation option:SAP System SAP Headquarters’ System




of Modified Data → Activate Change Pointers for Message

Types


2. If the message types BLAORD and COND_A are available on the Change View “ ActivateChange pointers for Message Type”: Overview screen, make the following entry for eachmessage type and proceed with step 6.


Active Select ALE - active indicator for various tools

3. If the message types BLAORD and COND_A are not available on the Change View “ Activate Change pointers for Message Type”: Overview screen, proceed as follows:


5. On the New Entries: Overview screen, make the following entries (depending on whichmessage type is missing):

Field

Name

Message Type Active

(ALE – active indicator for various tools)

Entry 1 BLAORD Select

Entry 2 COND_A Select

6. Choose Save.

3.1.3.4 Defining Variants for Report to Generate andDistribute IDocs

Use

To distribute central contract changes, you must schedule a report that reads the changepointers and generates IDocs from it. To do this, you need to:

• Define the variants for the report

• Schedule jobs, each with the report and a variant as one step

In this step, you will define the variants for the RBDMIDOC program. You can use system-defined variants for the standard message types.

Procedure










of Modified Data → Create IDocs from Change Pointers →

Define Variants

Transaction Code RBDMIDOC

2. On the ABAP Editor : Initial Screen screen, make the following entries:Field Name Description User Action and Values Comment

Program RBDMIDOC

Variants Select the radio button

3. Choose Change.

4. On the ABAP : Variants – Initial Screen screen, make the following entry:


Variant <name of variant>

for example CONTRACT

5. Choose Create.

6. On the Maintain Variant : Report RBDMIDOC , Variant CONTRACT screen, make thefollowing entry:


Message type BLAORD

7. Choose Attributes

8. On the Variant Attributes screen, make the following entry:


Meaning <description of

variant> for example variant forcentral contractdistribution

9. Choose Save.

10. Chose Exit .

11. On the ABAP : Variants – Initial Screen screen, make the following entry:


Variant <name of variant>

for example CONDITION

12. Choose Create.13. On the Maintain Variant : Report RBDMIDOC , Variant CONDITION screen, make the

following entry:


Message type COND_A

14. Choose Attributes

15. On the Variant Attributes screen, make the following entry:


Meaning <description ofvariant>

for example variant forcondition distribution





16. Choose Save.

3.1.3.5 Scheduling Jobs for IDoc Generation andDistribution

UseThe purpose of this activity is to schedule the jobs for the periodic creation of IDocs for thecentral contracts and their conditions. You will schedule the jobs for each defined variant andhence for each message type. For example, if central contracts are to be distributed, youmust plan a job for the message type (in this case BLAORD) that periodically checks thechanges and generates IDocs.

Procedure

1. Access the transaction using one of the following navigation options:


SAP ECC Menu Tools → CCMS → Background Processing → Define Job

Transaction Code SM36

2. On the Define Background Job screen, make the following entries


Job name <job name>

for example CONTRACT

Job class Classification of background jobsaccording to priorityand job type

<job classification>

for example B

Exec. Target Server name of anSAP instance onwhich thebackground jobshould be run

<Host name>_<ERPSystem name>_<ERPSystem number>

Use F4 inputhelp

3. Choose Start condition.

4. On the Start Time screen:

a. Choose the required starting time, for example Immediate.

b. Select Periodic job.

c. Choose Period values, then make a selection, for example Hourly .

5. Choose Save.

6. Choose Save.

7. Choose Step.

8. On the Create Step 1 screen, make the following entries:


Name Program name RBDMIDOC

Variant Name of the first variant youdefined,for example CONTRACT

9. Choose Save.10. On the Step List Overview screen, choose Create.





11. On Create Step 2 screen, make the following entries:


Name Program name RBDMIDOC

Variant Name of the second variant

you defined, for exampleCONDITION

12. Choose Save.

13. Choose Back .

14. Choose Save.

3.2 Subsidiary System

3.2.1 Defining Central Contract

UseThe purpose of this activity is to define all the settings for the central contract, which will –during processing – be distributed from the headquarters to the subsidiary system(s).

Even though the contract itself is created in the headquarters’ system, it is essential that thesetup of the central contract in the subsidiary closely matches the setup in the headquarters’system, because:

• Otherwise problems may occur in the replication process.

• The business meaning of contract details differs between headquarters and

subsidiary (for example, when payment terms are configured differently and only apayment terms identifier is transferred).

Prerequisites

The central contract is set up in the headquarters’ system and basic configuration isharmonized.

3.2.1.1 Defining Number Ranges

Procedure


SAP System SAP Business All-in-One Subsidiary’s System


Number Ranges


2. Choose Change Intervals.

3. Check whether there is already an adequate interval with external numbering, whichmatches the interval you defined for the central contract in the headquarters’ system. If such an interval exists, note the number and go to step 5. If you need a new interval,proceed with step 4.










Enter the lower limit of theinterval you defined for thecentral contract in theheadquarters’ system


Enter the upper limit of theinterval you defined for thecentral contract on theheadquarters’ system

Currentnumber




Select

5. Choose Save.

Result

The number range for the central contract is defined.

3.2.1.2 Defining Document Type of Central Contract

Procedure




Document Types


2. Select the document type MK (quantity contract) and choose Copy As…

3. On the Document Types Contract Change screen, make the following entries:


Type Purchasingdocument type

<YBCS>

Doc. TypeDescript.

Short descriptionof the purchasingdocument type

<Central Contract>

ItmInt Item number interval

Leave default value Determines thesize of stepsbetween defaultitem numbers(default 10)






NoRgeInt Number range inthe case of internal number assignment

Leave empty The number of the contract willbe among thedata transferred

for the contractfrom theheadquarters’system.Thereforeexternalnumbering isrequired.

NoRgeExt Number range inthe case of external number assignment

Enter the number rangeinterval ID youcreated/selected in theprevious step for externalnumbering

NoRgeALE Number range incase of internalnumber assignment for ALE

Leave empty In the subsidiarysystem theoriginal purchaseorder is assignedto the centralcontract.

ALE Dist Distributedcontract (ALE)

Do not select

<other fields> Leave all other fields withtheir default values

4. Choose Enter .5. On the Specify object to be copied screen, choose Copy All .

6. On the Information screen (shows number of dependent entries copied), choose Enter .

7. Choose Save.

8. Since only the item categories standard, material unknown, and material group aresupported for distributed contracts, all other item categories assigned to the centralcontract should be deleted. These three item categories are the maximum that issupported by any distributed contract. Depending on your needs, you can of coursefurther restrict the item categories allowed. For the current scenario, for example, only theitem categories standard and material unknown are required.On the Document Types Contract Change screen, select the procurement contract withthe type <YBCS>.

9. In the Dialog Structure subscreen, double-click Allowed item categories.

10. Select all the item categories apart from standard, material unknown, and materialgroup.

11. Choose Delete.

12. On the Specify objects to be deleted screen, choose all entries.

13. On the Information screen, choose Enter .

14. Choose Save.

Result

The new document type for central contracts is defined in the subsidiary’s system.





3.2.2 Defining Cross-Company Code

Use

The purpose of this activity is to define a global (or cross-company) company code for thecompany code of the subsidiary. This is necessary to enable the transfer of release orders

from the subsidiary to the headquarters’ system.

There is only one central system for each cross-system company code in the distributedenvironment. One company code has to be assigned to this cross-system company code ineach system involved in the distribution.

When sending an IDoc with company code-specific data, the company code is replaced withthe cross-system company code in all company code fields (in this scenario, the sender isalways the subsidiary system). When receiving this kind of IDoc, the reverse conversion takesplace in the target system (in this scenario, the headquarters’ system).

This kind of mapping is especially necessary when, for example, the company code for onesingle subsidiary is different in the subsidiary’s own system and in the headquarters’ system,to which some of the subsidiary’s data is transferred.

Cross-system company codes are used in the distribution with financial accounting. Althoughno financial accounting is involved on the headquarters’ side in the current scenario, thissetup has to be done.

In this scenario, the IDs of the cross-company code and the related company code will beidentical, both in the headquarters’ system and the subsidiary’s system. So for the subsidiarywith company code 1000 a cross company code of 1000 will be created and assigned.

Prerequisites

Define a structure (in concept form) for all global company codes that are used in a distributedenvironment. These global company codes must be named the same in all systems to avoidany errors occurring in the distributed environment. Local company codes are assigned to

global company codes in the individual systems.

3.2.2.1 Creating Cross-Company Code

Procedure





Business Processes → Global Organizational Units → Cross-System Company Codes → Cross-System Company Codes

Transaction Code OB72


3. On the New Entries: Overview of Added Entries screen, make the following entry:




4. Choose Save.





3.2.2.2 Assigning Subsidiary Company Code to Cross-System Company code

Procedure

1. Access the activity using one of the following navigation options:SAP System SAP Business All-in-One Subsidiary’s System




System Company Codes → Assign Company Code to Cross-

System Company Code

Transaction Code OBB5

2. In the row for the company code of the subsidiary, make the following entry:




3. Choose Save.

3.2.3 Assigning Purchasing Organization of Headquartersas Reference for Purchasing Organization of Subsidiary

UseThe purpose of this activity is to define the purchasing organization of the headquarters asreference for the purchasing organization of the subsidiary. This is a prerequisite for thesubsidiary’s purchasing organization to work with central contracts and post release ordersrelated to them.

Procedure



IMG Menu Enterprise Structure → Assignment → Materials Management

→

Assign purch organization to reference purch. OrganizationTransaction Code SPRO


3. On the New Entries: Details of Added Entries screen, make the following entries:


Purch.Organization

Name of thepurchasingorganization thatwants to accessthe reference data

1000 Subsidiary’spurchasingorganization






ReferencePurchasingOrg.

Name of thereferencepurchasingorganization

YV01 Headquarters’purchasingorganization

Release Order Indicator specifying thatrelease ordersagainst contractsare allowed

Select

Conditions Indicator specifying thatconditions of thereferencepurchasingorganization canbe accessed

Do not select

4. Choose Save.

Documents

Cross Co Code