Transaction Scenarios
[ Up ] [ Help Files ] [ Presentations ] [ ALE Contacts ] [ Master Data ] [ Transaction Scenarios ]

Home

Transaction Scenarios available in V3.1H

Financial Accounting

Controlling

Enterprise Controlling

Logistics - General

Sales and Distribution

Materials Management

Production Planning and Control

Human Resources

FI-GL: Financial Accounting- General Ledger

For each company code there is a central R/3 or R/2 System that receives the transaction data from one or more decentral systems. The scenario is designed to allow general ledgers to be linked and to allow a separation to be made between the general ledger and the subsidiary ledger.

FI-SL: Financial Accounting - Special Purpose Ledger

Using ALE you can send the data contents of ledgers from one or more decentral systems to a central system. Data can be transferred either at the same level of detail or in summarized form.
Distribution in the Special Purpose Ledger can also be used if accounting data is required in the central system but is not sent from the local system to the central system in the standard.
In this case you need to define a ledger in the Special Purpose Ledger with the required data fields and then specify that it should be sent to the central system.
The ledger distribution uses the rollup technique in Special Purpose Ledger. You can start a periodic rollup that sends the delta of the ledger data since the last rollup to all interested systems.

Profitability Analysis (CO-PA)

A consequence of the separation between accounting and logistics, and also of the distribution within sales and distribution, is that sales functions are executed in several logistics systems.
This means that distribution within the profitability analysis is also necessary:
The profitability analysis initially runs locally in all the sales systems. This means that local profitability analyses can be made in the sales systems (local contribution margin calculations).
One of the distributed systems can take on central functions for the distributed profitability analysis:

1. The individual results of the distributed profitability analysis can be combined centrally. Thus the overall results of a company can be determined both for the actual data and for the planning data.
   The reporting can be defined differently in the central system and in the decentral systems.
2. The profit planning may be carried out as a concurrent planning activity between the central and decentral organizations in a company.
   Planning is done both centrally and decentrally. The central planning and the decentral planning can be compared and adjusted so that they match.
3. The actual data can be updated centrally. This means that there are assessments from cost centers and direct account assignments from FI documents.
   If necessary, these updates can be sent to the corresponding decentral profitability analysis where they will enter the results.

Distribution from Product Cost Controlling to Profitability Analysis (CO-PC, CO-PA)

If there is a decentral sales and distribution system that performs profitability analysis based on costing data from a remote PPS system, then it is necessary for costing data to be exchanged between the two systems.

Cost center accounting

Cost Center Accounting (CO-OM-CCA) supports two distribution methods:

Reconciliation Ledger

Totals records for CO objects update in the reconciliation ledger. In Controlling, the ledger supplies data for the information system. In cross-company-code transactions, the reconciliation ledger information helps create reconciliation postings between the corresponding company codes in FI.
The reconciliation ledger updates for all CO objects with transaction data found in a system. Distribution method 1 updates cost center entries only in the central system, where method 2 updates only in the cost center home system.
Reconciliation ledger content periodically moves to the central system. If central financial accounting uses a different system than Cost Center Accounting, the reconciliation ledger itself moves to central financial accounting. You can make reconciliation postings only in the company code home system.

Orders \ Projects

You can create CO orders and projects in any system. However, these remain local and allow only local postings, as they cannot be distributed. Order settlement to a cost center moves the costs via ALE to the cost center home system.

Inventory Controlling (LO-LIS, MM-INV)

The scenario supports a central overview of the distributed inventory management (Example: a centralized view of the material stocks).
Logistics data is sent from the decentral inventory management to the central inventory controlling, where it causes the information structures to be updated that SAP has pre-defined for inventory controlling (for example, the characteristic plant and the key figure quantity), but which the customers may modify however they wish.
The central system is frequently only interested in aggregated data (for example, the total stock of a material at a plant rather than a detailed listing for each storage location), and therefore the inventory management data can be summarized.

Profit Center Accounting (EC-PCA)

A distributed environment where multiple R/3 systems are linked together via Application Link Enabling (ALE) makes it possible to send transaction data from Profit Center Accounting (EC-PCA) in several systems to Profit Center Accounting in one central system. Since EC-PCA runs in all the systems, you can analyze the profit centers in any system based on the data posted locally. One of the systems takes on the role of a central system and receives the summary records from the other systems. That way you can analyze all the profit center data in the central system.
Distributed Profit Center Accounting makes it possible to store profit center data even if different business process are depicted in different R/3 systems. For example, if Sales and Production use different systems in your organization, you can post the data to the profit centers in the local system and send the summary records to the central system on a periodic basis.

Distribution Between Accounting and Logistics (FI/CO-LO)

The distribution is based on the distribution mechanisms described above for accounting systems. The applications in the logistics system pass the documents to an accounting system running in the background that then communicates the information.
Links can be set up between R/3 logistics systems and R/2 or R/3 accounting systems only.
The term "logistics system" here means either a sales and distribution system for a company area or a system that provides materials management, production planning or maintenance functions for a plant.

General Distribution of Actual Data in Logistics Controlling (LO-LIS)

ALE provides the following ways of distributing information for the logistics information systems (LIS):

Separate Sales and Shipping (SD-SLS, SD-SHP)

If a customer places an order with a decentral sales center (using either a dialog or EDI), then a sales order is posted in the decentral system. This results in a purchase requisition which is used to automatically create a purchase order for the central shipping in the materials management module in the decentral system.
The vendor, "central shipping", receives the purchase order in the usual way using EDI (an incoming order in SD). After checking the order a confirmation is sent to the decentral sales system and this becomes the basis for an order acknowledgement for the customer.

Sales Information System (SD-IS)

A sales information system gives an overview of data and processes in sales and distribution.
This scenario makes this overview possible in distributed sales and distribution systems also (For example: A central view of orders).
Logistics data is sent from the decentral sales and distribution systems to the central sales information system, where it causes information structures to be updated. The data is usually summarized at this point too.

Interface for Orders to Service Agent in Transportation (SD-TRA-IN)

Electronic exchange of transportation data is continually on the increase. Forwarding agents (shippers) transmit shipping orders and transportation information to their service agents (forwarding agent, ship owner, customs agent), who organise shipments and make sure that they are carried out smoothly. The shipment often takes place along a logistical transportation chain containing several modes of transport and service agents so it is particularly important that the necessary data are ready as soon as possible for all participants in order to guarantee efficiency.
SAP has provided you with both an internal as well as two external interfaces in order to generate these documents for the shipment. The standard EDI interface optimizes the information flow between R/3 and other systems.

The SAP-R/3 Transportation Planning Interface (SD-TRA-IN)

The use of specialized software components is becoming increasingly important as a way to optimize the efficient planning of transportation requirements. The SAP R/3 system offers automated support for external optimizing transportation planning , since the huge number of different possible transportation processing procedures and optimization criteria require software that is exactly adapted to the customer's needs.
To meet these special customer requirements for transportation planning, you can set the SD-TPS interface described below between the SAP R/3 system and one or more specialized, external transportation planning systems (TPS).

Process Flow Overview

During the standard business process in R/3 you create a shipment and are given a selection of deliveries, that are to be planned for the shipment. This process is mainly carried out manually.
When an external system is used for transportation planning, are record of deliveries to be transported is selected in R/3 and is sent to the planning system. There, the deliveries are combined into shipments according to different optimization criteria. The shipments created are sent back via the interface to R/3 and are then used for generating shipment documents in the R/3 system. The master data (e.g. customer address, goods receiving hours) must be the same in both systems for the shipment documents to be posted correctly.
The creation and changing of shipments is carried out in the transportation planning system. All other processing stages for the shipment (printing papers, transportation start etc.) are carried out in the normal way in R/3.

Purchasing: Distributed Contracts (MM-PUR)

This scenario enables contracts to be distributed and release orders to be placed decentrally:

Purchasing Information System (MM-IS-PU)

A purchasing information system gives an overview of data and processes in purchasing.
This scenario makes this overview possible in distributed purchasing systems also (For example: A central view of release orders on contracts).
Logistics data is sent from the decentral purchasing systems to the central purchasing information system, where it causes information structures to be updated.

Stock Transfer Between Distributed Systems (SD, MM)

This scenario is based on the existing EDI interfaces in the SD and MM modules. The messages for purchase orders, order acknowledgements, shipping notifications and invoices are also used for internal data communication between distributed purchasing and sales systems.
The sales system and the purchasing system have a customer - vendor relationship:
The customer called "purchasing" places an order with the vendor called "sales and shipping", who will receive this order as if it were sent using EDI, but without an EDI sub-system (incoming orders in SD). After the order has been checked a confirmation is sent to the purchasing system.

Sales And Operations Planning (SOP)

One important application in which the information structure distribution is used is the SOP covers various activities including the specification of medium term and long term sales volumes and the approximate planning of the production activities that are required to meet these volumes. The enormous amount of data involved means that this is not a highly detailed form of planning with exploded bills of materials and scheduling via routing, but rather a rough estimate of the feasibility of the proposed plans.

Demand Program Reporting (PP-MP-MPS)

The master production scheduling part of the master planning contains some special analysis tools.
The results of the most recent planning run are stored in an MRP list, the planning result. The current stock/requirements situation can also be displayed via the planning situation.
This report allows analyses to be made of individual materials or product groups and across all plants. (You can find more detailed information in the description of the master planning).
The distribution scenario for the demand program reporting allows analyses to be carried out in distributed systems.
Information relating to MRP elements such as production orders, purchase orders, sales orders, reservations, warehouse stocks etc. can be obtained.
The so-called layouts specify exactly which information should be displayed on the screen. The layouts are configured in Customizing.
The scenario can be used in conjunction with the distributed sales and operations planning (SOP) in the business organization, but it can also be used on its own.

External Production Planning Optimization (PP)

Complex forms of production, especially in the areas of hi-tech, repetitive manufacturing, and in the process industry require planning optimization.
This interface belongs to the production planning module with the planning levels: master production scheduling, material requirements planning and shop floor control.
There are three stages to the procedure using the POI interface:

Communication takes place asynchronously using ALE during data download. Data is copied synchronously using RFC (remote function call) during data upload.
Processing can take place in the background.

Transferring Payroll Results to Financial Accounting and Cost Accounting (PA-PAY)

Once the results of a payroll run have been determined, they are transferred to financial accounting and cost accounting. Information that is relevant to financial accounting and cost accounting is selected from the payroll results, summarized, edited, and then posted.
In other words, the transfer function for payroll results has the task of collecting payroll information that is relevant to posting, and then including it in a posting to financial accounting and cost accounting.

Transferring Trip Cost Results to Financial Accounting (PA-TRV)

This scenario is used to prepare trip cost results for posting to financial accounting, and to distribute them to the financial accounting system determined by the customer distribution model.

The trip cost results determined by the trip cost accounting functions within HR Business Trip Management must be prepared for posting to financial accounting. This task is performed by an initial account assignment program for trip costs. It determines the wage type, input tax indicator, and account assignment for each trip expense amount, and then stores them in a sequential file. The sequential file constitutes the basis of further processing within financial accounting.
Communication is only possible between one R/3 System (at least release 3.1G) and another R/3 System (at least release 3.1G).

Transferring Personnel Cost Planning Results to Controlling (CO)

Confirmations are entered in the logistics system in order to document the progress made by an order. They include data that is relevant to payroll accounting. This data must be transferred from the logistics system so that you can use it within the HR system.
Confirmations from production planning (PP) are posted as time tickets to incentive wages. Confirmations from the project system (PS) and plant maintenance (PM) are posted as attendances to time management.
Communication is supported between R/3 Systems (at least release 3.1G).

Transferring Logistics Confirmations to HR (PA)

Please ADD any comments to our Guest book, otherwise READ through it if you wish...

This Web Site was created by Kevin Wilson  and Johan Delport

Last update: Tuesday, October 27, 1998