BAPIs for Data Transfer to Accounting
IDoc Interfaces for Data Transfer to the RW Interface
IDoc Interface: Inventory Management to Accounting
IDoc Interface: Billing to Accounting
IDoc Interface: Invoice Receipt to Accounting
Displaying IDoc Type and Segment Documentation
See also:
Use
The RW interface (RWIN) is the central interface for transferring postings from other application components in the SAP R/3 System to Accounting. The RW interface controls updates of actual data in Accounting and carries out checks from the Accounting standpoint.
Actual data relevant to Accounting from other SAP R/3 application components first transfers to the RW interface. The interface then sends the data to the appropriate Accounting application component (such as Asset Management, Financial Accounting, Cost Center Accounting, Profit Center Accounting, Profitability Analysis, and so on).
Billing data from the Sales and Distribution (SD) application component transfers to the RW interface. The interface then creates the relevant Accounting documents (CO document, FI document, and so on).
Beginning with Release 4.0A, you can use Business Application Programming Interfaces (BAPIs) to transfer postings from other application components to Accounting. A BAPI is a standard interface that facilitates the integration of the SAP R/3 System with the processes and data of other business application systems.
For more information about BAPIs, see the R/3 Library BAPI Introduction and Overview documentation (under Cross Application ® BAPI Introduction).
Features
The BAPIs transfer actual data to Accounting via the RW interface. You can use the following methods (BAPIs) to transfer data from specific business transactions to Accounting:
AccountingGoodsMovement.Post
Goods movements result from transactions in the Production (PP) and Sales and Distribution (SD) application components, or from inventory postings. In Logistics, they lead to adjustments in warehouse stock in the Inventory Management (MM-IM) application component. This also results in a posting to Accounting. Therefore, Accounting receives the corresponding data from Logistics.
Consumption of raw materials results in an inventory change posted to Inventory Management. The posting also transfers to Accounting.
The above check method checks whether the accounting-relevant data of the goods movement can be posted in Accounting.
The above post method posts the accounting-relevant data of the goods movement in Accounting.
AccountingBilling.Post
Billing transactions in the Sales and Distribution (SD) application component result in billing data being sent to Accounting.
Goods sold on credit result in revenues, which are posted to billing and then transferred to Accounting.
The above check method checks whether the accounting-relevant data of the billing can be posted in Accounting.
The above post method posts the accounting-relevant data of the billing in Accounting.
Posted revenues and sales deductions update to the Profitability Analysis (CO-PA) application component.
AccountingInvoiceReceipt.Post
The SAP R/3 Accounting components can accept data from invoice receipts posted in logistic systems.
Raw materials are sold on credit and the invoice receipt is posted in a logistic system. The RW interface transfers the relevant data to the Accounting application components.
The above check method checks whether the accounting-relevant data of the invoice receipt can be posted in Accounting.
The above post method posts the accounting-relevant data of the invoice receipt in Accounting.
AccountingPurchaseRequisition.Post
A purchase requisition created in Logistics represents a formal request to Purchasing to supply a specific quantity of material or perform a specific service at a specific date.
The expected costs from the purchase requisition have to be transferred to Accounting as purchase requisition commitments.
The purchase requisition commitments can update to the following components in Accounting:
The above check method checks whether the accounting-relevant data of the purchase requisition can be posted in Accounting.
The above post method posts the accounting-relevant data of the purchase requisition in Accounting.
AccountingPurchaseOrder.Post
A purchase order created in Logistics represents a formal request from a purchasing organization to a vendor to supply a specific quantity of material or perform a specific service at a specific date.
When a purchase order is made for a material that is consumed immediately (that is, the material is not taken into stock), the expected costs have to be transferred to Accounting as purchase order commitments.
The purchase order commitments can update to the following components in Accounting:
The above check method checks whether the accounting-relevant data of the purchase order can be posted in Accounting.
The above post method posts the accounting-relevant data of the purchase order in Accounting.
AccountingEmployeeExpenses.Post
G/L account postings made in payroll and trip costs accounting update to Accounting. Examples of such G/L account postings include:
In this scenario, Accounting does not use accounts receivable or accounts payable accounting.
The above check method checks whether the G/L account postings made in payroll and trip costs accounting can be posted in Accounting.
The above post method posts the G/L account postings made in payroll and trip costs accounting in Accounting.
AccountingEmployeeReceivables.Post
Accounts receivable postings made in payroll accounting update to Accounting. Examples of such postings include:
The above check method checks whether the accounts receivable postings made in payroll accounting can be posted in Accounting.
The above post method posts the accounts receivable postings made in payroll accounting in Accounting. The general ledger is also updated.
AccountingEmployeePayables.Post
Accounts payable postings made in payroll and trip costs accounting update to Accounting. Examples of such postings include:
The above check method checks whether the accounts payable postings made in payroll and trip costs accounting can be posted in Accounting.
The above post method posts the accounts payable postings made in payroll and trip costs accounting in Accounting. The general ledger is also updated
RW Interface in the SAP R/3 System
The RW interface (RWIN) is the central interface for transferring postings from other application components in the SAP R/3 System to Accounting. The RW interface controls updates of actual data in Accounting and carries out checks from the Accounting standpoint.
Actual data relevant to Accounting from other SAP R/3 application components first transfers to the RW interface. The interface then sends the data to the appropriate Accounting application component (such as Asset Management, Financial Accounting, Cost Center Accounting, Profit Center Accounting, Profitability Analysis, and so on).
Billing data from the Sales and Distribution (SD) application component transfers to the RW interface. The interface creates the relevant Accounting documents (CO document, FI document, and so on).
IDoc Interfaces to Other SAP R/3 Systems
If you use distributed systems (Application Link Enabling = ALE), the RW interface takes all actual data relevant to Accounting from other SAP R/3 Systems, but not data from the Accounting application components of the other SAP R/3 Systems.
Billing data from the Sales and Distribution (SD) application component in another SAP R/3 System transfers to the RW interface.
IDoc Interfaces to External Systems
The RW interface uses an intermediate document (IDoc) interface, which supports transfers of business transaction-based data from external systems to Accounting application components in the SAP R/3 System.
The IDoc interface for the RW interface can transfer data from the following business transactions:
Billing data can update to the Profitability Analysis (CO-PA) application component.
The IDoc interface fulfills the Open Application Group (OAG) communication structure for the following Business Object Documents (BODs):
Communication between logistics and accounting systems
Transfer of a billing document from an external system. Along with billing information, the IDoc includes segments with characteristics and value fields for Profitability Analysis.
Transfer of an invoice receipt from an external system or transfer of an invoice receipt to an external system
Confirmation of the successful processing of a received Business Object Document or sending of error messages
The IDocs for the business transactions can be provided with data through the BODs.
The data, once prepared for the RW interface, generally results in general ledger (G/L) postings and postings in the subsidiary ledgers for customers and vendors in the Financial Accounting (FI) application component. The integration of the SAP R/3 System ensures that other Accounting components have access to this data.
The IDoc serves as the source document for all other documents created in the SAP R/3 System. The connection between the IDoc and the follow-on documents is the document number in the external system or in the other, distributed, SAP R/3 System. You can also display the IDoc from the line item display.
Data Transfer to the RW Interface
The following graphic illustrates the data transfer to the RW interface in the SAP R/3 System.
Outbound System
The outbound system (either an external system or another SAP R/3 System) writes documents on the basis of business transactions made. The data transfers to the IDoc interface of the outbound system, whereupon the outbound IDoc moves to the BOD structure.
Inbound System
The inbound system (an SAP R/3 System) also possesses an IDoc interface. Inbound IDocs are provided with data through the BODs.
The following table shows the IDocs and message types that exist in the SAP R/3 System.
Business transaction | IDoc | Message type |
Goods movement | ACPJOU01 | ACPJMM |
Billing | ACLREC01 | ACLREC |
Invoice receipt | ACLPAY01 | ACLPAY |
The individual business transactions have the following check modules, which verify the corresponding coding block. These check modules belong to function group ACC3.
Business transaction | Check module |
Goods movement | ACC_CODINGBLOCK_CHECK_PJMM |
Billing | ACC_CODINGBLOCK_CHECK_LREC |
Invoice receipt | ACC_CODINGBLOCK_CHECK_LPAY |
An IDoc contains the mandatory and optional fields for the BODs along with SAP-specific fields, which are all optional fields. If, during data transfer via the IDoc interface, only mandatory fields are filled, the SAP R/3 System functions cannot be used to their maximum capacity.
The data is transferred to one of the following function modules (FM) according to the business transaction:
The function modules prepare the data for the RW interface and create the appropriate RW document. When preparing the IDocs, the function modules also check whether all mandatory fields are filled and convert ISO-normed units of measure, currencies, and currency units, as well as other fields, into SAP standard fields.
The RW interface function modules include customer functions for modifying a line before it is included in the RW document (for example, to insert additional data).
If no errors occur when the function modules process the data, it is transferred to the RW interface for further processing.
Errors during data processing in the function module result in status messages documented by the IDocs and their inclusion in an error log. The outbound system can receive a response IDoc (a confirm) informing of error messages or of the successful completion of the IDoc processing. The response IDoc transfers via the IDoc interface of the SAP R/3 System to the outbound system and can be converted into a BOD.
The following errors can occur during IDoc processing:
Preconditions and Requirements
Synchronisation of the outbound and inbound systems is mandatory; the same account assignment objects must exist in both systems during the data transfer.
In the inbound system, ensure before data transfer that the required account assignment objects exist. During the transfer, the RW interface checks whether the account assignment objects used in the IDoc actually exist.
Limitations in Comparison with an Integrated System
You cannot make real reverse postings, which only use the document number to be reversed. The document number, however, can be given to the inbound system as part of a reverse posting. The number updates to the individual SAP R/3 application components together with the document. The document to be deleted is thereby flagged.
IDoc Structure
For more information about the structure of IDocs and their documentation, proceed as described in Displaying IDoc Type and Segment Documentation.
Goods movements result from transactions in the Production (PP) and Sales and Distribution (SD) application components, or from inventory postings. In Logistics, they lead to adjustments in warehouse stock in the Inventory Management (MM-IM) application component. This also results in a posting to Accounting. Therefore, Accounting receives the corresponding data from Logistics. Consumption of raw materials results in an inventory change posted to Inventory Management. The posting transfers to Accounting. 400000 Raw Material Consumption to 300000 Raw Materials $ 40000 The posting updates to Controlling (CO).
Data Transfer from Inventory Management in an External System
The SAP R/3 Accounting components can accept data from goods movements posted in external logistic systems. The inbound IDoc ACPJOU01 from the RW interface is used for this purpose (refer to IDoc Interfaces for Data Transfer to the RW Interface).
Communication with ALE
If you use distributed systems (Application Link Enabling = ALE), the inbound IDoc for goods movements in Accounting communicates with the outbound IDoc for Inventory Management in the SAP R/3 System.
Data Transfer to Accounting in an External System
To transfer goods movement data from the SAP R/3 System to the Accounting components in an external system, you use outbound IDoc ACPJOU01 for Inventory Management (MM-IM).
Data Transfer to Accounting
Each goods movement in the Logistics components of the SAP R/3 System transfers data to outbound IDoc ACPJOU01, depending on the Customizing settings.
First, function module IDOC-OUTPUT_CHECK conducts general data consistency checks. Then, function module IDOC_OUTPUT_ACPJOU_PROJECT projects the RW document onto an IDoc-specific internal structure and converts quantities and currencies to the ISO standard. Finally, processing branches to function module IDOC_OUTPUT_ACPJOU_POST, where the initial field values of NUMC reset to SPACE and those fields change for which defined conversions exist in the user interface.
A customer function is provided for the IDoc header and items. An IDoc extension fills several segments with additional lines. However, you cannot change the existing data in the IDoc, that is, you cannot modify existing lines.
If errors appear in Accounting during processing, corresponding messages appear and are registered in Logistics. Confirmation of IDoc processing from Accounting is supported by IDoc ACCONF01.
BODs
IDoc ACPJOU01 fulfills the Open Application Group (OAG) communication structure for the Business Object Documents (BODs) Post Journal (goods movement) and Confirm for the communication between the logistics and accounting systems.
Preconditions and Requirements
Synchronisation of the outbound and inbound systems is mandatory; the same account assignment objects must exist in both systems during the data transfer.
The outbound system does not check whether the account assignment objects exist in the inbound system. Before data transfer, you should ensure that the required account assignment objects exist.
Structure of Idoc ACPJOU01
For more information about the structure of ACPJOU01 and its documentation, proceed as described Displaying IDoc Type and Segment Documentation.
Billing transactions in the Sales and Distribution (SD) application component result in billing data being sent to Accounting. Goods sold on credit result in revenues, which are posted to billing and transferred to Accounting. 140000 Customer Receivables to 800000 Revenue $100,000 140000 Customer Receivables to 175000 Output Tax $15,000 889000 Sales Deduction to 140000 Customer Receivables $6000 175000 Output Tax to 140000 Customer Receivables $900 Posted revenues and sales deductions update to the Profitability Analysis (CO-PA) application component.
Data Transfer from Billing in an External System
The SAP R/3 Accounting components can accept data from billing transactions made in external sales and distribution systems. The inbound IDoc ACLREC01 from the RW interface is used for this purpose (refer to IDoc Interfaces for Data Transfer to the RW Interface).
You can update billing data to the Profitability Analysis (CO-PA) application component. For more information, see the IDoc Interface Between an External Billing System and Accounting with Update in Profitability Analysis documentation in the R/3 Library (under Controlling ® Profitablility Analysis ® Actual Postings).
BODs
IDoc ACLREC01 fulfills the Open Application Group (OAG) communication structure for the Business Object Documents (BODs) Load Receivable (billing) and Confirm for the transfer of a billing document from an external system. The inbound IDoc in Accounting can be provided with data through the BODs.
Preconditions and Requirements
Synchronisation of the outbound and inbound systems is mandatory; the same account assignment objects must exist in both systems during the data transfer.
Structure of IDoc ACLREC01
For more information about the structure of ACLREC01 and its documentation, proceed as described in Displaying IDoc Type and Segment Documentation.
Data Transfer from Logistics in an External System
The SAP R/3 Accounting components can accept data from invoice receipts posted in external logistic systems. The inbound IDoc ACLPAY01 from the RW interface is used for this purpose (refer to IDoc Interfaces for Data Transfer to the RW Interface).
Raw materials are sold on credit and the invoice receipt is posted in an external logistic system. The RW interface transfers the accounting-relevant data to the Accounting application components.
400100 Raw Material Purchase to 160000 Vendor Payables $100,000
154000 Input Tax to 160000 Vendor Payables $15,000
Data Transfer to Accounting in an External System
To transfer invoice receipt data from an SAP R/3 Logistics system to an external Accounting system, you use outbound IDoc ACLPAY01.
BODs
IDoc ACLPAY01 fulfills the Open Application Group (OAG) communication structure for the Business Object Documents (BODs) Load Payable (invoice receipt) and Confirm for the transfer of an invoice receipt to an accounting system.
Preconditions and Requirements
Synchronisation of the outbound and inbound systems is mandatory; the same account assignment objects must exist in both systems during the data transfer.
Structure of IDoc ACLPAY01
For more information about the structure of ACLPAY01 and its documentation, proceed as described in Displaying IDoc Type and Segment Documentation.
The description of the IDoc interfaces in this documentation does not include the IDoc segments or the fields making up the segments. This information is found in the SAP R/3 System in the tools for the IDoc documentation.
Procedure
The IDoc Type and EDI Basis screen appears.
The illustration includes:
You can reduce the display to the application view or the technical view using the corresponding functions:
You can print or save any screen display.
For more information about IDoc type documentation, see the R/3 Library under Cross Application ® The IDoc Interface for EDI ® Reference Manual ® Structure, Documentation and Development of IDoc Types.
The central task of G/L accounting is to provide a comprehensive picture for external accounting and accounts. Recording all business transactions (primary postings as well as settlements from internal accounting) in a software system that is fully integrated with all the other operational areas of a company ensures that the accounting data is always complete and accurate. The SAP FI General Ledger has the following features: Essentially, the general ledger serves as a complete record of all business transactions. It is the centralized, up-to-date reference for the rendering of accounts. Actual individual transactions can be checked at any time in realtime processing by displaying the original documents, line items, and transaction figures at various levels such as:
Business transactions are posted to accounts and are managed via accounts. You must create a master record for each account you need. It contains information that controls the entry of business transactions in an account and the processing of data. The G/L accounts record the business transactions in totals form. In the standard system, all business transactions that are posted to G/L accounts are updated in the general ledger. Additionally, you can define further ledgers which are also posted to. For this, you must use the Special Purpose Ledger system. Information on additional ledgers can be found in FI-SL Special Purpose Ledger. The following sections contain basic information on G/L account master data as well as explanations of the settings that you make in Customizing. More detailed information on how to make these settings can be found in the General Ledger Accounting Implementation Guide. You can also find out how to create, display, change, delete, or lock general ledger master data.
The following objects play a central role in the creation and management of master records:
The sample account and the data transfer rules are optional and provide special functions. The following figure gives an overview of these objects.
G/L account master records are distributed to both of the following areas: The chart of accounts can be valid for one or more company codes. It contains information which applies to the master records of the company codes that use this chart of accounts. The company code-specific area contains information which may differ from company code to company code. For example, an account number is specified in the chart of accounts, and the currency in which you can post to the account is set in the company code area. The following figure illustrates this. The information in the chart of accounts controls, among other things, the creation of master records in the company codes. Before creating the company code part of the record, you thus have to first enter the master record in the chart of accounts. The general ledger accounting (FI-GL) component allows you to maintain these areas either separately or together with the following options: The different organizations of the various companies should be taken into account with the different procedures.
Companies which are centrally organized will want to define the chart of accounts for their company codes. The employees in these company codes then create the company code-dependent area for the G/L accounts. The chart of accounts should not, in this case, be maintained by the employees in the company codes. You can prevent this by using authorization assignment. For more information on authorization assignment, see Financial Accounting Global Settings in the Implementation Guide under Maintain Authorizations.
However, you may also want to control the creation of master records in the company codes. In order to define special data centrally, a sample account can be specified in the chart of accounts for every master record. The values contained in it are transferred according to definable rules when creating the master record in the company code. Using the sample account procedure is optional. For more information on sample accounts, see Sample Account.
You can create the master record in one step if not just the chart of accounts, but also the entire master record is to be defined from a central location. In a case like this, you do not authorize the employees in the company codes to maintain the master data.
Companies which are organized locally will have the chart of accounts and the area in the company code created and maintained by the employees in the individual company codes. In this case, you assign authorization for maintaining the master records to the appropriate employees.
The basic element of the master data structure in the general ledger accounting (FI-GL) system is the chart of accounts index. You enter all the charts of accounts that you require in your company in this index.
In the FI system, you can use as many charts of accounts as you require within a client. Company codes may have different requirements for grouping a chart of accounts if company codes are from different business sectors or countries, or have a different structure, company size, or legal structure.
However, several company codes can also use a common chart of accounts if a different grouping of the chart of accounts is not required.
You must allocate one chart of accounts to each company code. You therefore need at least one chart of accounts for your company in the system.
The chart of accounts is shared by financial accounting as well as cost/revenue accounting. The items in a chart of accounts can be both expense or revenue accounts in financial accounting and cost or revenue elements in cost/revenue accounting.
For more information on charts of accounts, see:
Specifications in the Chart of Accounts List
Using Several Charts of Accounts
Translating a Chart of Accounts
Changing the Chart of Accounts ListFirst enter the chart of accounts key and its name in the chart of accounts list. Then make the following specifications for the chart of accounts:
You maintain (that is, create and change) the chart of accounts in what is known as the maintenance language. You display it, however, in the logon language.
You translate the chart of accounts into other languages in order to be able to display the account name in the appropriate logon language when displaying master data and posting. If the chart of accounts has not been translated into the appropriate logon language, the account name appears in the maintenance language.
With a block indicator, you can block a chart of accounts so that G/L account master records cannot be created. This is useful if you create your chart of accounts from a central location and want to prevent accounts from being created in the meantime in the company codes. You can use the block indicator to determine centrally when master records can be created for the chart of accounts.
In the system, you can use account numbers of up to ten characters. If you do not need the entire length, you should specify in the chart of accounts list how many characters your account numbers have. This allows the system to suppress any leading zeros.
The assigned numbers should not contain a mixture of alphanumeric and numeric characters and should all have the same length. This is especially important if you want to order particular accounts hierarchically, such as your bank accounts.
Purely numeric account numbers are padded from the left with zeros by the system:
while alphanumeric account numbers appear left-justified:
1234.100 ® 1234.10000
1131DB ® 1131DB0000
Generally speaking, you only ever need more than one chart of accounts if you work with several company codes. But several charts of accounts are not absolutely necessary: You can also use one chart of accounts if the company codes do not have different requirements for grouping the chart of accounts.
The chart of accounts is shared by financial accounting as well as cost/revenue accounting. The items in a chart of accounts can be both expense or revenue accounts in financial accounting and cost or revenue elements in cost/revenue accounting.
You must set up the accounting system for two company codes which use the same account grouping. In this case, you will create only one chart of accounts and use this chart of accounts in both company codes.
You require several charts of accounts if you work with several company codes that require a different grouping structure of the chart of accounts. This is the case if you work with domestic and foreign company codes, if your company codes belong to different business sectors, or if you structure your charts of accounts differently for other reasons.
You must set up the accounting system for two companies: for a wholesaler and for an industrial enterprise. In Germany, you would use two charts of accounts to do this, since different grouping principles are generally used for these different industries.
The usage of different charts of accounts has no effect on the balance sheet and profit and loss statement. When creating the balance sheet or the profit and loss statement, you can choose whether to balance the company codes which use different charts of accounts together or separately. For more information, refer to FI Closing Operations and Reporting.
In addition to the account number of a G/L account master record, the chart of accounts also contains the account name. You may enter and change this name in the chart of accounts in one language only. This is the maintenance language of the chart of accounts. In the chart of accounts index, you must specify the maintenance language to be used for each chart of accounts. You generally use the language of the corporate group.
You use one chart of accounts for company codes in England and in Germany. You create the chart of accounts in England and choose English as the maintenance language. If you maintain this chart of accounts in Germany, you must maintain it in English.
The account name is displayed both when you post to a G/L account and when you create, display, or change the G/L account master record. The system uses the name from the chart of accounts. If you require the account name in languages other than the maintenance language, you can translate it. When the account is posted to or the master record displayed, the system attempts to display the name in the user's logon language. If no translation is available, it is displayed in the maintenance language.
You must specify the languages into which you want to translate the account name in the chart of accounts index. You can then only translate the chart of accounts into the languages listed in the index.
In our example, you maintain the chart of accounts in English. Since you also use the chart of accounts in Germany, you translate the account name into German. When a German employee posts to one of the accounts, the account name is displayed in German. English is the maintenance language and German is specified as an additional language in the chart of accounts index.
If you want to translate an account name, proceed as follows:
The system displays the initial screen for specifying the G/L account master record.
The system displays the screen for translating account names and the language keys for the languages into which you can translate them.
If you do not translate the long text, the system transfers the short text into the field for the long text.
There are two restrictions to changing the chart of accounts index: Firstly, you can change the language key for your maintenance language. However, you can only enter language keys for the languages into which the chart of accounts has already been translated. For example, the language key "E" for a chart of accounts maintained in English can be replaced by a "D" only if the chart of accounts exists completely in German. Secondly, you can delete an entry from the index if you have deleted or not yet created the chart of accounts.
The chart of accounts lists all the G/L account master records that belong to the chart of accounts. However, the chart of accounts is not just an index of all G/L accounts. In the General Ledger Accounting component (FI-GL), it also contains information on each master record that is not company code-dependent and thus managed centrally. This data identifies the type of account and controls the creating and changing of a master record (account group, sample account).
This information
You must define your account groups outside of the chart of accounts. In the chart of accounts, specify the key under which you have stored these definitions. Then create a sample account and assign it to a G/L account master record: specify the account number of the sample account in the required master record in the chart of accounts.
The purpose of the account group is to simplify the creation of master records and to prevent errors. The account group specifies the screens for entering master records and specifies the number interval from which the account number is selected. Account groups are defined for each chart of accounts.
When you create a master record in the chart of accounts, you must specify an account group. This means that you need at least one account group for your G/L account master records. The general ledger accounting (FI-GL) component is delivered with defined account groups.
If you do not want to use the account group as an entry tool, define an account group whose number interval includes all required numbers and contains the status "optional field" for the field groups. You can also define account groups that use the status definition only for the design of the screens or are supposed to define just the number interval for master records.
Do not forget to maintain the field status. Otherwise, all fields are hidden.
For more information on topics discussed in this section, please refer to:
G/L Account Master Data Entry Screen Layout
Example of G/L Account Master Data Entry Screen Layout
Account Number Assignment
Change to the Account Group
Field Status Definition
Field Status Definitions for Transactions: G/L Account Master DataYou can group G/L account master records by functional area. For example, you can group all bank accounts, postal giro accounts, and cash in the account group FIN. for "liquid funds". The master records within a functional area require the same fields for storing information when entering and processing business transactions.
Using the account group, you specify the fields that are relevant for a group of master records. To preclude the need to give every field a status, fields are combined into groups. The field group Interest calculation, for example, lets you set the status of the fields Interest calculation indicator, Interest cycle, and Last interest calculation key date.
You can assign one of the four following field statuses to all the fields in a field group:
This status should not be used since the fields that are displayed should be ready for input when you create a master record.
You set the field status by clicking on the required field status for each field group. If you do not maintain the field status, the system uses the default status "suppressed".
You cannot set the field status for the fields currency key and field status group. These fields must be contained in the master record of the G/L account. The field status group in the master record is required for layout of the screens needed for posting to the account.
The screen layout definitions have an effect not only when creating but also when changing a master record. When you make changes, the system always uses the current definition.
Since bank accounts, postal giro accounts and cash accounts are never used as reconciliation accounts, the Reconciliation account field is irrelevant to these master records. Therefore, this field can be suppressed for these master records. In addition, you post to these accounts directly so the fields for automatically posted accounts can also be suppressed. Every master record in the account group Liquid funds must be marked as a cash flow account. The system requires this information, for example, to calculate the payment amount from a customer for a payment confirmation. Consequently, this field should be defined as a required field for the master records in this account group.
The following figure shows two initial entry screens for company code-specific data: one containing all fields and one modified for the account group Liquid funds.
Standard charts of accounts are recommended in most countries. These are generally created so that the numbers of the accounts belonging to the same functional area begin with the same digits.
Bank, postal giro and cash account numbers begin with the digit 1 .
You use the account group in the chart of accounts to indicate this grouping principle. In addition to the field status, you can specify a number interval for each account group within which the account number of a master record - and therefore the account - must lie. This prevents typographic errors when you enter master records in the chart of accounts.
In our example for the account group Liquid funds, you would not only suppress certain fields and define others as required fields, you would also specify an interval for the account numbers. If you specify the number interval 100000 to 129999 for this account group, you must select account numbers for the master records from this interval. In our example, you could specify account number 101000 for the account Cash in the chart of accounts. Account number 10100 would be rejected as incorrect since it does not fall within the number interval of the account group Liquid funds.
The number intervals for G/L account master records can overlap. As a result, for master records that you do not want to assign to any special functional area, you can create a separate account group that has a number interval already contained in other number intervals.
You have the option of assigning alphanumeric account numbers. Account numbers can be up to ten characters long. You can reuse numbers from master records that have been deleted. The system ensures that account numbers are uniquely assigned. Always use account numbers of the same length. Using account number of varying lengths is not suitable for representing a hierarchy of accounts. Do not assign numbers that are both alphanumeric and numeric. The system pads purely numeric account numbers with zeroes from the left, and alphanumeric account numbers from the right.
You may have to make changes to the account group if fields do not have the required status. After you have installed the system, you may want to introduce an additional application. You have suppressed the fields relevant to this application in the master records. However, these are now required fields so you define them as such.
You may make the following modifications:
If you enter a different account group in the chart of accounts, it will contain a different field status definition or a different number interval. Please note:
If you change the field status definitions for an account group , these changes take effect when you display or change the master records that were created with this account group. The current definition always applies.
Situations may arise that require the maintenance of all master records using the corresponding account group. This is the case if you change the status of a field group from an optional to a required field or if you insert suppressed fields.
If you suppress fields at a later date, the field contents remain. However, the field is no longer displayed when you maintain the master record. The field contents continue to take effect.
You can change the number interval of an account group at a later date. The system only checks whether the specified account number lies in the number interval of the account group when you enter a master record in the chart of accounts. If you have chosen a number interval that is too small, you can increase it as necessary.
You may only delete an account group from the system if no master record refers to this account group. Otherwise, you cannot display or change the master record.
You have to define field status outside of the master record. Mark the field status you need for each field or field group under a field status group. Then assign the field status group to individual G/L accounts in the G/L account master records. Field status groups are independent of company code, attaching instead to the field status variant. A separate variant exists in each company code for field status groups in the standard system. The variant name is the same as the company code, and each company code is assigned to this variant. You can work with the same field status groups in more than one company code, as outlined below: Proceed as follows: Do not forget to maintain the field status. Otherwise, all fields are hidden.
Example of a field status group
You defined a separate field status group for bank accounts because you always need the same fields for posting to bank accounts. Within this group, the allocation number, text, and value date fields are optional. You have specified that all other fields be suppressed.
The figure below shows the standard screen in which no fields are suppressed, and the screen for posting to a bank account.
Other factors
Besides the field status group in the account master record, your posting key specifications also affect posting. For each posting key, you can decide what status the fields should have when posting with a key. But because there are only two posting keys for posting to G/L accounts in the standard system, you should use the field status groups from accounts in the master record for your screen layouts. The field status definition for posting keys 40 (debit posting to G/L accounts) and 50 (credit posting to G/L accounts) have optional status for each field in the standard system. Do not change this.
Some fields are controlled by other specifications. If you work with business areas, display the field centrally using company code specifications. The component documentation for general ledger accounting (FI-GL) as well as accounts receivable and payable (FI-AP/FI-AR) explains in greater detail when fields can be suppressed or shown independently of a field status group.
Field status groups and reconciliation accounts
You must also enter field status groups in reconciliation accounts. These specifications affect the customer or vendor account during posting. You cannot enter any field status groups in the master records for these accounts.
You can also make the status of a field group dependent on the transaction used to process the master record for the following transaction types: For each transaction, you can specify the field status for the company code-specific data area of the master record.
Link Between Status Specifications and Transaction Specifications
When you create, display, or change a master record, the system links the specifications you made for the account group with those made for the transaction. The fields in a field group take the status with the highest priority.
The status with the highest priority is the suppressed field, followed by display, optional, and required entry fields.
The area of the G/L account master record contained in the chart of accounts is described in the chart of accounts. The following only deals with the area of the master record created in the company codes.
The company code area of the G/L account master record contains the information on a master record that differs from company code to company code. This information controls the entry of accounting documents and the management of accounting data.
You use one chart of accounts for company codes in Germany, Italy, and Austria. You then set the master records in this chart of accounts specifically for the different company codes: you manage the accounts in Germany in German marks, in Italy in Italian lira, and in Austria in Austrian shillings.
For more information on topics discussed in this section, please refer to:
G/L Account Master Data in the Company Code
Account Management: G/L Account Master Data
This section explains the most important specifications you can make in the company code area of a G/L account master record. If you have to enter keys or indicators in a master record field, you can read about these specifications in more detail in a separate chapter. You are always notified of the relevant section. Before you make your specifications, you should read these sections.
Currency
Balances in Local Currency Only
Tax Category
Posting Without Tax Allowed
Reconciliation Account for Account Type
Open Item Management
Line Item Display
Field status group
Further Specifications
For each account, you can specify the currency in which it can be posted. To do this, you enter a currency key in the master record. If you have entered the currency key for local currency, you can post to the account in any currency. If you have entered the currency key for a foreign currency, you can post to the account in this foreign currency only. You have defined the local currency for each company code. This currency is defaulted automatically when you create a G/L account. For each account, the transaction figures are always updated and displayed in local currency
If you enter the currency key for a foreign currency in the master record, the transaction figures and the account balance of an account are managed in both the local currency and the specified foreign currency.
If you have set up a foreign exchange account at a bank, it is a good idea to manage it in your accounts in that currency as well. By doing this, you can compare the transaction figures with the account balance on the bank statement.
This indicator should be set for clearing accounts which are posted to in different currencies, and from which you want to be able to clear items without having to make further difference postings, providing the amounts balance to zero in local currency. Set this indicator for clearing accounts you want to be processed as described below when clearing: You manage a clearing account for goods received and incoming invoices to which you post manually. You post the incoming invoices in an invoice currency and the goods received in all cases in the local currency. Incoming invoice 1000 DEM 1480 USD Goods received 1480 USD Both items can be cleared if the local currency only was taken as a basis for updating the balances. If the indicator is not set, the DEM amount is translated into USD during clearing to determine which equivalent in USD is necessary to clear the 1000 DEM. For an assumed exchange rate of 1.50, 1500 USD is then displayed for the incoming invoice when processing the open items, and 1480 USD for the goods received. In order to clear both items, a difference posting of 20 USD must also be entered and the system automatically creates an additional exchange rate difference posting in the same amount.
In tax accounts, you can specify the type of tax on sales/purchases (input or output tax) that can be posted to the account. In exceptional cases, it is useful to allocate a certain tax code to an account. You enter the tax code in the master record in this case. Only this tax code can be used when posting to this account. If a G/L account is not tax relevant, you may make no specification in this field. For more information on sales tax and other taxes in your system, see the documentation for FI General Topics.
If you select this indicator, no tax code need be entered when posting to this account. If a tax code is entered, it is checked according to the tax category for this account. You use this indicator if taxable and non-taxable postings are to be entered to an account at the same time. In such a case, you normally set up your own tax code to allow for non-taxable transactions. However, this is not possible - for example - for tax entry with jurisdiction code, since no jurisdiction code can be specified for customers abroad. You would then also allow postings without tax codes for the corresponding expense or revenue accounts. This indicator is not needed for invoice verification postings, since the account assignments are generally derived from the purchase order. The indicator is therefore not read by the system for these postings. For items with no tax code, no tax information is created and they are not contained in the tax report lists.
You use this field to indicate G/L accounts as reconciliation accounts. For each subledger account , you must keep at least one reconciliation account in the G/L account area. When you post to an account in the subledger, the system automatically posts to the corresponding reconciliation account.
The "Receivables from goods and services" account is an example of a reconciliation account for customers. Enter a D for customer in the reconciliation account for account type field. Enter a K in this field for vendor.
Using the reconciliation account procedure, it is possible to create a balance sheet and a profit and loss statement at any time, since the amounts that are posted to the subledger accounts are also posted automatically in the general ledger.
During regular reconciliation, you check whether the balance of the reconciliation matches the balance of the corresponding subledger accounts.
You define reconciliation accounts by specifying in the G/L account master record the account type (such as fixed assets, vendor or customer) for which the account is to be used. In this way, the account can only be assigned to accounts in the corresponding subledger. You set the assignment of the subledger account to a reconciliation account in the master record of the subledger account. You cannot post to reconciliation accounts manually.
You have created a reconciliation account "Receivables" for accounts receivable. You must specify the account number of the reconciliation account in the master records of the customer accounts. The system checks whether the named reconciliation account is permitted for the account type "customer".
More information on the reconciliation account can be found in the FI Accounts Receivable and Payable Accounting documentation in the sections on customer master records and vendor master records .
Reconciliation operations are described in FI Closing and Reporting.
You can display all items posted to an account that have not yet been archived in accounts if they are kept using line item display. Not all accounts require line item display. Some cases in which line item display is not necessary are:
