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.
Reference Model for Distributed Financial Accounting
You can use either of the following options for transferring account information from the local financial accounting to the central R/3 System:
· Every line item that is booked to the decentral account gets sent to the central system separately.
· The delta for the transaction data is sent to the central system periodically (usually at the end of each accounting period), using the rollup technique from the Special Purpose Ledger module.
There is an “external accounting” flag in the G/L account master record that determines which of these two options should be used. If the flag is set, then individual line items are sent. If the flag is not set, then the transaction data deltas are sent. For a subsidiary ledger the method used is determined by the flag belonging to the corresponding reconciliation account.
This allows the communication between systems to be kept to a minimum, since most accounts are not sent as line items. On the other hand, it also guarantees that the transaction data for all the general ledger accounts are sent to the central system.
A table-controlled conversion can be performed on the G/L accounts of the decentral system to the G/L accounts on the central general ledger before the data is sent. This is useful if the charts of accounts in the central system are different from those in the decentral system.
A clearing account is kept for each decentral system in the central financial accounting. This is needed because a decentral system does not send complete documents but only selected document lines that may show a balance. In that case the balance from the input document lines is offset on the clearing account to obtain a cleared document. The clearing account has to be cleared at the period-end, if all the data from the distributed system has been transferred.
In order to illustrate the processes in a distributed financial accounting scenario, we will now look at the interaction between a decentral logistics system (in this example, purchasing) and a central financial accounting system.
The Distribution Logistics - Financial Accounting
As mentioned above, this coupling is performed in the distribution for financial accounting.
The assumption is made that the charts of accounts in the two systems are the same. The reconciliation account for the vendors is the only one in the logistics system for which the “external accounting” flag is set. This causes every open item that is posted to a vendor to be sent to the central system. Payment is made here.
The following transactions will be looked at:
· Receipt of materials from an external vendor
· Receipt of the invoice for this transaction
· Goods issue for consumption
· Payment to the vendor
Each of these transactions is assigned a sequence number.
A goods receipt with a value of $1,000 is posted (1). This is followed by the receipt of an invoice for $1,150 including sales tax (2). Finally there are goods issues (outward movements of goods) in the logistics system as consumption (4-6).
Goods Receipt
Activity |
Debit account |
Debit amount |
|
Credit account |
Credit amount |
(1) |
Stock |
$1000 |
to |
Goods/invoice rcvd. (clearing account) |
$10000 |
Invoice Receipt
Transaction |
Debit account |
Debit amount |
|
Credit account |
Credit amount |
(2) |
Sales tax |
$150 |
to |
Vendor |
$1150 |
|
Goods/invoice rcvd. |
$1000 |
|
|
|
Goods Issues
Transaction |
Debit account |
Debit amount |
|
Credit account |
Credit amount |
(4) |
Consumption |
$100 |
to |
Stock |
$100 |
(5) |
Consumption |
$200 |
to |
Stock |
$200 |
(6) |
Consumption |
$300 |
to |
Stock |
$300 |
The open item for the vendor is copied to the central financial accounting system, the payment is made there and the transaction data is copied there from the decentral R/3 System (3).
Transaction |
Debit account |
Debit amount |
|
Credit account |
Credit amount |
(3) |
Clearing account |
$1150 |
to |
Vendor |
$1150 |
The transaction data is also periodically copied to the central R/3 System (7):
Transaction |
Debit account |
Debit amount |
|
Credit account |
Credit amount |
(7) |
Goods/invoice rcvd. |
Stock |
to |
Goods/invoice rcvd. |
$1000 |
|
Sales tax |
$150 |
|
Stock |
$600 |
|
Stock |
$1000 |
|
Clearing account |
$1150 |
|
Consumption |
$600 |
|
|
|
A payment is made to the bank:
(8) |
Vendor |
$1150 |
to |
Bank |
$1150 |
Logistics R/3 System |
Central Financial Accounting |
|||
|
|
|||
Goods/invoice rcvd. |
|
|
Goods/invoice rcvd. |
|
(2) $1000 |
(1) $1000 |
|
(7) 1000 |
(7) $1000 |
Sales tax |
|
|
Sales tax |
|
(2) 150 |
|
|
(7) $150 |
|
Stock |
|
|
Stock |
|
(1) $1000 |
(4) $100 |
|
(7) $1000 |
(7) $600 |
|
(5) $200 |
|
|
|
|
(6) $300 |
|
|
|
Expense |
|
|
Consumption |
|
(4) $100 |
|
|
(7) $600 |
|
(5) $200 |
|
|
|
|
(6) $300 |
|
|
|
|
Vendor |
|
|
Vendor |
|
|
(2) $1150 |
|
(8) $1150 |
(3) $1150 |
|
|
|
Bank |
|
|
|
|
|
(8) $1150 |
|
|
|
Clearing |
Logist. System 1 |
|
|
|
(3) $1150 |
(7) $1150 |
Currently no transaction data is sent from the central system to the decentral system, and in particular no information is sent concerning the outgoing payment to the vendor that was posted in the central system.
Because the open item for the vendor was sent to the central financial accounting, it is marked as cleared in the decentral system. This ensures that payment can be made only from the central system and no double payment (i.e. central and decentral) can be made. The “open” item in the decentral system is reorganized as part of the FI document reorganization run.
No confirmation of the payment information is sent from the central system to the decentral system.
How the decentral system handles document changes mainly depends on whether the document line was sent as a line item or is relevant to rollup. There are no restrictions on rollup-relevant document lines since this kind of document line is not known to the central system in detail. These lines can be changed and no messages are sent.
Document lines that were sent as line items can be changed later using certain Logistics transactions only. Changes can no longer be made in the decentral financial accounting, since the central system has the accounting responsibility for these document lines. In the Logistics system changes can only be made from the invoice verification (purchasing) and the billing (sales). These changes are sent to the central R/3 System using the FIDCCH (FInancial DoCument CHange) message type.
The invoice verification posts an incoming invoice, for which there has not yet been a goods receipt. A logistical payment block is applied to the open item for the vendor in the associated FI document and the item is sent to the central system with the FIDCMT message. After the goods arrive, the purchasing department releases the invoice by removing the logistical payment block in the document line for the vendor. This change is sent to the central system using the FIDCCH message. Payment is then made from there through the payment program.
In a similar way, changes to the dunning block or to the reference document number are sent from sales to the central system using the FIDCCH message.
There are two ways of sending general ledger data:
· Distributing complete FI documents
· Distributing individual line items of an FI document
For more information, including possible solutions and limitations, see SAP note 114814.
· G/L accounts
· Customers
· Vendors
The control data that has to be distributed for the scenario is described in the ALE Implementation Guide.
Central cash management and forecast are not supported.
No group cash concentration, i.e. decentral payment proposals are sent to the central system and are collected together and paid there.
In central R/2 real-time financial accounting, tax accounts cannot be copied using line items.
Cross-system advance returns for sales and purchase tax are not supported.
Cross-system credit management is not supported.
Transaction data flows from the decentral R/3 System to the central R/3 System only and never in the other direction.
Special G/L transactions (for example, down payments on purchase orders, for example) are not supported in a distributed environment.
Only relevant data is sent to the G/L. Account. Assignments to CO objects, for example, to a cost center, are not included in the IDoc. The message type CODCMT is used to send CO relevant data (see CO scenario).