hi
The following is a set of logistics business processes or ALE business scenarios together with their related message types and IDoc types. Process
Message types / IDocs / scenarios
Separate sales and shipping
When a customer places an order in the case of decentralized sales, a sales order is posted there. In the process, a purchase order is generated automatically for the main shipping system (vendor). This purchase order generates a sales order in central shipping. The local sales office can be notified through a confirmation and/or a shipping notification. The delivery to the customer can take place directly through the main shipping system or through the local sales office (after supply from the main shipping system). After the delivery is made, the internal billing document is passed on to the local sales office as an incoming invoice for the purchase order.
ORDERS / ORDERS04
ORDCHG / ORDERS04
ORDRSP / ORDERS04
DESADV / DELVRY02
INVOIC / INVOIC02
Scenarios that must be taken into account:
Distributed credit management
Stock transfer of goods
Financial Accounting
Profitability Analysis
Distributed credit management
This scenario should be used when several local sales systems perform their credit limit checks in a central accounting system. To achieve this, the central accounting system sends a credit vector that contains all the required credit information for an account in a control area. The local checks are then performed against this credit vector. If the credit vector is outdated, a synchronous function call can be triggered to determine the current data in the central accounting system.
CRESTA / CRESTA01
Scenarios that must be taken into account:
Separate sales and shipping
Financial Accounting
Stock transfer of goods
The requesting system (e.g. sales) generates a purchase order in the supplying system (e.g. production). This purchase order generates a sales order in the supplying system. The requesting system can be notified through a confirmation and/or a shipping notification. After the delivery is made, the billing document is passed on to the requesting system as an incoming invoice for the purchase order.
ORDERS / ORDERS04
ORDCHG / ORDERS04
ORDRSP / ORDERS04
DESADV / DELVRY02
INVOIC / INVOIC02
Scenarios that must be taken into account:
Separate sales and shipping
Financial Accounting
Distributed purchasing contracts
This scenario enables the distribution of contracts using local calls:
A central purchasing department negotiates, records, and maintains the contracts.
The contracts are distributed to the local purchasing systems, where a copy of the main contract with a reference to the original is saved.
The release orders are entered in the local purchasing systems. The release order information is updated locally and sent to the main system.
The release order statistics for all the purchasing systems are updated in the main system.
BLAORD / BLAORD03
BLAOCH / BLAORD03
BLAREL / BLAREL02
Scenarios that must be taken into account:
Purchasing Information System
Financial Accounting
Accumulated exchange of information structures
In contrast to the transaction-specific data exchange at single document level, this scenario allows you to exchange summarized data in the information structures directly between the systems. In the process, the information structures are updated in the local systems as usual, and periodically sent to the main system via ALE. A delta data supply is generated by comparing the current dataset with the dataset from the last successful export. The participating systems must use the identical structure for all the information objects to exchange (same name, same periodicity, same characteristics, same key figures).
Because the structure of the information structures to exchange can be determined by the customer, no fixed message type exists. Instead, the message type is generated for the information structure to distribute, based on IDoc type SOPGEN01 .
Scenarios that must be taken into account:
Rough-cut capacity planning
Purchasing Information System
Sales Information System
Sales planning and rough-cut capacity planning
This scenario is used to distribute centrally calculated production or sales figures to several local R/3 Systems. The scenario also supports reverse transmission of the planning data that was adjusted in the local systems back to the main system. This scenario is one concrete example of the generally available function "Accumulated exchange of information structures"
Because the structure of the information structures to exchange can be determined by the customer, no fixed message type exists. Instead, the message type is generated for the information structure to distribute, based on IDoc type SOPGEN01 .
Scenarios that must be taken into account:
Accumulated exchange of information structures
Cross-system planning situation
You can use this business process when you have maintained a material in several systems and you want to perform a cross-system analysis of the requirement/stock situation for this material.
The planning situation is read synchronously
Sales Information System
In this scenario, sales data (delivery note, sales order, billing document) is passed on from local sales systems to a central Sales Information System. The info structures in this main system are updated based on this data. Because single documents are sent in this scenario, the info structures and update rules may differ between the involved systems.
SISCSO / SISCSO01
SISINV / SISINV01
SISDEL / SISDEL01
Scenarios that must be taken into account:
Accumulated exchange of information structures
Purchasing Information System
In this scenario, the following purchasing data is sent from local purchasing systems to a central Purchasing Information System:
Request for quotation
Purchase order/contract/scheduling agreement
Goods receipt
Incoming invoice
The info structures in this main system are updated based on this data. Because single documents are sent in this scenario, the info structures and update rules may differ between the involved systems.
EKSEKS / EKSEKS01
Scenarios that must be taken into account:
Accumulated exchange of information structures
Inventory Controlling
Stock movements are reported by local inventory management to the main Inventory Controlling system, where they trigger updates to the information structures.
INVCON / INVCON01
Scenarios that must be taken into account:
Accumulated exchange of information structures
Decentralized Warehouse Management System (WMS)
This scenario involves two systems: the ERP (Enterprise Resource Planning) system, which handles functions like inventory management, purchasing, sales, and shipping, and the WMS (Warehouse Management System), which takes care of the warehouse management functions.
Inbound and outbound deliveries are replicated in the WMS by the ERP system. Goods receipts and issues are posted in the WMS with reference to the replicated inbound and outbound deliveries. The goods receipt and goods issue postings for the inbound and outbound deliveries in the WMS generate inbound/outbound delivery confirmations that are sent to the ERP system, which then posts the stocks of the moved quantities.
As a result, stock changes resulting from the physical goods receipts and goods issues are posted in the WMS first and then in the ERP system. These messages cause stock changes in inventory management in the ERP system. This means the physical stock placement/removal takes place before the stocks are posted.
DEBMAS / DEBMAS03
MATMAS / MATMAS03
CLFMAS / CLFMAS01
CHRMAS / CHRMAS02 CLSMAS / CLSMAS03
BATMAS / BATMAS01
MBGMCR / MBGMCR01
SHP_OBDLV_SAVE_REPLICA / SHP_OBDLV_SAVE_REPLICA01
SHP_OBDLV_CONFIRM_DECENTRAL / SHP_OBDLV_CONFIRM_DECENTRAL01
SHP_IBDLV_SAVE_REPLICA / SHP_IBDLV_SAVE_REPLICA01
SHP_IBDLV_CONFIRM_DECENTRAL / SHP_IBDLV_CONFIRM_DECENTRAL01
Note: reward points if solution found helpfull
Regards
Chandrakanth.k
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.