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:

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

 

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:

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

 

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.

Sending FI Documents

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.

Master Data to be Distributed

·        G/L accounts

·        Customers

·        Vendors

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