1 / 168

Contents

ALE Business Processes. An ALE business process is an integrated, cross-system business processALE business processes run between:Several R/3 SystemsLogistics, Financial Accounting and HR on separate systems, for exampleR/3 and non-R/3 systemsWarehouse Management in R/3, external warehouse con

dorit
Download Presentation

Contents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    2. Contents

    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

    5. In other words, ALE is….

    6. Contents

    7. Contents, Master Data

    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

    11. Controlling / Influencing the Distribution Procedure

    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

    13. Logical Combination of Filters

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

    16. Reducing IDocs

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

    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

    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) The objective of many companies nowadays is to standardize the number structures that have evolved from the complex distributed system environment of the past. In this respect, ALE constitutes a strategic tool for achieving this objective, even if extensive ALE scenarios are not intended to be used (only master data distribution). It is often impossible to create company-wide evaluations on the sales volume with a particular vendor or to call up an overview of the stocks available globally or consumption of a particular article. Standardization of master data is a prerequisite for the transparency of business ALE scenarios. In general, the ALE scenarios can also be used with non-standard object numbers. In this case, however, extensive, complex conversion rules or data conversions are required if the distributed applications are to communicate. The objective of many companies nowadays is to standardize the number structures that have evolved from the complex distributed system environment of the past.In this respect, ALE constitutes a strategic tool for achieving this objective, even if extensive ALE scenarios are not intended to be used (only master data distribution).It is often impossible to create company-wide evaluations on the sales volume with a particular vendor or to call up an overview of the stocks available globally or consumption of a particular article. Standardization of master data is a prerequisite for the transparency of business ALE scenarios. In general, the ALE scenarios can also be used with non-standard object numbers. In this case, however, extensive, complex conversion rules or data conversions are required if the distributed applications are to communicate.

    23. Distributable Master Data Objects in Logistics Materials Debtors Creditors Purchasing info records Source lists Conditions BOMs

    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 ..). Customizing that is coordinated and uniform throughout the company is a prerequisite not only for master data distribution!!! The management and the projects/subprojects must be ‘sensitized’ accordingly at a very early stage. Before the distribution processes can be planned in detail, the organizational units must be defined throughout the company (controlling areas, operating concerns, company codes, plants, divisions, sales areas, purchasing organizations, ..... ) Check tables that are relevant for the distributed scenarios must be defined and configured throughout the company. The question of a central Customizing client, from which all Customizing settings are distributed, must be discussed and clarified at an early stage. For ‘political’ and organizational reasons, it is usually impossible to prevent Customizing changes in the local systems. Alternatively, you must clarify which Customizing settings may be performed centrally and which settings are still to be defined locally. (ALE distribution model CONTRLDATA for Customizing settings) Customizing that is coordinated and uniform throughout the company is a prerequisite not only for master data distribution!!! The management and the projects/subprojects must be ‘sensitized’ accordingly at a very early stage. Before the distribution processes can be planned in detail, the organizational units must be defined throughout the company (controlling areas, operating concerns, company codes, plants, divisions, sales areas, purchasing organizations, ..... ) Check tables that are relevant for the distributed scenarios must be defined and configured throughout the company. The question of a central Customizing client, from which all Customizing settings are distributed, must be discussed and clarified at an early stage.For ‘political’ and organizational reasons, it is usually impossible to prevent Customizing changes in the local systems. Alternatively, you must clarify which Customizing settings may be performed centrally and which settings are still to be defined locally. (ALE distribution model CONTRLDATA for Customizing settings)

    25. Material Master Distribution (1) All articles of the company are created and maintained at a central point (Z). From here, partial quantities are then dispatched to the local branches (B1, B2) (new quantities and changes). Provided that all of the data is available, all of the article characteristics can be entered in the central maintenance system with the result that no further material master maintenance is necessary / permitted in the local systems. Alternatively, you can create or supplement the views locally in line with the requirements concerned. These characteristics are then only active locally and are not distributed further. Advantage: simple, transparent scenario. Problem: certain items of data / views of a master record are always created and maintained in the central system (Z). This means that employees also have to log onto this central system, even if they are otherwise in charge of applications of a specific branch (problem of using / logging onto several systems) . Alternative: organizational approval procedure for creating or maintaining an article in the head office if the article is required locally. (Example: a new article is to be included locally in the order program or delivery catalog) . All articles of the company are created and maintained at a central point (Z). From here, partial quantities are then dispatched to the local branches (B1, B2) (new quantities and changes). Provided that all of the data is available, all of the article characteristics can be entered in the central maintenance system with the result that no further material master maintenance is necessary / permitted in the local systems.

    26. Material Master Distribution (2) Depending on the material characteristic (material type, division, material group, class, and so on) several maintenance systems exist (external CAD systems for material development or SAP systems with a direct link to these external systems, for example). Material numbers are assigned here. The articles are sent to the reference system, usually only with design data, and are supplemented if necessary. Alternatively, further views can of course be added in the maintenance systems. The articles are distributed to the partner systems selectively (from the reference system) (according to article numbers and views) where they are supplemented if necessary. Depending on the material characteristic (material type, division, material group, class, and so on) several maintenance systems exist (external CAD systems for material development or SAP systems with a direct link to these external systems, for example). Material numbers are assigned here. The articles are sent to the reference system, usually only with design data, and are supplemented if necessary.Alternatively, further views can of course be added in the maintenance systems. The articles are distributed to the partner systems selectively (from the reference system) (according to article numbers and views) where they are supplemented if necessary.

    27. Material Master Distribution (3) There are several maintenance systems (P1, P2) for developing, creating, and maintaining design data. Each maintenance system is responsible for a particular product range. Logistics applications are also productive in each maintenance system (P1, P2). The data is sent to a reference system R. From here, it is distributed across the entire company (also to branch P3, for example). Problem: preventing the data originating from P1 from being sent back to P1 by the reference system (‘ping-pong’), for example. Very complex procedure There are several maintenance systems (P1, P2) for developing, creating, and maintaining design data. Each maintenance system is responsible for a particular product range. Logistics applications are also productive in each maintenance system (P1, P2). The data is sent to a reference system R. From here, it is distributed across the entire company (also to branch P3, for example). Problem: preventing the data originating from P1 from being sent back to P1 by the reference system (‘ping-pong’), for example. Very complex procedure

    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

    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? The way in which the company structure is mapped using the organizational terms in SAP has a significant influence on the structure and distribution logic of the master data. The maintenance views of the material master are assigned to appropriate organizational structures, for example: Plant, warehouse, Sales area (sales organization / distribution channel) Valuation area (company code / plant). Depending on the recipient partners, different (reduced) message types can be used. This means that the partners can be supplied with various views and characteristics of the material. The way in which the company structure is mapped using the organizational terms in SAP has a significant influence on the structure and distribution logic of the master data. The maintenance views of the material master are assigned to appropriate organizational structures, for example: Plant, warehouse, Sales area (sales organization / distribution channel) Valuation area (company code / plant). Depending on the recipient partners, different (reduced) message types can be used. This means that the partners can be supplied with various views and characteristics of the material.

    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 -> Purchasing -> Purchasing Info Record ->Define 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 -> Purchasing -> Source List -> Define Source List Requirement at Plant Level Source list requirement (material-related): Material master record -> Purchasing view -> 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 Manually: possible for each condition type from price and condition maintenance (condition info)Manually: possible for each condition type from price and condition maintenance (condition info)

    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 Details on the conditions that are assigned to info records or contracts can be found under ‘distribution scenarios’. Conditions for agreements (KONA reference) generally cannot be distributed, as this can result in statistics problems with condition record numbers. Free goods is another use of the condition technique and, therefore, cannot be processed here. Details on all points --> laterDetails on the conditions that are assigned to info records or contracts can be found under ‘distribution scenarios’. Conditions for agreements (KONA reference) generally cannot be distributed, as this can result in statistics problems with condition record numbers. Free goods is another use of the condition technique and, therefore, cannot be processed here. Details on all points --> later

    66. IDoc and Condition Technique: Conditions in R/3 Overview Example: the usage A = Pricing the application V = Sales and distribution Condition type: determines the type of condition; price, markup, markdown in value or percentage, scaling yes/no ... Calculation scheme: determines the order and rules with which the condition types will be used for price determination. Access sequence: is stored with the condition type and determines the order in which the condition tables are to be searched for valid entries. Generally, it is assumed that a special search (here, customer+material) is followed by a general search (material group). Condition table: represents the validity periods of the individual condition records. A unique condition record number (knumh) provides the link to the condition records. Condition records: Konh: Condition header Konp: Condition item(s), possibly with additional conditions Konm/Konw: Quantity or value scale Condition type: determines the type of condition; price, markup, markdown in value or percentage, scaling yes/no ... Calculation scheme: determines the order and rules with which the condition types will be used for price determination. Access sequence: is stored with the condition type and determines the order in which the condition tables are to be searched for valid entries. Generally, it is assumed that a special search (here, customer+material) is followed by a general search (material group). Condition table: represents the validity periods of the individual condition records. A unique condition record number (knumh) provides the link to the condition records. Condition records: Konh: Condition header Konp: Condition item(s), possibly with additional conditions Konm/Konw: Quantity or value scale

    67. IDoc and Condition Technique: IDoc Structure E1KOMG For filter functions (1:required) E1KONH Condition header (n:required) E1KONP Condition position (m:required) E1KONM Quantity scale (i:optional) E1KONW Value scale (j:optional) E1KONH E1KONP Condition position (m:required) And so on. An IDoc combines all condition records that fulfil specific criteria (see Serialization) Application + Condition type + Condition table + VAKEY The Konh blocks are the individual validity periods within the logical unit (see Serialization)An IDoc combines all condition records that fulfil specific criteria (see Serialization) Application + Condition type + Condition table + VAKEY The Konh blocks are the individual validity periods within the logical unit (see Serialization)

    68. IDoc and Condition Technique: Concepts Concepts IDoc type: COND_A01 Determines 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 Customers can create reduction message types. These must refer to the IDoc type Cond_A01. Reduction capability is provided at the segment and field levels Further details under ‘Modification’/customer enhancement Customers can create reduction message types. These must refer to the IDoc type Cond_A01. Reduction capability is provided at the segment and field levels Further details under ‘Modification’/customer enhancement

    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... In the price and condition maintenance facility, you can generally call up the condition information for a condition type. You can use this to display all condition records available in the system via a selection screen. This display can also be used to send conditions manually.In the price and condition maintenance facility, you can generally call up the condition information for a condition type. You can use this to display all condition records available in the system via a selection screen.This display can also be used to send conditions manually.

    70. IDoc and Condition Technique: Outbound Processing Example - the selection screen for condition type PR00 All of the key fields in all the condition tables assigned via the access sequence can be used as selection criteria. You can restrict the criteria to a specific validity period for the conditions. If both fields remain empty, all the validity periods for the conditions are displayed.Example - the selection screen for condition type PR00 All of the key fields in all the condition tables assigned via the access sequence can be used as selection criteria. You can restrict the criteria to a specific validity period for the conditions. If both fields remain empty, all the validity periods for the conditions are displayed.

    71. IDoc and Condition Technique: Outbound Processing Condition records with several validity periods are displayed in color. When you send the checked conditions, a popup appears in which you can specify a different message type (reduced message) a logical system; if the field remains empty, the message is sent to all systems defined in the partner profile.Condition records with several validity periods are displayed in color. When you send the checked conditions, a popup appears in which you can specify a different message type (reduced message) a logical system; if the field remains empty, the message is sent to all systems defined in the partner profile.

    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... The partner profile is used to check whether a system is interested in the message. The partner profile is used to check whether a system is interested in the message.

    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 EKKO fields: if Komg-evrtn is filled EKKO fields: if Komg-kont_pack is filled (service header) as of 4.0C Significance of the VAKEY in the E1KOMG segment The key fields in a condition table often contain the actual recipient data for sending the condition. These fields are stored in encrypted form in the VAKEY of the condition header. The E1KOMG segment contains this data in unencrypted form which means that it can be used for filter and distribution functions using the standard ALE functionality. Since the E1KOMG segment must be permanently defined and cannot be extended to include customer-specific key fields (XKOMG), these fields must reach the target system via the VAKEY. For this reason, the VAKEY has also been included in the segment. The outbound procedure is as follows: The Vakey of the condition record is evaluated and copied to the appropriate fields of the KOMG structure (customer key fields may be present) Customer function for modifying the established KOMG structure. This can be enhanced for filter and distribution functions, in other words data can be entered in existing fields. Existing data contents can be converted. The fields of the KOMG structure, which may have been modified, are copied to the E1KOMG structure, if they are present in the structure. The Vakey is rebuilt from the modified KOMG structure and copied to the VAKEY and VAKEY_LONG (Rel4.0) fields of the E1KOMG structure. Continued overleafEKKO fields: if Komg-evrtn is filledEKKO fields: if Komg-kont_pack is filled (service header) as of 4.0C Significance of the VAKEY in the E1KOMG segmentThe key fields in a condition table often contain the actual recipient data for sending the condition. These fields are stored in encrypted form in the VAKEY of the condition header. The E1KOMG segment contains this data in unencrypted form which means that it can be used for filter and distribution functions using the standard ALE functionality. Since the E1KOMG segment must be permanently defined and cannot be extended to include customer-specific key fields (XKOMG), these fields must reach the target system via the VAKEY. For this reason, the VAKEY has also been included in the segment.The outbound procedure is as follows: The Vakey of the condition record is evaluated and copied to the appropriate fields of the KOMG structure (customer key fields may be present) Customer function for modifying the established KOMG structure. This can be enhanced for filter and distribution functions, in other words data can be entered in existing fields. Existing data contents can be converted. The fields of the KOMG structure, which may have been modified, are copied to the E1KOMG structure, if they are present in the structure. The Vakey is rebuilt from the modified KOMG structure and copied to the VAKEY and VAKEY_LONG (Rel4.0) fields of the E1KOMG structure. Continued overleaf

    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 Contd.: Significance of the VAKEY in the E1KOMG segment Inbound processing: The Vakey of the transferred E1KOMG structure is evaluated and copied to the appropriate fields of the KOMG structure to create the condition. Customer function for modifying the established KOMG structure. This can be used to convert existing data or to add data to existing fields that is needed in the condition table of the target system, for example. The condition is created using the contents of the KOMG structure. This procedure means that the field conversions provided by the ALE layer cannot be used for the E1KOMG segment, since the contents of the Vakey must also be converted. This, however, is not viable with the existing conversion rules (COMBINE or GROUP). As described above, these conversions must be performed via the customer functions in inbound and outbound processing. The Vakey must also be adapted accordingly. Contd.: Significance of the VAKEY in the E1KOMG segment

    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 >= today’s date. These validity periods are sent. (Consistency between source and target system) The various periods and condition records are combined and sent in an IDoc. See also Serialization ______ 1 ______ / ______ 2 __________ / __________ 3 ________________> today changed If today’s date is within the interval for condition record 1 and the second record was changed, records 1 to 3 are combined in an IDoc and sent. The various periods and condition records are combined and sent in an IDoc. See also Serialization ______ 1 ______ / ______ 2 __________ / __________ 3 ________________>

    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 >= today’s date are sent for each condition record number (consistency). Gaps in the target system Source system 1). AAAAABBBBBCCCCC 2). AAAAA BBBCCCCC reduce BBBBB 3). send BBB 4). AAAAA BBBCCCCC current status on the DB Target system 1). DDDDDKKKKKEEEEE identical to Source 2). recreate BBB 3). DDDDDKKBBBEEEEE part of KKKKK remains New condition record number Source system 1). AAAAABBBBBAAAAA AAAAA has same Knumh 2). Send completely Target system 1). DDDDDKKKKKEEEEE each with different KnumhGaps in the target system Source system 1). AAAAABBBBBCCCCC 2). AAAAA BBBCCCCC reduce BBBBB 3). send BBB 4). AAAAA BBBCCCCC current status on the DB Target system 1). DDDDDKKKKKEEEEE identical to Source 2). recreate BBB 3). DDDDDKKBBBEEEEE part ofKKKKK remains New condition record number Source system 1). AAAAABBBBBAAAAA AAAAA has same Knumh 2). Send completely Target system 1). DDDDDKKKKKEEEEE each withdifferent Knumh

    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. Serialization If two new validity periods are created in the source system and transferred to the target system in the wrong order, the results in the two systems may differ. This is not a problem, as all possible validity periods are always transferred for a condition record number and only more recent data is processed for a logical unit. Example: the following data is to be transferred: Appl KoArt KoTab VaKey knumh Value Valid M PB00 A016 R001R01 01 000005 3.50 06/01/-06/30 M PB00 A016 R001R01 01 000126 3.40 07/01/-08/20 M PB00 A016 R001R01 01 000005 3.50 08/21/-12/31 M PB00 A016 R001R02 01 000055 3.50 07/01/-12/31 2 IDocs are generated: KOMG with M+PB00+A016+R001R01 01 ........ KONH with knumh=000005 + 06/01/-06/30/ ...... KONP with data .... 3.50 ..... KONH with knumh=000126 + 07/01/-08/20/ ...... KONP with data .... 3.40 ..... KONH with knumh=000005 + 08/21/-12/31/ ...... KONP with data .... 3.50 ..... -------------------------------------------------------------------------------------------- KOMG with M+PB00+A016+R001R02 01 ........ KONH with knumh=000055 + 07/01/-12/31/ ...... KONP with data .... 3.50 ..... SerializationIf two new validity periods are created in the source system and transferred to the target system in the wrong order, the results in the two systems may differ. This is not a problem, as all possible validity periods are always transferred for a condition record number and only more recent data is processed for a logical unit. Example: the following data is to be transferred:Appl KoArt KoTab VaKey knumh Value ValidM PB00 A016 R001R01 01 000005 3.50 06/01/-06/30M PB00 A016 R001R01 01 000126 3.40 07/01/-08/20M PB00 A016 R001R01 01 000005 3.50 08/21/-12/31M PB00 A016 R001R02 01 000055 3.50 07/01/-12/31

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

    88. Contents, SD-MM Link

    89. Scenario: Stock Transfer Between Distributed Systems Menu No specific function in the menu Online help Help->SAP Library->CA(/Cross Application)->Business Framework Architecture->ALE->ALE Business Processes Library->Logistics-Logistics->Stock transfer of goods between distributed systems IMG IMG->Cross-Application Components->Predefined ALE Business Processes->Logistics->LO-LO->‘Stock Transfer Between Distributed Systems’ Scenario Menu No specific function in the menu Online help Help->SAP Library->CA(/Cross Application)->Business Framework Architecture->ALE->ALE Business Processes Library->Logistics-Logistics->Stock transfer of goods between distributed systems IMG IMG->Cross-Application Components->Predefined ALE Business Processes->Logistics->LO-LO->‘Stock Transfer Between Distributed Systems’ Scenario

    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 -> 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->Sales and Distribution->Electronic Data Interchange->EDI Messages Perform consistency checks: Check technical consistency / RBDMMSD1 - Check application consistency / Check control data consistency For converting the text IDs: Purchasing and Sales use different text IDs. If order texts are to be copied to the sales orders, a conversion must take place. This can be performed using the ALE conversion. For the purchase order (ORDERS) and the purchase order change (ORDCHG), conversions must take place at header and item level. These conversions can be carried out by generating a conversion rule for the document header (segment E1EDKT1) and the item (segment E1EDPT1). When defining this rule, use TDID for the recipient field. The assignment rule is GROUP, the sender field is TDID. A comparison of IDs for the purchase order and sales order is provided in the documentation on the ‘Stock Transfer Between Distributed Systems’ Scenario in the IMG. EDI settings: 1. EDI settings for incoming sales orders -Configuration of EDI partners (table EDPAR). Derivation of internal partner numbers from the combination sold-to party - partner role - external partner number -Maintenance of possible partner roles -Derivation of the sales area (table EDSDC) from the combination customer - vendor. If the sales area is specified in the IDoc, the table is not required. 2. Message handling for incoming orders Messages that are output for an inbound IDoc (if the IDoc contains conditions or payment conditions, for example) can be defined as information, warnings, or document blocks. 3. Conversion from SAP item category to IDoc item category An item category can be provided in the IDoc. This is converted to an SAP item category via the EDPST table. (If no item category is specified, the SD item category is determined in the standard manner). For converting the text IDs: Purchasing and Sales use different text IDs. If order texts are to be copied to the sales orders, a conversion must take place. This can be performed using the ALE conversion. For the purchase order (ORDERS) and the purchase order change (ORDCHG), conversions must take place at header and item level. These conversions can be carried out by generating a conversion rule for the document header (segment E1EDKT1) and the item (segment E1EDPT1). When defining this rule, use TDID for the recipient field. The assignment rule is GROUP, the sender field is TDID. A comparison of IDs for the purchase order and sales order is provided in the documentation on the ‘Stock Transfer Between Distributed Systems’ Scenario in the IMG. EDI settings: 1. EDI settings for incoming sales orders-Configuration of EDI partners (table EDPAR). Derivation of internal partner numbers from the combination sold-to party - partner role - external partner number-Maintenance of possible partner roles-Derivation of the sales area (table EDSDC) from the combination customer - vendor. If the sales area is specified in the IDoc, the table is not required. 2. Message handling for incoming ordersMessages that are output for an inbound IDoc (if the IDoc contains conditions or payment conditions, for example) can be defined as information, warnings, or document blocks. 3. Conversion from SAP item category to IDoc item categoryAn item category can be provided in the IDoc. This is converted to an SAP item category via the EDPST table. (If no item category is specified, the SD item category is determined in the standard manner).

    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->Materials Management->Invoice Verification->EDI Setting message types: For exporting the purchase order (message type ‘NEW’) and the order confirmation, you can configure the system in such a way that a change message is generated automatically. This is the prerequisite for generating the corresponding IDocs for the purchase order change and for changing the sales order. The ‘change message’ flag is part of the key for determining the transaction code for outbound processing of the IDocs. (Message control within partner maintenance). To trigger ALE outbound processing via message control, the routine ALE_PROCESSING from the RSNASTED program must be assigned to the message concerned with medium ‘A’ (ALE) in Customizing as the processing program. EDI settings for the incoming invoice: Assign a tax code SAP tax codes are assigned to the tax rates from the IDoc. Assign a company code A company code is assigned to the name of the delivering company from the IDoc. Assign program parameters Parameters for controlling the processing of incoming invoices are derived from the combination partner type, partner number (for ALE, that is ‘LS’ + logical system) and company code. (Park document, generate BDC session, calculate tax, document type of the incoming invoice, for example). Setting message types: For exporting the purchase order (message type ‘NEW’) and the order confirmation, you can configure the system in such a way that a change message is generated automatically. This is the prerequisite for generating the corresponding IDocs for the purchase order change and for changing the sales order. The ‘change message’ flag is part of the key for determining the transaction code for outbound processing of the IDocs. (Message control within partner maintenance). To trigger ALE outbound processing via message control, the routine ALE_PROCESSING from the RSNASTED program must be assigned to the message concerned with medium ‘A’ (ALE) in Customizing as the processing program. EDI settings for the incoming invoice: Assign a tax codeSAP tax codes are assigned to the tax rates from the IDoc. Assign a company codeA company code is assigned to the name of the delivering company from the IDoc. Assign program parametersParameters for controlling the processing of incoming invoices are derived from the combination partner type, partner number (for ALE, that is ‘LS’ + logical system) and company code. (Park document, generate BDC session, calculate tax, document type of the incoming invoice, for example).

    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 Vendor master: in the system of the ordering plant, a vendor is created that represents the delivering system. The customer number of the sold-to party, for whom the sales order is to be generated in the delivering system, can be entered in the ‘Correspondance’ view in the ‘Own number at partner’ field. This number is transferred as the sold-to party to the IDoc for the ORDERS message type. Purchasing info record: the material number from the purchase order can be converted to the material number for vendor using the purchasing info record. This conversion must also take place if the numbers are identical. Alternatively, the conversion can also be performed in inbound processing in the customer material info record (SD). Customer master: in the system of the delivering plant, a customer master is created for the sold-to party (and possibly other partners). The number of the vendor from the ordering system can be stored in the ‘Sales’ view in the ‘Account at customer’ field of the sold-to party master record. Outbound processing copies this number to the IDoc for message type INVOIC as the invoicing party for billing. The creditor is determined when the incoming invoice is processed, using partner role ‘RS’ or ‘LF’. Message conditions: can be stored under various keys. The transmission medium is ‘A’ (ALE) . Vendor master: in the system of the ordering plant, a vendor is created that represents the delivering system. The customer number of the sold-to party, for whom the sales order is to be generated in the delivering system, can be entered in the ‘Correspondance’ view in the ‘Own number at partner’ field. This number is transferred as the sold-to party to the IDoc for the ORDERS message type. Purchasing info record: the material number from the purchase order can be converted to the material number for vendor using the purchasing info record. This conversion must also take place if the numbers are identical. Alternatively, the conversion can also be performed in inbound processing in the customer material info record (SD). Customer master: in the system of the delivering plant, a customer master is created for the sold-to party (and possibly other partners). The number of the vendor from the ordering system can be stored in the ‘Sales’ view in the ‘Account at customer’ field of the sold-to party master record. Outbound processing copies this number to the IDoc for message type INVOIC as the invoicing party for billing. The creditor is determined when the incoming invoice is processed, using partner role ‘RS’ or ‘LF’. Message conditions: can be stored under various keys. The transmission medium is ‘A’ (ALE) .

    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 The exits in outbound processing generally provide the option of Changing fields in IDoc segments Supplying new segments in the IDocs Performing updates in the control record of the IDoc …….The exits in outbound processing generally provide the option of Changing fields in IDoc segments Supplying new segments in the IDocs Performing updates in the control record of the IDoc …….

    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) In inbound processing, customer-specific segments are processed entirely in EXITS. Options are also provided for Performing additional checks on the segment data, Changing the established application tables, Changing the status table, .. . Inbound processing also supports functions that depend specifically on individual logistics message types. Examples: Incoming sales order: determine sold-to party, sales area, order type. Incoming invoice: determine G/L account per invoice line, additional account assignment per invoice line, name of the BDC session, .. In inbound processing, customer-specific segments are processed entirely in EXITS. Options are also provided for Performing additional checks on the segment data, Changing the established application tables, Changing the status table, .. . Inbound processing also supports functions that depend specifically on individual logistics message types. Examples: Incoming sales order: determine sold-to party, sales area, order type. Incoming invoice: determine G/L account per invoice line, additional account assignment per invoice line, name of the BDC session, ..

    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 Call CUSTOMER FUNCTION: call customer-function '006' tables didoc_data = idoc_data changing dxvbak = xvbak exceptions user_error = 01. Call CUSTOMER FUNCTION: call customer-function '006' tables didoc_data = idoc_data changing dxvbak = xvbak exceptions user_error = 01.

    97. Contents, SD-MM Link

    98. Scenario: Decentral Sales, Central Shipping, Assigned standard purchase order Menu No specific function in the menu Online help Help->SAP Library->CA(/Cross Application)->Business Framework Architecture->ALE->ALE Business Processes Library->Logistics-Logistics->'Separate Sales and Shipping' Scenario IMG IMG->Cross-Application Components->Predefined ALE Business Processes->Logistics->LO-LO->‘Separate Sales and Shipping’ Scenario Menu No specific function in the menu Online help Help->SAP Library->CA(/Cross Application)->Business Framework Architecture->ALE->ALE Business Processes Library->Logistics-Logistics->'Separate Sales and Shipping' Scenario IMG IMG->Cross-Application Components->Predefined ALE Business Processes->Logistics->LO-LO->‘Separate Sales and Shipping’ Scenario

    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

    101. Automatization of External Procurement for ALE

    102. Scenario: Local Sales, Central Shipping, External Procurement Menu No specific function in the menu Online help Help->SAP Library->CA(/Cross Application)->Business Framework Architecture->ALE->ALE Business Processes Library->Logistics-Logistics->‘Separate Sales and Shipping’ Scenario IMG IMG->Cross-Application Components->ALE->Predefined ALE Business Processes->Logistics->LO-LO->‘Separate Sales and Shipping’ Scenario Menu No specific function in the menu Online help Help->SAP Library->CA(/Cross Application)->Business Framework Architecture->ALE->ALE Business Processes Library->Logistics-Logistics->‘Separate Sales and Shipping’ Scenario IMG IMG->Cross-Application Components->ALE->Predefined ALE Business Processes->Logistics->LO-LO->‘Separate Sales and Shipping’ Scenario

    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->Sales and Distribution->Electronic Data Interchange->EDI Messages Perform consistency checks: Check technical consistency / RBSDMM1 - Check application consistency / Check control data consistency Converting the text IDs: Purchasing and Sales use different text IDs. If order texts are to be copied to the sales orders, a conversion has to take place. This can be performed using the ALE conversion. For the purchase order (ORDERS) and the purchase order change (ORDCHG), conversions must take place at header and item level. These conversions can be carried out by generating a conversion rule for the document header (segment E1EDKT1) and the item (segment E1EDPT1). When defining this rule, use TDID for the recipient field. The assignment rule is GROUP, the sender field is TDID. A comparison of the IDs for purchase order and sales order is provided in the documentation on the ‘Stock Transfer Between Distributed Systems’ Scenario in the IMG. EDI settings: 1. EDI settings for incoming sales orders -Configuration of EDI partners (table EDPAR). Derivation of internal partner numbers from the combination sold-to party/partner role/external partner number -Maintenance of possible partner roles -Derivation of the sales area (table EDSDC) from the combination customer/vendor. If the sales area is specified in the IDoc, the table is not required. 2. Message handling for incoming orders Messages that are output for an inbound IDoc (if the IDoc contains conditions or payment conditions that can be defined as information, warnings, or document blocks, for example). 3. Conversion from SAP item category to IDoc item category An item category can be specified in the IDoc. This is converted to an SAP item via the EDPST table. (If no item category is specified, the SD item category is determined in the standard manner). Converting the text IDs: Purchasing and Sales use different text IDs. If order texts are to be copied to the sales orders, a conversion has to take place. This can be performed using the ALE conversion. For the purchase order (ORDERS) and the purchase order change (ORDCHG), conversions must take place at header and item level. These conversions can be carried out by generating a conversion rule for the document header (segment E1EDKT1) and the item (segment E1EDPT1). When defining this rule, use TDID for the recipient field. The assignment rule is GROUP, the sender field is TDID. A comparison of the IDs for purchase order and sales order is provided in the documentation on the ‘Stock Transfer Between Distributed Systems’ Scenario in the IMG. EDI settings: 1. EDI settings for incoming sales orders-Configuration of EDI partners (table EDPAR). Derivation of internal partner numbers from the combination sold-to party/partner role/external partner number-Maintenance of possible partner roles-Derivation of the sales area (table EDSDC) from the combination customer/vendor. If the sales area is specified in the IDoc, the table is not required. 2. Message handling for incoming ordersMessages that are output for an inbound IDoc (if the IDoc contains conditions or payment conditions that can be defined as information, warnings, or document blocks, for example). 3. Conversion from SAP item category to IDoc item categoryAn item category can be specified in the IDoc. This is converted to an SAP item via the EDPST table. (If no item category is specified, the SD item category is determined in the standard manner).

    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->Materials Management->Invoice Verification->EDI Setting message types: For exporting the purchase order (message type ‘NEW’) and the order confirmation, you can configure the system in such a way that a change message is generated automatically. This is a prerequisite for generating the corresponding IDocs for the purchase order change and for changing the sales order. The ‘change message’ flag is part of the key for determining the transaction code for outbound processing of the IDocs. (Message control within partner maintenance). To trigger ALE outbound processing via message control, the ALE_PROCESSING routine from the RSNASTED program must be assigned to the message concerned with medium ‘A’ (ALE) in Customizing as the processing program. EDI settings for the incoming invoice: Assign a tax code SAP tax codes are assigned to the tax rates from the IDoc. Assign a company code A company code is assigned to the name of the delivering company from the IDoc. Assign program parameters Parameters for controlling the processing of incoming invoices are derived from the combination partner type, partner number (for ALE, that is ‘LS’ + logical system), and company code (Park document, generate BDC session, calculate tax, document type of the incoming invoice, for example). Setting message types: For exporting the purchase order (message type ‘NEW’) and the order confirmation, you can configure the system in such a way that a change message is generated automatically. This is a prerequisite for generating the corresponding IDocs for the purchase order change and for changing the sales order. The ‘change message’ flag is part of the key for determining the transaction code for outbound processing of the IDocs. (Message control within partner maintenance). To trigger ALE outbound processing via message control, the ALE_PROCESSING routine from the RSNASTED program must be assigned to the message concerned with medium ‘A’ (ALE) in Customizing as the processing program. EDI settings for the incoming invoice: Assign a tax codeSAP tax codes are assigned to the tax rates from the IDoc. Assign a company codeA company code is assigned to the name of the delivering company from the IDoc. Assign program parametersParameters for controlling the processing of incoming invoices are derived from the combination partner type, partner number (for ALE, that is ‘LS’ + logical system), and company code (Park document, generate BDC session, calculate tax, document type of the incoming invoice, for example).

    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. The item categories ALEN and ALES are flagged as ‘ALE-relevant’. This means that an additional status (order confirmation status) is managed. Furthermore, the ‘ALECREATED’ event is triggered if at least one ALE-relevant item category occurs in the order. This event converts the PReq generated by the sales order to a purchase order. (The function module ‘PUR_ORDER_CREATE_VIA_SD_EVENT’ is determined for business object ‘BUS2032’ and event ‘ALECREATED’ via the workflow event link. This generates the purchase order. Changes are sent via the event ‘ALECHANGED’). The schedule line categories control the creation of purchase requisitions from the sales order. The parameters for creating the purchase order are determine via the sales organization. You can specify a vendor here, for example. This is useful if there is only one shipping system and if all materials are supplied by it. If a vendor (and thus a different shipping system) is to be determined for each material, this condition can be defined via purchasing info records or source lists. Several vendors can also be enabled for one material by using a CUSTOMER EXIT. The item categories ALEN and ALES are flagged as ‘ALE-relevant’. This means that an additional status (order confirmation status) is managed. Furthermore, the ‘ALECREATED’ event is triggered if at least one ALE-relevant item category occurs in the order. This event converts the PReq generated by the sales order to a purchase order. (The function module ‘PUR_ORDER_CREATE_VIA_SD_EVENT’ is determined for business object ‘BUS2032’ and event ‘ALECREATED’ via the workflow event link. This generates the purchase order. Changes are sent via the event ‘ALECHANGED’). The schedule line categories control the creation of purchase requisitions from the sales order. The parameters for creating the purchase order are determine via the sales organization. You can specify a vendor here, for example. This is useful if there is only one shipping system and if all materials are supplied by it. If a vendor (and thus a different shipping system) is to be determined for each material, this condition can be defined via purchasing info records or source lists. Several vendors can also be enabled for one material by using a CUSTOMER EXIT.

    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 Vendor master: in the system of the ordering plant, a vendor is created that represents the delivering system. The customer number of the sold-to party, for whom the sales order is to be generated in the delivering system, can be entered in the ‘Correspondence’ view in the ‘Own number at partner’ field. This number is transferred to the IDoc as the sold-to party for message type ORDERS. Purchasing info record: the material number from the purchase order can be converted to the material number for the vendor using the purchasing info record. This conversion must also take place if the numbers are identical. Alternatively, the conversion can also take place in inbound processing in the customer material info record (SD). Customer master: in the system of the delivering plant, a customer master is created for the sold-to party (and possibly other partners). The number of the vendor from the ordering system can be stored in the STP master record in the ‘Sales’ view in the ‘Account at customer’ field. Outbound processing copies this number to the IDoc for message type INVOIC as the invoicing party for billing. The creditor is determined when the incoming invoice is processed, using partner role ‘RS’ or ‘LF’. Message conditions: can be stored under various keys. The transmission medium is ‘A’ (ALE) . Vendor master: in the system of the ordering plant, a vendor is created that represents the delivering system. The customer number of the sold-to party, for whom the sales order is to be generated in the delivering system, can be entered in the ‘Correspondence’ view in the ‘Own number at partner’ field. This number is transferred to the IDoc as the sold-to party for message type ORDERS. Purchasing info record: the material number from the purchase order can be converted to the material number for the vendor using the purchasing info record. This conversion must also take place if the numbers are identical. Alternatively, the conversion can also take place in inbound processing in the customer material info record (SD). Customer master: in the system of the delivering plant, a customer master is created for the sold-to party (and possibly other partners). The number of the vendor from the ordering system can be stored in the STP master record in the ‘Sales’ view in the ‘Account at customer’ field. Outbound processing copies this number to the IDoc for message type INVOIC as the invoicing party for billing. The creditor is determined when the incoming invoice is processed, using partner role ‘RS’ or ‘LF’. Message conditions: can be stored under various keys. The transmission medium is ‘A’ (ALE) .

    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 The exits in outbound processing provide the option of Changing fields in IDoc segments Supplying new segments in the IDocs Performing updates in the control record of the IDoc …….The exits in outbound processing provide the option of Changing fields in IDoc segments Supplying new segments in the IDocs Performing updates in the control record of the IDoc …….

    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) In inbound processing, customer-specific segments are processed entirely in EXITS. Options are also provided for Performing additional checks on the segment data, Changing the established application tables, Changing the status table, .. . Inbound processing also supports functions that depend specifically on individual logical message types. Examples: Inbound sales order: determine the sold-to party, sales area, order type. Inbound invoice: determine G/L account and additional account assignment per invoice line, determine name of the BDC session, .. In inbound processing, customer-specific segments are processed entirely in EXITS. Options are also provided for Performing additional checks on the segment data, Changing the established application tables, Changing the status table, .. . Inbound processing also supports functions that depend specifically on individual logical message types. Examples: Inbound sales order: determine the sold-to party, sales area, order type. Inbound invoice: determine G/L account and additional account assignment per invoice line, determine name of the BDC session, ..

    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. 1. Goods receipts for the purchase order with stock material takes place at the order value. If processing is handled in one company code, this must also be the value of the goods issue posting from the delivering system. If the standard price is used, it can be stored as a purchasing condition. The valuation cannot be mapped correctly if an MAP is used. 4. No stock in transit is managed. The GI posting reduces the stock in the delivering system. The stock does not appear again until the GR for the purchase order is posted in the ordering system. 5. Inbound processing for message ORDRSP cannot process a confirmed quantity of ‘zero’. In other words, situations in which confirmation is not possible in the delivering plant, because of the availability situation, cannot be mapped. The tolerances cannot be set in a way that allows ‘zero’ to be accepted. 6. Deletion of the delivery is not forwarded to the purchase order. (The shipping notification is received in its original form). If the delivery is created again after it was deleted, there are 2 notifications for the purchase order item. 7. The procedure for deleting/canceling an order item is problematic. When an order item is deleted, the purchase order item is not deleted, as this would create a new purchase order. The same problems would arise with confirming zero quantities. 8. Purchase order items can still be deleted if they have already been delivered in the vendor system.1. Goods receipts for the purchase order with stock material takes place at the order value. If processing is handled in one company code, this must also be the value of the goods issue posting from the delivering system. If the standard price is used, it can be stored as a purchasing condition. The valuation cannot be mapped correctly if an MAP is used. 4. No stock in transit is managed. The GI posting reduces the stock in the delivering system. The stock does not appear again until the GR for the purchase order is posted in the ordering system. 5. Inbound processing for message ORDRSP cannot process a confirmed quantity of ‘zero’. In other words, situations in which confirmation is not possible in the delivering plant, because of the availability situation, cannot be mapped. The tolerances cannot be set in a way that allows ‘zero’ to be accepted. 6. Deletion of the delivery is not forwarded to the purchase order. (The shipping notification is received in its original form). If the delivery is created again after it was deleted, there are 2 notifications for the purchase order item. 7. The procedure for deleting/canceling an order item is problematic. When an order item is deleted, the purchase order item is not deleted, as this would create a new purchase order. The same problems would arise with confirming zero quantities. 8. Purchase order items can still be deleted if they have already been delivered in the vendor system.

    111. Contents, SD-MM Link

    112. Alternative Processing of Stock Transfers Via Scheduling Agreements Generation of MM schedule agreement delivery scheduling lines from MRP, transfer to the other system and storage as SD schedule agreement delivery scheduling lines (message type DELINS). The MM and SD scheduling agreements must be generated beforehand. Shipping notifications can be used (message type DESADV). For clearing (2 company codes), 3 alternatives are possible: 1: billing of the SD delivery, transfer of the billing document and inbound processing as the incoming invoice for MM-LP. 2: ERS credit memo procedure via credit display and payment notification (message types GSVERF, REMADV) 3: Processing via clearing accounts (not in the standard system). GI for delivery and GR for MM-LP can be linked via ALE (not in the standard system). Generation of MM schedule agreement delivery scheduling lines from MRP, transfer to the other system and storage as SD schedule agreement delivery scheduling lines (message type DELINS). The MM and SD scheduling agreements must be generated beforehand. Shipping notifications can be used (message type DESADV). For clearing (2 company codes), 3 alternatives are possible: 1: billing of the SD delivery, transfer of the billing document and inbound processing as the incoming invoice for MM-LP. 2: ERS credit memo procedure via credit display and payment notification (message types GSVERF, REMADV) 3: Processing via clearing accounts (not in the standard system). GI for delivery and GR for MM-LP can be linked via ALE (not in the standard system).

    113. Contents, SD-MM Link

    114. Application Example VMI (Vendor Managed Inventory) Menu Logistics->Sales and distribution->Sales->Order->Customer replenishment Online help Help->R/3 Library->Logistics->Retail->Vendor Managed InventoryMenu Logistics->Sales and distribution->Sales->Order->Customer replenishment Online help Help->R/3 Library->Logistics->Retail->Vendor Managed Inventory

    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

    117. Data Warehouse Concepts More recent Data Warehouse concepts use a three-tier model to implement more powerful, integrated information systems. The three tiers divide the entire data flow, from data entry in operative systems, right up to the presentation of information at the top tier. Operative, integrated applications in OLTP systems form the basis of the information entered. These systems handle large volumes of master and process data, which must be presented in a formatted form via information systems. For this purpose, the application data is summarized in a few, meaningful key figures and managed separately in the database tables of a Data Warehouse. Various analysis tools are available in a third tier for evaluating the statistical data gained in this way. They offer a variety of options for complex analysis and presentation of the statistical data and therefore represent a powerful set of decision-making instruments in modern management.More recent Data Warehouse concepts use a three-tier model to implement more powerful, integrated information systems. The three tiers divide the entire data flow, from data entry in operative systems, right up to the presentation of information at the top tier. Operative, integrated applications in OLTP systems form the basis of the information entered. These systems handle large volumes of master and process data, which must be presented in a formatted form via information systems. For this purpose, the application data is summarized in a few, meaningful key figures and managed separately in the database tables of a Data Warehouse. Various analysis tools are available in a third tier for evaluating the statistical data gained in this way. They offer a variety of options for complex analysis and presentation of the statistical data and therefore represent a powerful set of decision-making instruments in modern management.

    118. Logistics Data Warehouse The individual, physical tables of the SAP Information Warehouse are referred to as information structures; they are described transparently in the SAP Data Dictionary. Information structures, or info structures, have a typical structure: The analysis objects of the real business world are represented in the info structures in the form of so-called characteristics. Statistical information is updated and summarized in characteristics such as vendor, customer, or material. Organizational elements, such as purchasing group, material group, valuation area, plant, or storage location, are also used as characteristics in info structures. The time reference represents a further summarization option; the data is not only cumulated per characteristic but also per period. As far as the period is concerned, you can compress the data in each info structure on a daily, weekly, and monthly data basis. Logistics key figures are updated for each characteristic combination and periodicity. These are quantitative variables that provide information on measurable aspects. Key figures can be recorded for each evaluation group by means of cumulation, such as purchase order quantity or production order quantity. They can, however, also be simple counters such as ‘number of deliveries’, for example. The SAP standard system contains various info structures for different application areas. Convenient tools also allow characteristics and key figures to be grouped into individual info structures, also in line with user-defined criteria, and to be supplied with data using separate update programs.The individual, physical tables of the SAP Information Warehouse are referred to as information structures; they are described transparently in the SAP Data Dictionary. Information structures, or info structures, have a typical structure: The analysis objects of the real business world are represented in the info structures in the form of so-called characteristics. Statistical information is updated and summarized in characteristics such as vendor, customer, or material. Organizational elements, such as purchasing group, material group, valuation area, plant, or storage location, are also used as characteristics in info structures. The time reference represents a further summarization option; the data is not only cumulated per characteristic but also per period. As far as the period is concerned, you can compress the data in each info structure on a daily, weekly, and monthly data basis. Logistics key figures are updated for each characteristic combination and periodicity. These are quantitative variables that provide information on measurable aspects. Key figures can be recorded for each evaluation group by means of cumulation, such as purchase order quantity or production order quantity. They can, however, also be simple counters such as ‘number of deliveries’, for example. The SAP standard system contains various info structures for different application areas. Convenient tools also allow characteristics and key figures to be grouped into individual info structures, also in line with user-defined criteria, and to be supplied with data using separate update programs.

    119. Online Transaction Processing LIS update for process data handling Extraction Summarizing Calculation of key figures Modules from SAP R/2, SAP R/3, and also from non-SAP systems can be integrated at the OLTP level. When all business processes are mapped in detail, these applications contain enormous volumes of incomprehensible data. The Logistics Information Systems of the SAP R/3 System are anchored in the SAP R/3 OLTP applications via specific update modules. By summarizing data, the LIS update programs represent one of the most important basic ideas of the entire LIS concept. Update programs reduce the process data quantity to its relevant components; they compress the data by means of periodic and object-related cumulation and calculate meaningful key figures from the process data using formulas and conditions. The statistical data can be updated in the LIS while the process data is being processed so that the consistency of the LIS information and the data in the operative application is guaranteed. In order to reduce the system load in the application systems, the update can also take place periodically. A link between the R/3 LIS component and external OLTP systems is also implemented. The process data of an SAP R/2 application, for example, can be subsequently supplied to the LIS update programs of an SAP R/3 System. In this way, the LIS can become an R/3 OLAP application for an R/2 OLTP system.Modules from SAP R/2, SAP R/3, and also from non-SAP systems can be integrated at the OLTP level. When all business processes are mapped in detail, these applications contain enormous volumes of incomprehensible data. The Logistics Information Systems of the SAP R/3 System are anchored in the SAP R/3 OLTP applications via specific update modules. By summarizing data, the LIS update programs represent one of the most important basic ideas of the entire LIS concept. Update programs reduce the process data quantity to its relevant components; they compress the data by means of periodic and object-related cumulation and calculate meaningful key figures from the process data using formulas and conditions. The statistical data can be updated in the LIS while the process data is being processed so that the consistency of the LIS information and the data in the operative application is guaranteed. In order to reduce the system load in the application systems, the update can also take place periodically. A link between the R/3 LIS component and external OLTP systems is also implemented. The process data of an SAP R/2 application, for example, can be subsequently supplied to the LIS update programs of an SAP R/3 System. In this way, the LIS can become an R/3 OLAP application for an R/2 OLTP system.

    120. Application Link Enabling (ALE) ALE is available in the LIS from Release 3.0 onwards Inventory Controlling Purchasing Information System Sales Information System Menu No specific function in the menu Online help Help->R/3 Library->CA(/Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Information Systems IMG IMG->Cross-Application Components->ALE->Predefined ALE Business Processes->Logistics->LO-LIS Menu No specific function in the menu Online help Help->R/3 Library->CA(/Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Information Systems IMG IMG->Cross-Application Components->ALE->Predefined ALE Business Processes->Logistics->LO-LIS

    121. ALE in the LIS: Concept Local system 1 The statistical data can be transferred at two levels Level 1 contains all the data required to update info structures. Level 2 only contains aggregated data that has been generated in the local system according to the update rules. Advantages: Level 1: All update-relevant data is available for transfer using ALE. This means that an individual update can take place in the central system. Update in the OLTP is not always necessary Level 2: Can be used for the majority of info structures available in the standard system Low system load as the data is summarized beforehand by the sender Restrictions/disadvantages: Level 1: depending on the volume of documents, the data quantity to be transported can become very large. Access to original documents not possible at the moment Level 2: for every info structure that is filled by means of ALE, an identical info structure must exist in the source system. The systems involved must be reconciled Update in the OLTP always necessary Access to original documents not implemented at present The organizational and master data must be identical in the systems involved. The statistical data can be transferred at two levels Level 1 contains all the data required to update info structures. Level 2 only contains aggregated data that has been generated in the local system according to the update rules. Advantages: Level 1: All update-relevant data is available for transfer using ALE. This means that an individual update can take place in the central system. Update in the OLTP is not always necessary Level 2: Can be used for the majority of info structures available in the standard system Low system load as the data is summarized beforehand by the sender Restrictions/disadvantages: Level 1: depending on the volume of documents, the data quantity to be transported can become very large. Access to original documents not possible at the moment Level 2: for every info structure that is filled by means of ALE, an identical info structure must exist in the source system. The systems involved must be reconciled Update in the OLTP always necessary Access to original documents not implemented at present The organizational and master data must be identical in the systems involved.

    122. ALE in the LIS: Scenarios With ALE, consolidated statistics can also be recorded if different business areas are processed on different R/3 Systems. Depending on the information requirements, different statistics can be updated in the central and local systems. With ALE, consolidated statistics can also be recorded if different business areas are processed on different R/3 Systems. Depending on the information requirements, different statistics can be updated in the central and local systems.

    123. ALE in the LIS: Advantages 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 Statistical data from local R/3 Systems can be consolidated in one central system by integrating ALE. Detailed statistical data can be recorded in local systems while, at the same time, highly-aggregated data is made available in the central system. LIS can run on a separate R/3 System with a reduced system load. Statistical data from local R/3 Systems can be consolidated in one central system by integrating ALE. Detailed statistical data can be recorded in local systems while, at the same time, highly-aggregated data is made available in the central system. LIS can run on a separate R/3 System with a reduced system load.

    124. Distribution of Inventory Controlling, Single Documents

    125. Distribution of Purchasing Info System, Single Documents

    126. Distribution of Sales Info System, Single Documents

    127. Cumulated Distribution of Info Structures Message types can be generated on the basis of info structures Generic IDoc type SOPGEN01 Periodic transfer of the absolute key figures for characteristic combinations which have been changed. Adjustment of actual data (plan version 000) with a comparative version to be defined, via report RBDMCCOP. The characteristic combinations of different delivering systems must be disjunct!

    128. Contents

    129. Contract Distribution Scenario A contract with a special document type for distributed contracts is created in the central system. This contract is copied to the local system, in other words, it is created in the local system under the same document number. In the local system, external number assignment must be set for the document type. In the local system, you can now create release purchase orders with reference to this contract. When the release purchase order is created, the release documentation is updated locally and centrally. --------------------------------------------------------------------------------------------------------- Menu Contract processing in MM Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Logistics->Logistics-Logistics->Distributed contracts IMG IMG->Cross-Application Components->Predefined ALE Business Processes->Logistics->LO-LO->‘Purchasing:Distributed contracts’ Scenario A contract with a special document type for distributed contracts is created in the central system. This contract is copied to the local system, in other words, it is created in the local system under the same document number. In the local system, external number assignment must be set for the document type. In the local system, you can now create release purchase orders with reference to this contract. When the release purchase order is created, the release documentation is updated locally and centrally. --------------------------------------------------------------------------------------------------------- Menu Contract processing in MM Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Logistics->Logistics-Logistics->Distributed contracts IMG IMG->Cross-Application Components->Predefined ALE Business Processes->Logistics->LO-LO->‘Purchasing:Distributed contracts’ Scenario

    130. What is a Purchase Contract? Long-term agreement with a vendor regarding the purchase of a particular material (or material group) Prices, texts, order addresses, and target quantities in particular are recorded here The data in the contract is also used as default data for purchase orders (release purchase orders)

    131. Distribution of Purchase Contracts 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

    132. Distribution of Purchase Contracts 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 MM06E001 and the appropriate Exit

    133. Distribution of Purchase Contracts 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

    134. ALE Customizing, Outbound Processing Central System 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

    135. Application Customizing In the central system IMG: Materials Management -> Purchasing -> Contract -> Define Document Types Flag for change pointer in the document type Number range for release purchase orders from local systems In the local system IMG: Materials Management -> Purchasing -> Contract -> Define Number Ranges Separate number range with external number assignment, number is copied from the central system

    136. Distribution Restrictions 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.

    137. Contents

    138. Contents, Further Business Processes

    139. Local Credit Limit Check General conditions for using the scenario: The sales organizations of the local sales and distribution systems must be assigned to various company codes, there must not be any higher-level company codes, and the company codes must be assigned to different credit control areas. The local sales and distribution systems are independent with regard to credit management, in other words maintenance of the credit master data, checks in SD, and the release by the credit manager are all performed locally. As open sales order, vendor, and billing document values cannot be distributed, the following restrictions apply: To work with distributed systems, one of the following conditions has to be fulfilled: The local sales and distribution systems must have separate credit control areas (no multiple assignments are allowed). or Different customers must be assigned to each of the local sales and distribution systems (no multiple assignments are allowed). or Credit checks in the local sales and distribution systems may only be performed on the FI data (such as static credit limit checks without open credit values from Sales and Distribution, dunning level , and so on) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Menu Accounting->Financial accounting->Accounts receivable->Master records->Credit management Accounting-> Financial accounting->Accounts receivable->Periodic processing->Credit management Online help Help->R/3 Library->Logistics->Sales and Distribution->FI/SD Credit Management->Credit Management in Distributed Systems IMG IMG->Cross-Application Components->Predefined ALE Business Processes->Logistics->LO-AC (Accounting)->‘Distributed Credit Management’ Scenario General conditions for using the scenario: The sales organizations of the local sales and distribution systems must be assigned to various company codes, there must not be any higher-level company codes, and the company codes must be assigned to different credit control areas. The local sales and distribution systems are independent with regard to credit management, in other words maintenance of the credit master data, checks in SD, and the release by the credit manager are all performed locally. As open sales order, vendor, and billing document values cannot be distributed, the following restrictions apply: To work with distributed systems, one of the following conditions has to be fulfilled: The local sales and distribution systems must have separate credit control areas (no multiple assignments are allowed). or Different customers must be assigned to each of the local sales and distribution systems (no multiple assignments are allowed). or Credit checks in the local sales and distribution systems may only be performed on the FI data (such as static credit limit checks without open credit values from Sales and Distribution, dunning level , and so on) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Menu Accounting->Financial accounting->Accounts receivable->Master records->Credit management Accounting-> Financial accounting->Accounts receivable->Periodic processing->Credit management Online help Help->R/3 Library->Logistics->Sales and Distribution->FI/SD Credit Management->Credit Management in Distributed Systems IMG IMG->Cross-Application Components->Predefined ALE Business Processes->Logistics->LO-AC (Accounting)->‘Distributed Credit Management’ Scenario

    140. Contents, Further Business Processes

    141. SOP Program Planning (Sales Operation Planning) Menu No specific function. Production->SOP Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Processes Library->Logistics->Logistics-Logistics->Sales and Operations Planning IMG IMG->Cross-Application Components->ALE->Predefined ALE-Business Processes->Logistics->LO-LO->‘Sales and Operations Planning’ Scenario Menu No specific function. Production->SOP Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Processes Library->Logistics->Logistics-Logistics->Sales and Operations Planning IMG IMG->Cross-Application Components->ALE->Predefined ALE-Business Processes->Logistics->LO-LO->‘Sales and Operations Planning’ Scenario

    142. Contents, Further Business Processes

    143. Cross-System Planning Situation 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. Prerequisites: You have defined your plants uniquely across all systems Your customer model clearly shows the systems in which each plant is managed You have set the authorization for displaying MRP in all of the systems involved Note: The ALE distribution model is used when the evaluation is created in order to determine the systems involved and to find out which plants are defined in these systems. To do so, a dummy distribution is defined (maintenance of the distribution model). The message type is PROPL, IDoc type SYNCHRON. No IDocs are sent. The evaluation is created in the partner systems using a synchronous RFC. ----------------------------------------------------------------------------------------- Menu Logistics->Production->MRP->Evaluations->Situat. - all plants Logistics->Production->Production planning->Long-term planning->Situat. - all plants Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Logistics->Logistics-Logistics->Cross-System Planning Situation IMG IMG->Cross-Application Components->ALE->Predefined ALE Business Processes->Logistics->LO-LO->Cross-System Planning Situation Prerequisites: You have defined your plants uniquely across all systems Your customer model clearly shows the systems in which each plant is managed You have set the authorization for displaying MRP in all of the systems involved Note: The ALE distribution model is used when the evaluation is created in order to determine the systems involved and to find out which plants are defined in these systems. To do so, a dummy distribution is defined (maintenance of the distribution model). The message type is PROPL, IDoc type SYNCHRON. No IDocs are sent. The evaluation is created in the partner systems using a synchronous RFC. ----------------------------------------------------------------------------------------- Menu Logistics->Production->MRP->Evaluations->Situat. - all plants Logistics->Production->Production planning->Long-term planning->Situat. - all plants Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Logistics->Logistics-Logistics->Cross-System Planning Situation IMG IMG->Cross-Application Components->ALE->Predefined ALE Business Processes->Logistics->LO-LO->Cross-System Planning Situation

    144. Process Description After you have started the evaluation, the system uses the customer distribution model to check which plants are created in which logical R/3 System. The system checks all the plants to determine whether they contain the relevant material. If this is the case, the required MRP data is interrogated via synchronous Remote Function Calls (RFCs). If the calling system cannot access some of the information that it needs (if there is no access authorization, for example), it logs an error, which you can also display. The planning situation is displayed on the screen. The report contains all MRP elements that are defined in the layout set for the evaluation, such as production orders, purchase orders, sales orders, reservations, or warehouse stocks.

    145. Contents, Further Business Processes

    146. WMS as a Component Menu No specific function. Shipping, ordering, inventory management Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Decentral Warehouse Management IMG IMG->Logistics Execution->Decentralized WMS Integration Menu No specific function. Shipping, ordering, inventory management Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Decentral Warehouse Management IMG IMG->Logistics Execution->Decentralized WMS Integration

    147. WMS as a Component

    148. WMS as a Component Goods receipt for the purchase order: 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

    149. WMS as a Component Stock transfer: 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 outbound delivery 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.

    150. WMS as a Component Goods issue for delivery: Create sales order Create outbound delivery Distribute delivery to the WMS Create transfer order for the outbound delivery Physically perform picking in the warehouse Confirm transfer order Print delivery shipping documents, if necessary Post goods issue for outbound delivery (confirmation is to the ERP system as a result, using the BAPI method ‘OutboundDelivery.ConfirmDecentral’) Goods issues for outbound delivery in the ERP system (posting in inventory management) are posted automatically when the confirmation is imported

    151. Contents, Further Business Processes

    152. Generic Vendor Interface, IDoc DELVRY01 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 Menu No specific function. General shipping Online help Help->R/3 Library->Logistics->SD-Sales and Distribution->Shipping->Vendor Interface IMG No specific function. General shipping Menu No specific function. General shipping Online help Help->R/3 Library->Logistics->SD-Sales and Distribution->Shipping->Vendor Interface IMG No specific function. General shipping

    153. Generic Vendor Interface, IDoc DELVRY01

    154. Contents, Further Business Processes

    155. R/2-R/3 Link in Shipping Menu Logistics->Sales and Distribution->Shipping->Environment->R/2-R/3 Link Online help Help->R/3 Library->Logistics->SD-Sales and Distribution->Shipping and Transportation->R/2-R/3 Link IMG IMG->Logistics Execution->Shipping->R/2-R/3 Link Menu Logistics->Sales and Distribution->Shipping->Environment->R/2-R/3 Link Online help Help->R/3 Library->Logistics->SD-Sales and Distribution->Shipping and Transportation->R/2-R/3 Link IMG IMG->Logistics Execution->Shipping->R/2-R/3 Link

    156. Contents, Further Business Processes

    157. Transport Optimization, Process, Integrating the Interface in the Process Menu Logistics->Sales and Distribution->Transportation->External systems ->Transport planning Online help Help->R/3 Library->Logistics->SD-Sales and Distribution->Transport->Transport planning interface IMG IMG->Logistics Execution->Transport->Interfaces->External Transportation Planning Systems Information on certification: www.sap.com/products/compsoft/certify/Menu Logistics->Sales and Distribution->Transportation->External systems ->Transport planning Online help Help->R/3 Library->Logistics->SD-Sales and Distribution->Transport->Transport planning interface IMG IMG->Logistics Execution->Transport->Interfaces->External Transportation Planning Systems Information on certification: www.sap.com/products/compsoft/certify/

    158. Transport Optimization, Individual Functions Functions The SD-TPS interface supports the following functions: SAP to the transport planning system: Transfer of local master data Transfer of deliveries to be scheduled Transfer of status values for planned transports Transport planning system to SAP: Transfer of planned transports Error status is also exchanged between the two systems, with regard to the logical correctness of the transferred documents.

    159. Contents, Further Business Processes

    160. Warehouse Management, MM-MOB, WM-LSR Assignment of IDoc to interface IDoc Component Description WMMBID01 MOB Goods movements SDPIOD01 MOB Picking message to the external system SDPIID01 MOB Picking confirmation SDPAID01 MOB Shipping unit confirmation LSR/MOB LSR/MOB Transfer orders TO LSR/MOB LSR/MOB Confirmation of transfer orders LSR/MOB LSR/MOB Reversal requirement / reversal TO LSR/MOB LSR/MOB Transfer orders TO LSR/MOB LSR/MOB Block storage bins LSR/MOB LSR/MOB Release TOs for the group LSR/MOB LSR/MOB Movement of storage units LSR/MOB LSR/MOB Entry of actual inventory count data LSR/MOB LSR/MOB Information text -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Menu Logistics->Logistics Execution->Warehouse Management Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Logistics->Logistics-Logistics->MM-MOB and WM-LSR Interfaces IMG IMG->Logistics Execution->Warehouse Management->Interfaces->External Systems Information on certification: www.sap.com/products/compsoft/certify/ Assignment of IDoc to interface IDoc Component Description WMMBID01 MOB Goods movements SDPIOD01 MOB Picking message to the external system SDPIID01 MOB Picking confirmation SDPAID01 MOB Shipping unit confirmation LSR/MOB LSR/MOB Transfer orders TO LSR/MOB LSR/MOB Confirmation of transfer orders LSR/MOB LSR/MOB Reversal requirement / reversal TO LSR/MOB LSR/MOB Transfer orders TO LSR/MOB LSR/MOB Block storage bins LSR/MOB LSR/MOB Release TOs for the group LSR/MOB LSR/MOB Movement of storage units LSR/MOB LSR/MOB Entry of actual inventory count data LSR/MOB LSR/MOB Information text -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Menu Logistics->Logistics Execution->Warehouse Management Online help Help->R/3 Library->CA /Cross Application)->Business Framework Architecture->ALE->ALE Business Process Library->Logistics->Logistics-Logistics->MM-MOB and WM-LSR Interfaces IMG IMG->Logistics Execution->Warehouse Management->Interfaces->External Systems Information on certification: www.sap.com/products/compsoft/certify/

    161. Warehouse Management, WM-LSR, Scenarios These scenarios are described in detail in the online documentation Goods receipt external system in inventory management Putaway from production in inventory management Putaway from production in Warehouse Management Putaway of WM with manual storage bin assignment Replenishment TR for Production Entry of inventory count data without WM (offline) Entry of inventory count data with WM Confirmation of packing to SD, link to picking systems Link to scales

    162. Warehouse Management, WM-LSR, Scenarios 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

    163. Contents, Further Business Processes

    164. Productions Optimization Interface (POI) Menu Logistics->Central Functions->SCP Interface->SCP Interfaces->POI Online help Online help->R/3 Library->LO->Logistics-General->Supply Chain Interfaces ->Interfaces for Supply Chain Planning->Production Optimization Interface (POI) IMG IMG->Logistics - General->Supply Chain Planning Interfaces (SCPI) ->Production Optimization Interface (POI) Information on certification: www.sap.com/products/compsoft/certify/ Menu Logistics->Central Functions->SCP Interface->SCP Interfaces->POI Online help Online help->R/3 Library->LO->Logistics-General->Supply Chain Interfaces ->Interfaces for Supply Chain Planning->Production Optimization Interface (POI) IMG IMG->Logistics - General->Supply Chain Planning Interfaces (SCPI) ->Production Optimization Interface (POI) Information on certification: www.sap.com/products/compsoft/certify/

    166. DP/DRP Interface Menu Logistics->Central functions->SCP interface ->SCP interfaces->POI Online help Online help->R/3 Library->LO->Logistics-General->Supply Chain Interfaces ->Interfaces for Supply Chain Planning->Production Optimization Interface (POI) IMG IMG->Logistics - General->Supply Chain Planning Interfaces (SCPI) ->Production Optimization Interface (POI) Information on certification: www.sap.com/products/compsoft/certify/ Menu Logistics->Central functions->SCP interface ->SCP interfaces->POI Online help Online help->R/3 Library->LO->Logistics-General->Supply Chain Interfaces ->Interfaces for Supply Chain Planning->Production Optimization Interface (POI) IMG IMG->Logistics - General->Supply Chain Planning Interfaces (SCPI) ->Production Optimization Interface (POI) Information on certification: www.sap.com/products/compsoft/certify/

    167. Overview, Deployment

    168. DP/DRP Interface Menu Logistics->Central functions->SCP Interface ->SCP Interfaces->POI Online help Online help->R/3 Library->LO->Logistics-General->Supply Chain Interfaces ->Interfaces for Supply Chain Planning->Production Optimization Interface (POI) IMG IMG->Logistics - General->Supply Chain Planning Interfaces (SCPI) ->Production Optimization Interface (POI) Information on certification: www.sap.com/products/compsoft/certify/ Menu Logistics->Central functions->SCP Interface ->SCP Interfaces->POI Online help Online help->R/3 Library->LO->Logistics-General->Supply Chain Interfaces ->Interfaces for Supply Chain Planning->Production Optimization Interface (POI) IMG IMG->Logistics - General->Supply Chain Planning Interfaces (SCPI) ->Production Optimization Interface (POI) Information on certification: www.sap.com/products/compsoft/certify/

    169. Overview, DRP (Distribution Resource Planning)

More Related