Uwe Schweig

1
ALE Business Processes in Logistics
Uwe Schweig Business Framework Support
2
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
3
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

4
Example of an ALE Business Process
Exchange of messages
Headquarters
BLAORD, BLAOCH

• Accounting
• Central purchasing
• Purchasing Information System

BLAREL
EKSEKS
FIDCMT
FIROLL
BLAOR Contract/change BLAOCH Change BLAREL Releas
e order statistics EKSEKS Purchasing Information
System FIDCMT FI document FIROLL FI rollup
PRODUCTION

• Local purchasing
• Invoice verification

5
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 integrated
  system configurations

6
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
7
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
8
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).

9
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
  started manually or scheduled periodically,
  selects the change pointers and generates the
  summarized IDocs.

10
SMD Tool for Distributing Master Data
Application
Engineering change management
ALE layer
Standard ALE outbound processing
ALE relevant?
Batch job / manual
Change documents
Change pointers
11
Controlling / Influencing the Distribution
Procedure

• Data filtering in the distribution model
• Segment filtering
• Reducing IDocs
• Taking dependencies between master data objects
  into consideration

12
Data Filtering

• 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

General data
Short text
Filter at plant level
Plant
Warehouse/batches
Product group
Material valuation
...
13
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 ORing of filter groups)

14
Segment Filtering / Field Conversion

• IDoc segments that are not required are filtered
  out from the ALE 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 using conversion rules.

15
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 (ltgt
  filtering), no modifications to the standard
  system required

16
Reducing IDocs
Initial screen When it is generated, the new
message type is linked to the structure of the
reference message Structure description Activatio
n of the segments of the message type Field
list Fields that are to be sent must be activated
in the active segments
Maintain reduction Access View (message
type) ________ Derived from ________ Short
text ________
Structure description MATMAS03 Material master
E1MARAM General data E1MAKTM
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 ...
17
Taking Dependencies Between Master Data Objects
into Account Serialization, Dependent Objects

• Serialization of message typesSome 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.

18
Taking Dependencies Between Master Data Objects
into Account 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.

19
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

20
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)

21
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
22
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)

23
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

24
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 so on).
• 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 ..).

25
Material Master Distribution (1)
1 Central maintenance and reference system,
supplement in local maintenance systems with
operative business
Maintenance of the material characteristics that
are identical throughout the company (e.g. view
K) (maintenance and reference system Z)
Z
A..Z
B1
B2
Branch 1 (Sub-range of all articles, B1)
Branch 2 (Sub-range of all articles, B2)
A,D,..
B,C,E,..
B, C
Local maintenance of the views that are
significant locallydata is only available or is
instantiated locally (Views A, G, V, F ., for
example )


26
Material Master Distribution (2)
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
Maintenance system for articles C,D
C, D
Maintenance system for articles A,B
A, B
Reference system (without active maintenance or
with restricted maintenance)
Selective distribution in the productive
branches (according to articles A,B,C,D and
views)
A, B, C, D
Productive branches
27
Material Master Distribution (3)
Several maintenance systems in production
operation. 1 reference system for coordination
28
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

29
Performance Aspects

• Direct sending
• Remote logon for every IDoc Impairs
  performance!!
• Problems with selecting and sending (Report
  RSEOUT00)
• If the IDocs to be sent have been restricted
  incorrectly
• If the number of IDocs sent per LUW is too large
• Cascading of the occupied processes caused by too
  many RFCs(per selected IDoc packet)
• Problems with inbound processing (Report
  RBDAPP01)
• Parallel posting can overload the work processes
  and disrupt online operation
• Deadlock danger one free work process is always
  required to assign numbers in the
  application!!!(design problem)

30
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
31
Material Master

• Material Master

32
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

33
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

34
ALE Customizing

• 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

35
Distribution Restrictions

• 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)

36
How are Material Masters Distributed Effectively?

• 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?

37
Customer Master

• Customer Master

38
What is a Customer Master?

• 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

39
Distribution of Customer Masters

• Available since 3.0A
• Direct sending
• Sending via change pointers
• Reduction possible
• Listing possible
• Dependencies conditions, banks, G/L accounts
  (reconciliation account)

40
ALE Customizing

• Message types DEBMAS
• IDoc types DEBMAS03
• Filters in the distribution model,
• Company code, debtor, credit control area,
  division, sales organization, distribution
  channel
• General ALE Customizing
• Listings (3.0x)
• Serialization group no specific group predefined

41
Distribution Restrictions

• Not distributed/supported
• Addresses of contacts are not distributed
• Long texts are not attached to the change
  documents

42
How are Debtors Distributed Effectively?

• How is the customer handled in the company?
• Always in the same way or in different ways
  (creditworthiness, assignment to sales areas,...,
  )
• How are company codes and sales areas
  organized?
• How are incoming payments made by the debtor
  processed(centrally or decentrally, same payer,
  dunning, ..).
• Where is information on the individual views of
  the debtor stored in the company?
• Central locations or different locations for
  different information

43
Vendor Master

• Vendor Master

44
What is a Vendor Master?

• 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

45
Distribution of Vendor Masters

• Available since 3.0A
• Direct sending
• Sending via change pointers
• Reduction possible
• Listing possible
• Dependencies conditions, banks, G/L accounts
  (reconciliation accounts etc.).

46
ALE Customizing

• Message types CREMAS
• IDoc types CREMAS02
• Filters in the distribution model,
• Company code, purchasing organization, creditor
  
• General ALE Customizing
• Listings (3.0x)
• Serialization group no specific group delivered

47
Distribution Restrictions

• Not distributed/supported
• Dunning data is only posted to the default
  dunning area with inbound processing of vendor
  master data

48
How are Creditors Distributed Effectively?

• 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?

49
Purchasing Info Records

• Purchasing Info Records

50
What is a Purchasing Info Record?

• Information source for purchasing
• Data on a particular material and material vendor
  (quotation and purchase order data)
• General data
• Organizational data (POrg., plant)
• Texts
• The data in the info record is also used as
  default data for purchase orders

51
Types of Info Records

• Info record with material master (stock material,
  for example)
• Info record without material master record
  (consumable material, for example)
• Subcontracting purchasing info record
• Pipeline info record

52
Distribution of Purchasing Info Records

• Available since 3.1G
• Direct sending
• Sending via change pointers
• Reduction possible
• Dependencies material, vendor, (conditions)

53
ALE Customizing

• Message type INFREC
• Filters in the distribution model
• Material, plant, vendor, purchasing organization,
  listing
• Dependent message type
• General ALE Customizing
• Listings (3.1x)
• Serialization group (after 4.0A)
• Material
• Vendor
• Purchasing info record

54
Application Customizing

• Coordination of the number ranges
• IMG Materials Management -gt Purchasing -gt
  Purchasing Info Record -gtDefine Number Ranges

55
Distribution Restrictions

• 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 plant field for cross-plant info
  records or the material field for non-stock
  materials must be assigned SPACE.

56
Source List

• Source List

57
What is a Source List?

• 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

58
Utilization of the Source List

• 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

59
Distribution of the Source List

• Available since 3.1G
• Direct sending
• Sending via change pointer
• No reduction
• Dependency material, vendor, (contracts)

60
ALE Customizing

• Message type SRCLST
• Filters in the distribution model
• Material, plant, vendor, purchasing organization,
  listing
• Dependent message type (4.0A)
• General ALE Customizing
• Listings (3.1x)
• Serialization group (as of 4.0A)
• Material
• Vendor
• Source list

61
Application Customizing

• Source list requirement (plant-related)
• IMG Materials Management -gt Purchasing -gt
  Source List -gt Define Source List Requirement
  at Plant Level
• Source list requirement (material-related)
• Material master record -gt Purchasing view -gt
  Source list requirement

62
Distribution Restrictions

• 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.

63
Conditions

• Conditions

64
Introduction What is Implemented?

• Outbound processing
• Automatic selection and distribution on the basis
  of change documents from price and condition
  maintenance
• Manual selection and distribution without change
  documents
• IDoc modification option via customer functions

65
Introduction What is Implemented?

• 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

66
IDoc and Condition Technique Conditions in R/3

• Overview
• Example the usage A Pricing the
  application V Sales and distribution

T683
T682
T685
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 x 20 006 Price
list/mat 0 x 30 006 Price list/mat 3 x 40 004 Mate
rial 0 x 50 029 Material group 0 x ...
... PR00 - Price PR01 - Price incl. VAT RA01 -
disc. from gross RB00 - Absolute discount SKTO -
Cash discount ...
Condition type
Calculation scheme
Access sequence
Konm
A999
Konp
Konh
A001
A005
Application x Condition type x Variable key
x Date until x Link (knumh)
Konw
Condition records
Condition tables
67
IDoc and Condition Technique IDoc Structure

• E1KOMG For filter functions (1required)
• E1KONH Condition header (nrequired)
• E1KONP Condition position (mrequired)
• E1KONM Quantity scale (ioptional)
• E1KONW Value scale (joptional)
• E1KONH
• E1KONP Condition position (mrequired)
• And so on.

68
IDoc and Condition Technique Concepts

• 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 dataEntire IDoc
  segments can be excluded from the transfer

69
IDoc and Condition Technique Implementation of
Outbound Processing

• Manual selection and distribution
• For each condition type by displaying condition
  records (condition info) 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...

70
IDoc and Condition Technique Outbound Processing
71
IDoc and Condition Technique Outbound Processing
72
IDoc and Condition Technique Outbound Processing

• Automatic selection and distribution
• Processing of the change documents COND_A from
  condition and 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...

73
IDoc and Condition Technique Special Features
Outbound Processing

• 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, retail promotion 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

74
IDoc and Condition Technique Special Features
Outbound Processing

• Error handling
• What the standard transaction BALE has to offer
• Generated documents with their processing status
• IDoc segments with the data to be sent
• Manual sending success or failure messages
• Automatic sending
• Only formally consistent conditions are
  transferred the change pointer is set to
  processed
• The status of the change pointer only remains
  unchanged with system-specific errors

75
IDoc and Condition Technique Special Features
Outbound Processing

• 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 gt todays date. These validity periods
  are sent.(Consistency between source and target
  system)

76
IDoc and Condition Technique Special Features
Inbound Processing

• 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 are lost
• 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 gt todays date are sent for
  each condition record number (consistency).

77
Customizing Prerequisites

• 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

78
Customizing Prerequisites

• 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 inbound processing, an error message
  is output

79
Modification / Customer Enhancements Other

• Reduction of segments
• The segments for the value or quantity scales can
  be excluded from 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.

80
Serialization IDoc Logical Unit

• 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.

81
BOMs

• BOMs

82
Distribution of BOMs

• Available since 3.1G
• Direct sending
• Sending via change pointer
• No reduction provided
• Dependency material, documents, classes

83
ALE Customizing

• Message type BOMMAT
• Filters in the distribution model
• BOM usage, BOM status, plant
• General ALE Customizing
• No classification for BOMs -gt no ALE listing
• No serialization group in the standard system

84
Distribution Restrictions

• The distribution of BOMs does not include
• Long texts for header, alternative, item
• Sub-items
• Global object dependencies. This must be
  available in the target system.
• The history of the BOM. The status of the BOM is
  distributed according to the key days.
• The item objects of the BOM, for example,
  materials, documents, classes. These must be
  distributed separately before the BOM.
• The change number (if specified). This must be
  available in the target system (message ECMMAS01
  as of 4.0).
• Batch classification of the BOM items
• Multiple and variant BOMs

85
Customer Enhancements - BOMs

• Outbound processing not planned
• Inbound processing not planned

86
Further Master Data Objects

• Details of further objects can then be taken from
  the Interface Advisor.
• Listing of further objects
• Article master ARTMAS / ARTMAS02
• Additionals MMADDI / MMADDI01
• Assortment ASSORTMENT / ASSORTMENT01
• Listing conditions LIKOND / LIKOND01
• Price list PRICAT / PRICAT01
• Product catalog PRDCAT / BPRDCAT01, PRDPOS /
  PRDPOS01
• Document DOCMAS / DOCMAS04
• Change master ECMMAS / ECMMAS01
• Project structure plan PROJECT / PROJECT01
• Document BOM DOC / BOMDOC01
• Characteristic, class CHRMAS / CHRMAS02, CLSMAS /
  CLSMAS03
• Classification CLFMAS / CLFMAS01

87
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
88
Contents, SD-MM Link
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)
89
Scenario Stock Transfer Between Distributed
Systems
System of the ordering plant
System of the supplying plant
Requirement, planned order, purchase requisition
ORDERS
Purchase order
Sales order
ORDCHG
Purchase order change
Order change
ORDRSP
Confirmation
ORDRSP
Confirm sales order
Shipping notification
Delivery
DESADV
Incoming invoice
Billing document
INVOIC
Goods receipt
Goods issue
Physical stock transfer
90
Process Description

• This scenario is based on purchase orders that
  are created in the system of the ordering plant.
  The purchase orders are sent to the system of the
  supplying plant via the logical message type
  ORDERS. Here, a sales order is created in the
  inbound processing of the IDoc. The sold-to party
  is determined in outbound processing from the
  vendor master. (correspondence view, account
  with vendor field). The sales area can be
  specified in the IDoc or determined via the EDSDC
  table. (SP VD -gt Sales area) The order type can
  be set in a CUSTOMER EXIT. If nothing is
  specified in the IDoc, the default TA is used.
• The sales order generated in the delivery system
  sends an order confirmation via the logical
  message type ORDRSP. This is stored as an order
  confirmation in the purchase order system.
• If a shipping notification is sent via the
  logical message type DESADV when the sales order
  is delivered, a notification for the purchase
  order can be generated in the ordering system.
• The billing for the sales order is sent via the
  logical message type INVOIC. The inbound
  processing in the ordering system generates an
  incoming invoice for the purchase order.
• The scenario does not have an interface for
  mapping the goods movement.

91
ALE Customizing

• 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-gtSales and Distribution-gtElectronic
  Data Interchange-gtEDI Messages
• Perform consistency checks Check technical
  consistency / RBDMMSD1 - Check application
  consistency /
• 
  Check control data consistency

92
Application Customizing

• 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-gtMaterials
  Management-gtInvoice Verification-gtEDI

93
Master Data

• 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)
• - Message condition records

94
USER EXITS in Outbound Processing

• CUSTOMER FUNCTIONS
• ORDCHG - Purchase order change MM06E001
• ORDERS - Purchase order
  MM06E001
• ORDRSP - Order confirmation
  SDEDI001
• INVOIC - Billing
  LVEDF001
• FORM routines
• DESADV - Shipping notification
  LVED2FZZ

95
USER EXITS in Inbound Processing

• 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)

96
Example of Using a CUSTOMER FUNCTION in Inbound
Processing

• 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

97
Contents, SD-MM Link
SD-MM link - Stock transfer between distributed
systems - Separate Sales and Shipping
Scenario - Assigned standard purchase order -
External procurement - Usage of MM-SD scheduling
agreements - VMI (Vendor Managed Inventory)
98
Scenario Decentral Sales, Central Shipping,
Assigned standard purchase order
99
Process Description

• 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.

100
External Procurement, Without ALE Scenario
MM
SD / MM
SD
Vendor
Third-party vendor
Customer
Sales order
Purchase order
PReq
Third-party purchase order
Sales order
Delivery to customer
GR
Goods issue
101
Automatization of External Procurement for ALE
MM
SD / MM
SD
Vendor
Third-party vendor
Customer
Sales order
Purchase order
PReq
WF event TRFC
ALE / IDoc
Third-partypurchase order
Sales order
102
Scenario Local Sales, Central Shipping,
External Procurement
MM
SD / MM
SD
EDI message
Decentral sales
Central shipping
Customer
Purchaseorder
Sales order
PReq
Create /change
ORDERS
Third-partypurchase order
Sales order
Confirmation
Status, Confirmation
ORDCHG
Order change
Purchase order change
ORDRSP
Billing
Confirmation
ORDRSP
Confirm sales order
Shipping notification
Delivery to customer
DESADV
GR
Incoming invoice
Billing of internal allocation
INVOIC
St-GR, FI doc.
Goods issue
Billing, sales order
103
Process Description

• This scenario is based on a sales order.
  Customizing at the schedule line level is defined
  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 additional status 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 sent to 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,
  billing cannot 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.

104
ALE Customizing

• 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 order
• Settings IMG-gtSales and Distribution-gtElectronic
  Data Interchange-gtEDI Messages
• Perform consistency checks Check technical
  consistency / RBSDMM1 - Check application
  consistency /
• 
  Check control data consistency

105
Application Customizing (1)

• Set message control for the following message
  types
• Local sales
• NEW - Outbound purchase order and purchase order
  change
• Central shipping
• BA00- Outbound order confirmation
• LALE - Outbound shipping notification
• RD00 - Outbound billing document
• 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 called up via IMG-gtMaterials
  Management-gtInvoice Verification-gtEDI

106
Application Customizing (2)

• 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.

107
Master Data

• In local sales
• - Vendor master (represents central shipping)
• - Purchasing info record (alternatively -
  customer/material/info record)
• - Message condition records
• In central shipping
• - Customer master (represents local sales)
• - Customer/material/info record
  (alternatively - purchasing info records)
• - Message condition records

108
USER EXITS in Outbound Processing

• CUSTOMER FUNCTIONS
• ORDCHG - Purchase order change MM06E001
• ORDERS - Purchase order MM06E001
• ORDRSP - Order confirmation SDEDI001
• INVOIC - Billing document
  LVEDF001
• Order creation (several vendors allowed per
  material) SDALE001
• FORM routines
• DESADV - Shipping notification
  LVED2FZZ

109
USER EXITS in Inbound Processing

• 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 compatability)
• ORDCHG - Sales order change LVEDBF0U
  (for reasons of compatability)

110
Weaknesses of the Stock Transfers and Separate
Sales and Shipping Scenarios

• 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.

111
Contents, SD-MM Link
SD-MM link - Stock transfer between distributed
systems - Separate Sales and Shipping
Scenario - Assigned standard purchase order -
External procurement - Usage of MM-SD scheduling
agreements - VMI (Vendor Managed Inventory)
112
Alternative Processing of Stock Transfers Via
Scheduling Agreements
MM scheduling agreement
SD scheduling agreement
Forecast delivery schedule
MRP
Delivery
GI
Shipping notification
GR
Inventory posting
Incoming invoice
Billing document
1
1 , 2
Invoice
1
Credit memo display
2
Accounting document
2
Payment run
2
Payment notification
2
2
Payment notification
3
3
Clearing account
Clearing account
Clearing
3
113
Contents, SD-MM Link
SD-MM link - Stock transfer between distributed
systems - Separate Sales and Shipping
Scenario - Assigned standard purchase order -
External procurement - Usage of MM-SD scheduling
agreements - VMI (Vendor Managed Inventory)
114
Application Example VMI (Vendor Managed Inventory)
Customer system
Vendor system
Update statistics, send sales data
Import sales figures
PROACT
Generate purchase order
ORDRSP
Check purchase order Release purchase order
Processing of these tasks, including error
handling, viaWorkflow
Confirm generated purchase order Sending
purchase order change messages to the vendor
ORDCHG
Process ORDCHG
115
Process Description

• 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 to receive 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 the
  purchase order number from the customer system.

116
Contents
The ALE business process concept Distribution of
master data in Logistics SD-MM link Distribution
of the Logistics Info Systems Distributed
purchase contracts Overview of further business
processes
117
Data Warehouse Concepts
OLAP
OnlineAnalyticalProcessing
Analysis tools
DATAWARE-HOUSE
Summarized information
OnlineTransactionProcessing
OLTP
Integrated application modules
118
Logistics Data Warehouse