ale customizing

8/12/2019 ALE Customizing

http://slidepdf.com/reader/full/ale-customizing 1/169

SAP AG 1999 June 29, 1999

Uwe SchweigBusiness Framework Support

ALE Business Processes

in Logistics



SAP AG 1999 June 29, 1999

Contents

The ALE business process concept

Distribution of master data in Logistics

SD-MM link

Distribution of information systems

Distributed purchase contracts

Overview of further business processes



SAP AG 1999 June 29, 1999

ALE Business Processes

An ALE business process is an integrated, cross-system business

process

ALE business processes run between:

Several R/3 Systems

Logistics, Financial Accounting and HR on separate systems, for example

R/3 and non-R/3 systems

Warehouse Management in R/3, external warehouse control system, for example

Integrated ALE business processes

Loose integration (asynchronous, message-based)

Close integration (synchronous)

A combination of both



SAP AG 1999 June 29, 1999

Example of an ALE Business Process

PRODUCTION

Headquarters

Exchange of messages

BLAORD,

BLAOCH

BLAREL

EKSEKS

FIDCMT

FIROLL

Local purchasing

Invoice verification

Accounting

Central purchasing

Purchasing

Information

System

BLAOR Contract/change

BLAOCH Change

BLAREL Release order statistics

EKSEKS Purchasing Information SystemFIDCMT FI document

FIROLL FI rollup



SAP AG 1999 June 29, 1999

In other words, ALE is….

A method and technique for supporting

distributed applications

A collection of distribution scenarios with the

aim of achieving distributed and integratedsystem configurations



SAP AG 1999 June 29, 1999

Contents



SD-MM link





http://slidepdf.com/reader/full/ale-customizing 7/169 SAP AG 1999 June 29, 1999

Contents, Master Data

Master data in Logistics

- ALE features that support master data distribution

- Reasons and prerequisites for distributing master data

- Individual master data objects



Master Data Distribution

Different ways of sending master data:

Sending changes by evaluating change pointers (SMD tool)

Initially, partner systems can also be supplied directly with the

appropriate master data („direct sending‟).

The receiving system can request master data from the reference

system. The request is sent by a particular message type(MATFET for material, for example). The reference system checks

whether the requested master data exists and whether it may be

sent (distribution model). If this is the case, the current status of

the master data is sent to the receiver (no delta download).



SMD Tool for Distributing Master Data

Master data (a material master, for example) is distributed by

evaluating so-called change pointers.

These change pointers (table BDCP) are generated directly

from the application (SMD tool = Shared Master Data) for

changes that are relevant for distribution (table TBD62).

A post-processing program (RBDMIDOC), which is startedmanually or scheduled periodically, selects the change

pointers and generates the summarized IDocs.



SMD Tool for Distributing Master Data

Appl icat ion

Create/change

master data

SMD

Customizing

Engineer ing c hange

management

master data

ALE layer

Generate

change

document

Change documents Change pointers

ALE relevant?

Write pointers

Generate IDocs

Batch job / manual

Standard ALE

outboundprocessing

MC

Master data



Controlling / Influencing the Distribution Procedure

Data filtering in the distribution model

Segment filtering

Reducing IDocs

Taking dependencies between master data objects intoconsideration



Data Filtering

General data

Short text

Plant

Warehouse/batches

Material valuation

Product group

...

Filter at plant level

Filter objects can be used with each communication relationship to

prevent certain application data from being sent.

If a segment within a hierarchy contains a filter, only this segment

and the segments dependent on it are filtered



Logical Combination of Filters

Filter groups are used to combine filter objects (AND /OR )

(Division 10 AND mat grp 001) OR (division 20 AND mat grp 005)

Within one filter group:

Logic ORing between filters of the same filter object type

(Plant 1000 OR plant 2000)

Logic ANDing between filters of different filter object types

(Division 10 AND mat grp 001)

Data is sent if it is defined in at least one filter group (logic

OR ing of filter groups)



Segment Filtering / Field Conversion

IDoc segments that are not required are filtered out from theALE layer. These segments are not sent.

Segment filtering is data-independent, in other words you can

specify the segments that are to be filtered out for a particular

message type and the corresponding recipient.

In contrast to this, filtering via filter objects in the distribution

model depends on the actual data that is to be transferred in

the IDoc.

The contents of the IDoc fields can be adapted to the

requirements of the recipient by converting the fields usingconversion rules.



Reducing IDocs

An individual, reduced message type can be derived from the

existing message types in the standard system for master data

objects

The customer-specific message type for a master data object

(material, for example) is derived from the „standard maximum

IDoc‟ (MATMAS03, for example) of the object You can choose segments and fields from the overview of the

assigned standard maximum IDoc by selecting or deselecting

them

Required entry fields and mandatory segments cannot be

deselected

Advantage: reduction at field level (<> filtering), no

modifications to the standard system required



Reducing IDocs

Initial screenWhen it is generated, the new

message type is linked to the

structure of the reference message

Structure description

Activation of the segments of themessage type

Field list

Fields that are to be sent must be

activated in the active segments

Maintain reduction: AccessView (message type) ________

Derived from ________

Short text ________

Structure description

MATMAS03 Material master

E1MARAM General dataE1MAKTM Short text

E1MARMM Unit of measure

E1MARCM Plant data

Field list E1MARAM

_ MATNR Material no.

_ MTART Material type

_ MBRSH Industry sector _ MATKL Material group

_ WRKST Basic material

...

T ki D d i B t M t D t Obj t i t



Taking Dependencies Between Master Data Objects intoAccount: Serialization, Dependent Objects

Serialization of message types

Some items of master data contain dependent objects and should

therefore be distributed together (material and classification of the

materials, for example).

These objects must be processed sequentially (1st material, 2nd

classification) in inbound processing on the receiving system.

The messages are grouped according to message types and processed in the receiving

system. Messages of one particular message type are not serialized. Available for message types from the master data area

For this purpose, dependent message types are combined in serialization groups in

which the individual message types are processed in a fixed sequence.

Process:

Generation of the IDocs for the serialization group using change pointers in the

sending system (RBDSER01). Generated IDocs are sent (RBDSER02).

System checks whether all IDocs have been sent and sends an IDoc of the type

SERDAT to the receiver (RBDSER03).

Serialized processing of the IDocs sent previously to the receiver is triggered by

processing the SERDAT01 IDoc.

T ki D d i B t M t D t Obj t i t



SAP AG 1999 June 29, 1999

Taking Dependencies Between Master Data Objects intoAccount: Serialization, Dependent Objects

Dependent objects

With some items of master data, it only makes sense to distribute

an object to a specific system if other objects are also distributed

to this system (purchasing info record and vendor).

Dependencies describe relationships, with reference to whether the

objects can be distributed among

Message types

BAPI methods and message type

BAPI methods

Before an object is distributed, ALE determines whether dependent

objects are also distributed to this destination. The object is only

distributed if this is the case.



SAP AG 1999 June 29, 1999

Administration Programs

You can schedule the following programs periodically:

Outbound

Generation of IDocs from change pointers

Sending of IDocs in batch jobs

Status conversion after successful communication

Serialization groups

Inbound

Forwarding of IDocs to the application

Sending of audit messages

General

Active monitoring



SAP AG 1999 June 29, 1999

Documentation

Further documentation:

R/3 library:

BC - Changes to the SAP standard system

CA - ALE programming guide

CA - The IDoc interface

Knowledgeware

R/3 Interface Adviser

R/3 transactions

CMOD (project management of SAP enhancements)

BAPI (BAPI browser)



SAP AG 1999 June 29, 1999








SAP AG 1999 June 29, 1999

Reasons for Distributing Master Data

Strategic instrument

Standardization of object numbers

Standardization of company-wide statistics and evaluations

(company-wide profitability analysis, OAS, company-wide logistics

evaluations, for example)

Transparency of company-wide processes

Prerequisite for other distribution scenarios

Preparation for a more extensive distribution project (1st

subproject to gain experience, for example)

Di ib bl M D Obj i L i i



SAP AG 1999 June 29, 1999

Distributable Master Data Objects in Logistics

Materials

Debtors

Creditors

Purchasing info records

Source lists

Conditions

BOMs

Article masters

Additionals

Assortments

Listing conditions

Price lists

Product catalogs

Documents

Change masters

Project structure plans

Document structures

Class systems

Prerequisites for Master Data Distribution



SAP AG 1999 June 29, 1999

Prerequisites for Master Data Distribution

Coordinated Customizing, depending on the master

data, check tables, and views to be distributed Organizational units

(such as sales areas, plants, purchasing organizations, and so on)

Check tables (such as divisions, material groups, MRP groups, and soon).

Desirable

Central, standardized Customizing throughout the company(Central Customizing client / central Customizing system)

Problem: control data distributed to many systems(CTS is „awkward‟, manual intervention!!)

Additional distribution of dependent objects(such as classes, characteristics, documents ..).



Material Master Distribution (2)



SAP AG 1999 June 29, 1999


C, D

A, B, C, D

A, B, D A, DB, C

Productive branches

Several maintenance systems (depending on the material or material

grouping, for example), 1 reference system for coordination,

supplementary maintenance is possible locally in the branches

Reference system

(without active maintenance or

with restricted maintenance)

Maintenance system for

articles A,B

Maintenance system for articles

C,D

Selective distribution in the

productive branches

(according to articles A,B,C,D

and views)

A, B




SAP AG 1999 June 29, 1999


A,B,

C,D

(A,B)

C,D

A,B

(C)

A,B,C,D

A,B,D

System without active

maintenance

Reference system R

Maintenance system only

for articles A,B

(productive system P2)

Maintenance system only

for articles C,D(productive system P1)

D

No material master

maintenance (productive

system P3)

Several maintenance systems in production operation. 1 reference system

for coordination



SAP AG 1999 June 29, 1999

Experience with Customers

Mostly 1 central maintenance system with the corporate-wide

data (design view, for example)

Views that are relevant locally are created locally

(plant-dependent settings, for example)

Problem with different valuations of stock transfers

Central Customizing is not always possible from a „political‟

or organizational perspective

Risk of „Customizing split‟



C t t M t D t



SAP AG 1999 June 29, 1999






Material Master



SAP AG 1999 June 29, 1999

Material Master

Material Master

What is a Material Master?



SAP AG 1999 June 29, 1999

What is a Material Master?

Central source of information for Logistics

Organized into several views

Design data

Production data

MRP data

Sales data

Accounting data

……..

The most important organizational unit is the plant, otherwise

the warehouse number, sales area.

Various material types control the most important attributes

Distribution of Material Masters



SAP AG 1999 June 29, 1999

Distribution of Material Masters

Available since 3.0A

Direct sending

Sending via change pointers

Reduction possible

Listing possible

Dependencies: conditions, purchasing info records, source

lists, BOMs

ALE Customizing



SAP AG 1999 June 29, 1999

Custo g

Message types: MATMAS (send), MATFET (retrieve)

IDoc types: MATMAS03

Filters in the distribution model,

Valuation area, external material group, warehouse number,

storage location, material, material type, division, language key,

sales organization, distribution channel, material group, plant

General ALE Customizing

Listings (3.0x)

Use of material classes

Serialization group GRP_MATMAS

Material

Document

Classification

Distribution Restrictions



SAP AG 1999 June 29, 1999

Not distributed/supported:

Reference material

Scheduling of changes

Unit of measure group

QM inspection setup

Manufacture of co-products

Average plant stock

Revision level (after 4.5A separate IDoc: ECMREV01)

Assignment of configurable material (standard product) and variant configuration

Export licenses/customs tariff preferences

Production versions

Document data (separate IDoc: DOCMAS04)

Sales prices (separate IDoc: COND_A1)

Classification (separate transfer programs for classification, separate IDoc:

CLFMAS01)

MRP area cannot be distributed. (New object for 4.5A)

How are Material Masters Distributed Effectively?

http://localhost/var/www/apps/conversion/tmp/scratch_1/cond_A1_d.htm

http://localhost/var/www/apps/conversion/tmp/scratch_1/cond_A1_d.htm



SAP AG 1999 June 29, 1999

y

Where is information on the individual views of the material stored in

the company?

One central location? At what organizational level?

Different locations for different information?

Who is to be authorized to maintain the data?

Central maintenance of all material master data? Where?

Different locations maintain different views of the same material?

One location maintains all the views of a material (material group-related)?

Who requires which material info for their processes?

All materials required everywhere?

Selective distribution of materials and views required?

Who initially creates a new material master? (Material number assignment)

Who is to be informed of changes and how?



What is a Customer Master?



SAP AG 1999 June 29, 1999

Central source of information for Logistics and Accounting

Organized into several views at the levels

Client

Company code

Sales area

Different account groups control the most important attributes

Distribution of Customer Masters



SAP AG 1999 June 29, 1999


Direct sending


Reduction possible

Listing possible

Dependencies: conditions, banks, G/L accounts

(reconciliation account)

ALE Customizing



SAP AG 1999 June 29, 1999

g

Message types: DEBMAS

IDoc types: DEBMAS03


Company code, debtor, credit control area, division, sales

organization, distribution channel


Listings (3.0x)

Serialization group: no specific group predefined




SAP AG 1999 June 29, 1999


Addresses of contacts are not distributed

Long texts are not attached to the change documents



Vendor Master



SAP AG 1999 June 29, 1999

Vendor Master

Vendor Master

What is a Vendor Master?



SAP AG 1999 June 29, 1999

Central information source for Logistics and Accounting

Organized into several views at the levels

Client

Company code

Purchasing organization

Different account groups control the most important attributes

Distribution of Vendor Masters



SAP AG 1999 June 29, 1999


Direct sending


Reduction possible

Listing possible

Dependencies: conditions, banks, G/L accounts

(reconciliation accounts etc….).

ALE Customizing



SAP AG 1999 June 29, 1999

Message types: CREMAS

IDoc types: CREMAS02


Company code, purchasing organization, creditor


Listings (3.0x)

Serialization group: no specific group delivered




SAP AG 1999 June 29, 1999


Dunning data is only posted to the default dunning area with

inbound processing of vendor master data

How are Creditors Distributed Effectively?



SAP AG 1999 June 29, 1999

How is the vendor handled in the organizations within the company (company code,

purchasing organization)?

Always in the same way or in different ways? How is the company code / purchasing organization structured in the distributed systems?

How are payments to the creditor processed (centrally, decentrally, grouped,... )?

Where is the information on the individual views currently stored?

One central location or different locations for different information

Who is to be authorized to maintain and create data?

Central maintenance of all creditor master data

Different locations maintain different views of the same creditor

(with different company codes, purchasing organizations in the distributed systems)

One location maintains all views of a creditor, a different location maintains other creditors

Who needs which creditors for their processes? Are all creditors needed everywhere or is selective distribution required?

Who is to be informed of changes, how, and when?

Purchasing Info Records



SAP AG 1999 June 29, 1999

g

Purchasing Info Records



Distribution of Purchasing Info Records



SAP AG 1999 June 29, 1999

Available since 3.1G

Direct sending


Reduction possible

Dependencies: material, vendor, (conditions)

ALE Customizing



SAP AG 1999 June 29, 1999

Message type: INFREC

Filters in the distribution model

Material, plant, vendor, purchasing organization, listing

Dependent message type


Listings (3.1x)

Serialization group (after 4.0A)

Material

Vendor

Purchasing info record

Application Customizing



SAP AG 1999 June 29, 1999

Coordination of the number ranges

IMG: Materials Management -> Purchasing -> Purchasing InfoRecord ->Define Number Ranges




SAP AG 1999 June 29, 1999

Not distributed:

Customs tariff preference data

Order price history

The conditions are not changed when the info record is

posted

If the filter objects plant, material, or listing are used, the plantfield for cross-plant info records or the material field for non-

stock materials must be assigned SPACE.

Source List



SAP AG 1999 June 29, 1999

Source List

What is a Source List?



SAP AG 1999 June 29, 1999

The source list lists the sources of supply that are allowed (or

not allowed) for a material in a plant within a specified period

of time.

The term “source of supply” refers to a vendor or an outline

agreement.

Each source of supply is defined by a source list record in the

source list.

Source lists are maintained

Manually

From an outline agreement

From an info record

Automatically

Utilization of the Source List



SAP AG 1999 June 29, 1999

Source list records are used to determine the effective source of

supply.

When the source of supply is determined, the source of supply to

which a purchase requisition is to be assigned is specified.

Further options:

Displaying the source list for a material

Simulating automatic source determination

Distribution of the Source List



SAP AG 1999 June 29, 1999


Direct sending

Sending via change pointer

No reduction

Dependency: material, vendor, (contracts)

ALE Customizing



SAP AG 1999 June 29, 1999

Message type: SRCLST

Filters in the distribution model Material, plant, vendor, purchasing organization, listing

Dependent message type (4.0A)


Listings (3.1x)

Serialization group (as of 4.0A)

Material

Vendor

Source list




SAP AG 1999 June 29, 1999

Source list requirement (plant-related):

IMG: Materials Management -> Purchasing -> Source List ->Define Source List Requirement at Plant Level

Source list requirement (material-related):

Material master record -> Purchasing view -> Source list requirement




SAP AG 1999 June 29, 1999

Not distributed:

Source list records with reference to a scheduling agreement

If the filter objects vendor or purchasing organization are used,

the vendor field must be assigned SPACE for cross-vendor

source list records and the purchasing organization field for

cross-purchasing-organization records.

Conditions



SAP AG 1999 June 29, 1999

Conditions



Introduction: What is Implemented?



SAP AG 1999 June 29, 1999

Inbound processing

Transfer of IDocs to the master conditions Axxx, Konh, Konp,Konm/Konw

Also for purchasing info records

Also for document-related conditions (contracts)

Also for purchasing bonuses (agreements)

Not for other agreements (KONA reference)

Not for free goods

Option of modifying IDocs by means of customer

functions

IDoc and Condition Technique: Conditions in R/3



SAP AG 1999 June 29, 1999

Overview

Example: the usage A = Pricingthe application V = Sales and distribution

Condition type

...

PR00 - Price

PR01 - Price incl. VAT

RA01 - % disc. from gross

RB00 - Absolute discount

SKTO - Cash discount

...

Calculation scheme Access sequence

T685

Condition tables

Condition records

T683

10 PR00 Price 0

20 PR02 Price rise 0

30 PB00 Gross price 0 X

40 Gross 0

50 K004 Material 0

60 RA01 % disc. from gross 40...

10 005 Customer/material 0

20 006 Price list/mat 0 x

30 006 Price list/mat 3 x

40 004 Material 0 x

50 029 Material group 0 x

...

T682

A005

A001

A999

Application x

Condition type x

Variable key x

Date until x

Link (knumh)

KonhKonpKonm

Konw



IDoc and Condition Technique: Concepts



SAP AG 1999 June 29, 1999

Concepts

IDoc type: COND_A01Determines the hierarchical structure of the IDoc for exchanging

prices/conditions

IDocs and their segments are assigned to the IDoc type

Message type: COND_A is assigned to the IDoc type

Reduction message types are possible on the customer side

Reduction capability: individual fields of the IDoc segments can be

transferred in a reduced form, in other words without data

Entire IDoc segments can be excluded from the transfer

IDoc and Condition Technique: Implementation ofOutbound Processing



SAP AG 1999 June 29, 1999

g

Manual selection and distribution

For each condition type by displaying condition records (conditioninfo) with the following selection options:

„Valid on‟ date or validity period

Selection checkbox with single, block, and complete selection

options

Display name of the condition table

Selection (reduction) message type and possible target system

Transfer of the selected data to send module

MASTERIDoc_CREATE_COND_A

In the ALE layer: select, filter, transfer recipient...

IDoc and Condition Technique: Outbound Processing



SAP AG 1999 June 29, 1999




SAP AG 1999 June 29, 1999

Automatic selection and distribution

Processing of the change documents COND_A from conditionand price maintenance using the function module

MASTERIDOC_CREATE_SMD_COND_A

Called via report RBDMIDOC with the message type COND_A as a

parameter

Checks whether a system is interested in the data

Structures and sends the IDoc with the function module

„MASTERIDOC_CREATE_COND_A’

At the ALE layer: Select, filter, transfer recipient...

IDoc and Condition Technique: Special Features OutboundProcessing



SAP AG 1999 June 29, 1999

Filter and distribution function

VAKEY in the E1KOMG segment E1KOMG contains (almost) all of the fields that can be used

as key fields in condition tables

E1KOMG extended to include important fields from the

condition header

(usage, application, table number, condition type, retailpromotion number, ..).

E1KOMG extended to include fields for conditions with a

reference (for contract, info record, for example) =

(purchasing document category, type, purchasing group,..).

Call customer function for data enhancement

Customer-specific segment at E1KOMG level is possible for

providing further filter and distribution functionality



IDoc and Condition Technique: Special Features OutboundProcessing



SAP AG 1999 June 29, 1999

Validity periods

Manual sending The individual conditions selected are sent together with their

validity range

Automatic sending

For each condition record number, all the validity periods are

determined for which the to_date >= today‟s date. These

validity periods are sent.

(Consistency between source and target system)

IDoc and Condition Technique: Special Features Inbound Processing



SAP AG 1999 June 29, 1999

Determined by RV_CONDITION_COPY

The condition records are always recreated in the target system,in other words, a new condition record number is always

assigned.

Time gaps that exist in the source system because of

condition changes will not always occur in the target system.

Periods that are linked via the condition record number arelost

Maintenance for the conditions cannot be split; prices in the

source system and scales in the target system, for example

When sending using change documents, all affected validity

periods >= today‟s date are sent for each condition recordnumber (consistency).

Customizing: Prerequisites



SAP AG 1999 June 29, 1999

The Customizing data of the condition technique is not transferred

Customizing must be identical in the source and target systems Certain conversions, however, are possible, for example

Renaming the condition type

Renaming the condition table

The following are not possible

Conversion of a percentage type to an amount condition type

Conversion of a value scale to a quantity scale

Customizing: Prerequisites



SAP AG 1999 June 29, 1999

The master data must be available and identical in both the

source and target system.

ISO standardization

Countries, quantity units, currencies, and associated amounts

are transferred to ISO standards. If there is no ISO code for the

SAP_Code, the SAP_Code is transferred (outbound)

If an ambiguous ISO-SAP conversion is not possible in inboundprocessing, an error message is output

Modification / Customer Enhancements: Other



SAP AG 1999 June 29, 1999

Reduction of segments

The segments for the value or quantity scales can be excludedfrom the transfer (E1KONM, E1KONW)

No scales are created in the target system as a result.

Because of the new structures created, existing scales may

no longer be valid.

Reduction to field level

Field contents can be assigned a „reduce character‟ (for example

= / ).

Unlike in other master data transfers, the values of the

corresponding fields do not remain in the target system and

are initialized instead.

Serialization: IDoc = Logical Unit



SAP AG 1999 June 29, 1999

A logical unit for conditions consists of

Application + condition type + condition table + VAKEY All data that is to be transferred and that belongs to a logical unit

is combined in an IDoc and sent (in other words, specifically all

time periods).

This unit is also the basis for serialization in inbound processing

For inbound processing, only more recent data can be

processed for a logical unit.

BOMs



SAP AG 1999 June 29, 1999

BOMs

Distribution of BOMs



SAP AG 1999 June 29, 1999


Direct sending Sending via change pointer

No reduction provided

Dependency: material, documents, classes

ALE Customizing



SAP AG 1999 June 29, 1999

Message type: BOMMAT

Filters in the distribution model BOM usage, BOM status, plant


No classification for BOMs -> no ALE listing

No serialization group in the standard system



Customer Enhancements - BOMs



SAP AG 1999 June 29, 1999

Outbound processing: not planned

Inbound processing: not planned



Contents



SAP AG 1999 June 29, 1999



SD-MM link




Contents, SD-MM Link



SAP AG 1999 June 29, 1999

SD-MM link

- Stock transfer between distributed systems

- „Separate Sales and Shipping‟ Scenario

- Assigned standard purchase order

- External procurement

- Use of MM-SD scheduling agreements

- VMI (Vendor Managed Inventory)

Scenario: Stock Transfer Between Distributed Systems



SAP AG 1999 June 29, 1999

Requirement, planned order,

purchase requisition

Purchase order

Shipping notification

Incoming invoice

Goods receipt

Sales order

Delivery

Billing document

Confirm sales orderConfirmation

Goods issue

Purchase

order change

Order change

ORDERS

ORDCHG

ORDRSP

ORDRSP

DESADV

INVOIC

Physical stock transfer

System of the ordering plant System of the supplying plant



ALE Customizing



SAP AG 1999 June 29, 1999

Maintain distribution model:

Message types:ORDERS - Purchase order

ORDRSP - Order confirmation

ORDCHG - Purchase order change

DESADV - Shipping notification

INVOIC - Billing (incoming invoice)

Maintain or generate partner profiles

Set error handling using the following standard tasks:

ORDCHG_Error - 8046, ORDERS_Error - 8115, ORDRSP_Error - 8075, DESADV_Error - 8178, INVOIC_MM_Er - 8057

Maintain conversion for text IDs

Define EDI settings for inbound processing of the sales order

Settings: IMG->Sales and Distribution->Electronic Data Interchange->EDI Messages

Perform consistency checks: Check technical consistency / RBDMMSD1 - Check application consistency /

Check control data consistency




SAP AG 1999 June 29, 1999

Set message control for the following message types:

Local sales:

NEW - Outbound purchase order and purchase order change

Central shipping:

BA00- Outbound order confirmation

LAVA - Outbound shipping notification

RD00 - Outbound billing

Confirmation control in local sales

A confirmation control key must be set up with order confirmations and shipping notification.

EDI settings for inbound processing of the incoming invoice in local sales

Settings can be reached via IMG->Materials Management->Invoice Verification->EDI

Master Data



SAP AG 1999 June 29, 1999

In the order system

- Vendor master

- Purchasing info record (alternatively - customer/material/info record)

- Message condition records

In the shipping system

- Customer master- Customer/material/info record (alternatively - purchasing info record)


USER EXITS in Outbound Processing



SAP AG 1999 June 29, 1999

CUSTOMER FUNCTIONS:

ORDCHG - Purchase order change : MM06E001

ORDERS - Purchase order : MM06E001

ORDRSP - Order confirmation : SDEDI001

INVOIC - Billing : LVEDF001

FORM routines:

DESADV - Shipping notification : LVED2FZZ

USER EXITS in Inbound Processing



SAP AG 1999 June 29, 1999

CUSTOMER FUNCTIONS:

ORDERS -Sales order : VEDA0001

ORDCHG - Sales order change : VEDB0001

ORDRSP - Order confirmation : MM06E001

INVOIC - Incoming invoice : FEDI0001

DESADV - Shipping notification : MM06E001, LMELA010

FORM routines:

ORDERS - Sales order : LVEDAF0U (for reasons of compatibility)

ORDCHG - Sales order change : LVEDBF0U (for reasons of compatibility)

Example of Using a CUSTOMER FUNCTION in InboundProcessing



SAP AG 1999 June 29, 1999

Determination of an order type for the orders resulting from ALE

communication:

Enhancement: VEDA0001, EXIT number: 006, function module:

EXIT_SAPLVEDA_006

Call in the function module: IDoc_INPUT_ORDERS



Scenario: Decentral Sales, Central Shipping, Assigned standard purchase order



SAP AG 1999 June 29, 1999

Status,

Confirmation

Sales order

Purchase order


Incoming invoice

Goods receipt

Sales order

Delivery

Billing


Goods issue

Order changePurchase

order change

ORDERS

ORDCHG

ORDRSP

ORDRSP

DESADV

INVOIC

Physical stock transfer

PReq

Decentral sales Central shipping

Change

Process Description



SAP AG 1999 June 29, 1999

This scenario is based on a sales order. Customizing at the schedule line level is

defined to generate a PReq when data is saved. The update triggers an event that starts

to convert the PReq into a purchase order (event „ALECREATED‟ for BUS2032). This

purchase order is exported to central shipping (logical message type ORDERS). The item

category ALEN that is used for this purpose has the flag „ALE relevant‟ which causes a

further status to be managed. This status shows whether an order confirmation has

already been returned. Inbound processing of the order confirmation (logical message

type ORDRSP) sets this status in the sales order. In central shipping, an ATP check can

be performed in the sales order. The result appears as a confirmation in local sales.

Changes to the sales order of local sales are processed further via the event

„ALECHANGED‟ for BUS2032. In other words, the change is forwarded to the purchase

order and a change message is sent (logical message type ORDCHG).

The order confirmation is stored with the purchase order.

The shipping notification generated during delivery in central shipping can also be sent

and is stored in local sales as a notification for the purchase order.

Billing of the sales order in central shipping generates a message (logical message type

INVOIC) that is stored in local shipping as an incoming invoice for the purchase order.

The goods movement is not mapped as an interface. After goods are physically

transported, a GR is performed for the purchase order.

External Procurement, Without ALE Scenario



SAP AG 1999 June 29, 1999

Third-party

purchase orderSales order

Delivery to customer

Goods issue

PReq

„GR‟

Vendor Third-party vendor

Sales order

Purchase

order

MM

Customer

SD / MM SD



Scenario: Local Sales, Central Shipping,External Procurement

MM SD / MM SDEDI



SAP AG 1999 June 29, 1999

Third-party

purchase order


Incoming invoice

Sales order

Delivery to customer

Billing of

internal allocation


Goods issue

Order changePurchase

order change

ORDERS

ORDCHG

ORDRSP

ORDRSP

DESADV

INVOIC

PReq

Billing, sales order

St-GR,

FI doc.

Decentral sales Central shipping

Create /change

Sales order

Purchase

order

MM

Customer

SD / MM SDEDI

message

Status,

Confirmation

Billing

Confirmation

GR

Process Description

This scenario is based on a sales order. Customizing at the schedule line level is defined

t t thi d t PR Th d t t i th t „ALECREATED‟ f



SAP AG 1999 June 29, 1999

to generate a third-party PReq. The update triggers the event „ALECREATED‟ for

BUS2032. This generates a purchase order from the PReq via the function module

„PUR_ORDER_CREATE_VIA_SD_EVENT‟. The purchase order is sent to the system of

the delivering plant via message type ORDERS. In SD, the item categories (in the

standard ALE system) are assigned the flag „ALE relevant‟. This means that an additionalstatus is managed in the sales order (order confirmation status). If the order is created,

the status is unconfirmed. It is set to confirmed by processing the order confirmation

(ORDRSP). (In other words when the confirmation returns from the vendor system).

The ship-to party is forwarded from the sales order to the third-party purchase order and

then to the sales order in the vendor system via the ORDERS message. The goods from

the vendor system are shipped directly to the ship-to party. Changes to the sales order

are forwarded to the purchase order via the event „ALECHANGED‟ for BUS2032 and sentto the vendor system via the message control of the purchase order (message type

ORDCHG).

A shipping notification can be generated on the basis of logical message type DESADV.

Inbound processing of the shipping notification generates a static goods receipt for the

purchase order. In other words, the purchase order history is updated and an FI

document is generated (stock changes/GR//IR). This goods receipt is the condition for

billing the original order for the end customer. Without a static goods receipt, billingcannot be carried out until an incoming invoice is posted for the purchase order.

Whether goods receipt or invoice receipt is the basis for billing is determined in the SD

copy control for order-related billing.

Billing for the sales orders in the vendor system can be sent via the logical message

type INVOIC. An incoming invoice is created in the order system.

ALE Customizing



SAP AG 1999 June 29, 1999

Maintaining the distribution model:

Message types:

ORDERS - Purchase order

ORDRSP - Order confirmation

ORDCHG - Purchase order change

DESADV - Shipping notification

INVOIC - Billing document (incoming invoice)

Maintain or generate partner profiles

Set error handling using the following standard tasks:

ORDCHG_Error - 8046, ORDERS_Error - 8115, ORDRSP_Error - 8075, DESADV_Error - 8178, INVOIC_MM_Er - 8057

SD_PO_Err - 8097(Error generating purchase requisition from PReq for sales order), SD_PO_ChgErr - 8114 (Change purchase

requisition)

Maintain conversion for text IDs

Define EDI settings for inbound processing of the sales orderSettings: IMG->Sales and Distribution->Electronic Data Interchange->EDI Messages

Perform consistency checks: Check technical consistency / RBSDMM1 - Check application consistency /

Check control data consistency



Application Customizing (2)



SAP AG 1999 June 29, 1999

Further settings in local sales:

Set item categories ALEN and ALES (third-party) in SD to „ALE relevant‟

(shipment)

Order type, item category, account assignment category, for schedule line

category CS Maintain EKORG, EKGRP, creditor, order type, plant, storage location,

movement type in the purchasing organization.

Master Data



SAP AG 1999 June 29, 1999

In local sales

- Vendor master (represents central shipping)

- Purchasing info record (alternatively - customer/material/info record)


In central shipping- Customer master (represents local sales)

- Customer/material/info record (alternatively - purchasing info records)




Weaknesses of the Stock Transfers and SeparateSales and Shipping Scenarios



SAP AG 1999 June 29, 1999

1. Valuation problems arise if a moving average price is used for internal stock

postings in the issuing plant (stock transfer scenario)

2. The ATP check option in the supplying plant is lost during distribution (stock transfer

scenario, the stock transfer purchase order in the integrated system can check

availability).

3. No synchronous ATP check in the sales order (separate sales and shipping)

4. No stock in transit is managed.

5. Zero quantity cannot be processed as a confirmation quantity in the purchase order

6. Deletion of deliveries is not updated in the purchase order.

7. Deletion/canceling of sales items is not mapped.

8. Deletion/changing of purchase order items without checking the processing status of

the order in the other system.




SAP AG 1999 June 29, 1999

SD-MM link





- Usage of MM-SD scheduling agreements


Alternative Processing of Stock Transfers ViaScheduling Agreements



SAP AG 1999 June 29, 1999

MM scheduling

agreement

Incoming invoice

Delivery

SD scheduling

agreement

Billing

document

GI

MRP

Forecast delivery

schedule


Invoice

Clearing account Clearing account Clearing

GR

Credit memo display Accounting

document

Payment run Payment

notification

1 , 2

2

11

22

2 Payment

notification

33

3

2

Inventory posting




SAP AG 1999 June 29, 1999

SD-MM link





- Usage of MM-SD scheduling agreements


Application Example VMI (Vendor Managed Inventory)

C stomer s stem Vendor s stem



SAP AG 1999 June 29, 1999

Generate purchase order

Confirm generated

purchase order

Sending purchase

order change messages

to the vendor

Check purchase order

Release purchase

order

VMI MRP

Generate sales order

Send ORDRSP

Process ORDCHGORDCHG

ORDRSP Processing of

these tasks,

including

error

handling, via

Workflow

Customer system Vendor system

PROACT

Update statistics,

send sales dataImport sales figures

Process Description

Th t id hi h d ith l fi d t k i f ti



SAP AG 1999 June 29, 1999

The customer provides his or her vendor with sales figures and stock information

to enable the vendor to perform MRP.

In the receiving system, a purchase order is generated for one of the purchase

order confirmations received via EDI. The customer can use this function toreceive information on sales orders from the vendors, which the vendor has

created for the customer as part of replenishment planning. In the customer

system, a purchase order is then generated, which represents the opposite of the

vendor sales order.

A purchase order confirmation is generated. The number of the sales order is

entered as a reference number in the purchase order. A purchase order change

message is then sent to the vendor, which informs the vendor system of thepurchase order number from the customer system.

Contents



SAP AG 1999 June 29, 1999



SD-MM link

Distribution of the Logistics Info Systems



Data Warehouse Concepts



SAP AG 1999 June 29, 1999

OnlineTransaction

Processing

DATA

WARE-HOUSE

OLTP

OLAP

Analysis tools

OnlineAnalytical

Processing

Summarized information

Integrated application modules

ExternalData

Sales andDistribution

FinancialAccounting

ProductionPlanning

MaterialsManagement

Logistics Data Warehouse



SAP AG 1999 June 29, 1999

ProductionPurchasingSales and

Distribution

Individual Info Structures

Plant Management Production/Sales and Distribution

Info structure: Purchasing

Characteristics

Plant

Material

Vendor

...

Periodicity Key figure

Monthly

Weekly

Daily

...

Order quantity

Order value

Number of deliveries

Last purchase order...

Standard info structures

LogisticsInformation

Warehouse

Various

Info structurescontained in the

standard system

Measurable sizes

Quantitative keyfigures

Qualitative key

figures

Summarization criteria

Characteristics

Periodicity

Info structures

Transparent

Online Transaction Processing



SAP AG 1999 June 29, 1999

OLTP

RV RF

RM-PPS

RM-MAT

SAP R/3 SAP R/2

LIS Update

FISD

MM PP

LIS update for processdata handling

Extraction

Summarizing Calculation of key

figures

OLTP systems

Mapping of businessprocesses

Administration of masterand process data

NonSAP systems

Application Link Enabling (ALE)



SAP AG 1999 June 29, 1999

ALE is available in the LIS from Release 3.0 onwards

Inventory Controlling

Purchasing Information System

Sales Information System

ALE in the LIS: Concept



SAP AG 1999 June 29, 1999

Local system 1 Central system Local system 2

Document

Headquarters

ALE Level 1 DocumentALE Level 1

ALE Level 2 ALE Level 2



ALE in the LIS: Advantages



SAP AG 1999 June 29, 1999

Receive statistical data from local systems

Store detailed statistical data in local systems

Store summarized statistical data in central systems

Summarize statistics in special systems

Run evaluations on special systems

Distribution of Inventory Controlling, SingleDocuments



SAP AG 1999 June 29, 1999

OLAP OLTP

Distribution of Purchasing Info System, SingleDocuments



SAP AG 1999 June 29, 1999

OLAP OLTP

Distribution of Sales Info System, Single Documents



SAP AG 1999 June 29, 1999

OLAP OLTP



Contents



SAP AG 1999 June 29, 1999



SD-MM link






Distribution of Purchase Contracts



SAP AG 1999 June 29, 1999

Available since 3.0A (via messages)

Depending on the document type, an additional message type is

determined that has transmission medium ALE

The function module IDOC_OUTPUT_BLAORD is called using the

transaction code

Direct sending since 4.5A

Sending via change pointer since 4.5A




SAP AG 1999 June 29, 1999

Direct sending since 4.5A

ALE: Administration of master data distribution -> Logistics ->

Send contracts

RBDSECON program selects the purchasing documents

Function module MASTERIDOC_CREATE_REQ_BLAORD

generates the IDoc

The IDoc data can be adjusted using the enhancement MM06E001and the appropriate Exit




SAP AG 1999 June 29, 1999

Sending via the change pointer since 4.5A

ALE: Administration of the distribution -> Periodic work->

Evaluate change pointer.

Function module MASTERIDOC_CREATE_SMD_BLAORD

analyzes the change pointer and generates the IDoc

The message type and function module are linked via table

TBDME (TA BD60)

ALE: Development -> Master data -> Additional data on the

message type

The generation of the change pointer must be activated in the

document type in the central system

ALE Customizing, Outbound Processing CentralSystem

L i l



SAP AG 1999 June 29, 1999

Logical message type:

BLAORD

BLAOCH (only with distribution via messages, not relevant for

new installations after 4.5A)

Activation of the change pointers

Generally or for each message type




N t i t d t i di t ib t d



SAP AG 1999 June 29, 1999

No account assignment data is distributed

The following item categories are supported:

Normal

Material unknown

Material group

Service Violations of the target quantity can only be checked in the

central system.

Contents



SAP AG 1999 June 29, 1999



SD-MM link




Contents, Further Business Processes

Local credit limit check



SAP AG 1999 June 29, 1999

SOP program planning

Cross-system planning situation

WMS as a component

Generic vendor interface

R/2-R/3 link in shipping

Certified scenarios:

•Transport planning

•Warehouse management MM-MOB, WM-LSR

•PP-POI interface / DP/DRP interface

Local Credit Limit Check

after Rel.



SAP AG 1999 June 29, 1999

•The credit status of all customers can be distributed periodically to the local

sales and distribution systems as a so-called credit vector and used in the

credit limit check instead of the local FI data.

•Restriction: open sales order, vendor, and billing document values between the

sales and distribution systems cannot be distributed. This results in certain

restrictions (see notes for this slide)

•BAPIs also exist for a closely-linked solution in which credit information is

read synchronously if the local values are outdated.

4.0a

HEADQUARTERS

SALES AND DISTRIBUTION

Credi t status

S&DS&D





SAP AG 1999 June 29, 1999



WMS as a component







SOP Program Planning (Sales Operation Planning)



SAP AG 1999 June 29, 1999

Local SOP

Central SOP

PRODUCTION

HEADQUARTERS

S&D

Central and local units can plan independently;

display all plans, change own plans only Cross-system reporting is performed via a

synchronous connection

Product ion p lans

Report ing product ion planSales forecasts





SAP AG 1999 June 29, 1999



WMS as a component





•Warehouse administration MM-MOB, WM-LSR


Cross-System Planning Situation



SAP AG 1999 June 29, 1999

You can use this business process if you have maintained a material in several systems (in other words across several

clients) and if you want to perform a cross-system evaluation of the plans for this material.

The evaluation shows the planning situation based on the data in the current stock/requirements list.

You can only process an MRP element in the system that contains the original element. It cannot be processed directly from

the planning situation.

If necessary, the business process can be used in conjunction with distributed sales and operations planning (SOP) in the

company.



SAP AG 1999 June 29, 1999



WMS as a component







WMS as a Component



SAP AG 1999 June 29, 1999

WMS as a Component



SAP AG 1999 June 29, 1999

WMS as a Component

Goods receipt for the purchase order:



SAP AG 1999 June 29, 1999

Create purchase order in the ERP system

Generate deliveries (automatically/manually) Distribute delivery from the ERP to the WM system using the BAPI

method „InboundDelivery.SaveReplica‟ (this process runs

automatically in the background).

Accept goods physically in the warehouse (WMS)

Generate transfer order

Put away goods

Confirm transfer order

Post goods receipt for the delivery (this allows confirmation to be

sent to the ERP system using the BAPI method

„InboundDelivery.ConfirmDecentral‟)

Goods receipts for delivery in the ERP system (posting in

inventory management) are automatically posted when the

confirmation is imported

WMS as a Component

Stock transfer:

E t d t



SAP AG 1999 June 29, 1999

Enter goods movement

Automatic creation of the delivery

Distribute delivery from the ERP to the WM system using the BAPI method

„InboundDelivery.SaveReplica‟ (This process runs automatically in the

background).

Goods accepted physically or goods issue in the warehouse (WMS)

Generate transport request

Put away or pick goods

Confirm transfer order

Post goods receipt for the delivery (this allows confirmation to be sent to the

ERP system using the BAPI method „InboundDelivery.ConfirmDecentral‟) or

post goods issue for outbound delivery (the confirmation is sent to the ERP

system in this way, using the BAPI method

„OutboundDelivery.ConfirmDecentral‟)

Goods receipts for the inbound delivery or goods issue for outbounddelivery in the ERP system (posting in inventory management) are posted

automatically when the confirmation is imported. The stock transfer posting

in inventory management takes place at the same time as the posting in the

ERP system.



SAP AG 1999 June 29, 1999



WMS as a component







Generic Vendor Interface, IDoc DELVRY01



SAP AG 1999 June 29, 1999

Sending of a shipping notification (DESADV, outbound EDI)

Notification of the carrier (CARNOT, outbound EDI)

Dispatch order to the a warehouse (SHPORD, outbound EDI)

Dispatch confirmation from the service provider (SHPCON, inbound

EDI)

Warehouse order to the internal warehouse (WHSORD, outbound ALE)

Warehouse confirmation from the internal warehouse (WHSCON,

inbound ALE)

Generic IDoc is DELVRY01, available as of 4.0

Generic Vendor Interface, IDoc DELVRY01



SAP AG 1999 June 29, 1999



R/2-R/3 Link in Shipping



SAP AG 1999 June 29, 1999

Purpose

All of the shipping functions are also available to you if you are using an independent R/3 shipping module in combination with an R/2 System.

The data is transferred automatically between the R/2 System, in which sales processing and the billing takes place, and the local R/3 shipping module.

The R/2-R/3 link can also be useful, without the other sales processing functions, in the following situations:

A selling company works together with a delivering company, both have, however, their own systems.

Different software products are combined on different hardware platforms.



Transport Optimization, Process, Integrating the Interfacein the Process



SAP AG 1999 June 29, 1999



Warehouse Management, MM-MOB, WM-LSR



SAP AG 1999 June 29, 1999

Warehouse

management

PRODUCTIONExternal system

External system

Warehouse control

Mobile data entry

HEADQUARTERS

S&D

Interfaces in WM, SD (packing, picking) and IM (goods

movements)



Warehouse Management, WM-LSR, Scenarios

Th i d ib d i d t il i th li



SAP AG 1999 June 29, 1999

These scenarios are described in detail in the online

documentation

Fully automatic warehouse

Fully automatic warehouse - blackbox

Interface to an external WM system

WM interface to non-warehouse systems






SAP AG 1999 June 29, 1999



WMS as a component







Productions Optimization Interface (POI)



SAP AG 1999 June 29, 1999

PP

PRODUCTION

External system Optimizing of planned orders

and production orders

Overview

The POI interface



SAP AG 1999 June 29, 1999

Is an open interface that has been part of the standard system

since R/3 Release 3.1G

Enables the user to use external optimization programs etc. for

production planning

Enables master and movement data to be transferred from an

R/3 System to an external system (download)

Planned changes can be transferred from an external system to

the R/3 System (upload)

External programs can be certified for the interface

DP/DRP Interface

Deployment interface, process



SAP AG 1999 June 29, 1999

Overview, Deployment



SAP AG 1999 June 29, 1999

On the basis of the current production plan, sales orders,

stocks, and the quota arrangement information from R/3, theexternal system determines the transports for supplying the

distribution centers, taking the transport optimization aspects

into account. Additional information from the material master,

e.g. local master data from R/3, can also be transferred to the

external system if necessary.

This results in stock transfer purchase orders that can be

generated, changed, or deleted in R/3.

The interface is a certifiable interface that enables customers to

use those external systems that best suit their processes and

requirements.

DP/DRP Interface

Distribution Planning Interface, Process



SAP AG 1999 June 29, 1999

Overview, DRP (Distribution Resource Planning)

On the basis of planned inward movements (purchase orders,



p (p ,

production orders), sales orders, stocks, and the quota arrangement

information from R/3, the external system determinesPlanned figures for SOP, which can be processed further in R/3.

Stock transfer purchase orders or stock transfer purchase

requisitions that can be generated, changed, and deleted in R/3. R/3

can provide the external system with the master data it requires.

This interface is a certifiable interface that enables customers to usethose external systems that best suit their processes and

requirements.