Financial Accounting (FI-GL)

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:

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.

Example of Distributed Financial Accounting

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:

Each of these transactions is assigned a sequence number.

Postings in the Logistics System

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

 

Postings in the Central Financial Accounting

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.

Sending Document Changes

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.

Master Data to be Distributed

Control Data to be Distributed

The control data that has to be distributed for the scenario is described in the ALE Implementation Guide.

Constraints

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