General Ledger

You can independently define dimensions and use them to prepare analyses of ledger account transactions and balances. You can use up to 12 dimension types. You can define a name and an entire structure of dimension codes for each of these dimension types. There is no relationship between the dimension types. Dimension types and codes can be derived from logistic code tables.

Cross Validation Rules (CVR) functionality allows you to indicate which combinations of GL accounts and dimensional values are valid. Cross validation rules help to reduce data entry errors, enforce segregation of duties, and improve reporting accuracy.

Three financial period types exist: Fiscal, Reporting, and Tax.

You enter transactions based on transaction types. The transaction types are grouped by transaction category.

Transaction entry default values set authorizations and provide quick access to transactions types for each user.

To distribute a transaction across a number of ledger accounts and dimensions, you can use a transaction template. For each transaction template, you can define one or more transaction template lines to specify the distribution of the main transaction amount across a number of ledger accounts and dimensions.

When a transaction that matches a specified transaction type and ledger account in the master data is finalized, LN generates parallel transaction lines. The amounts will be posted to the specified ledger accounts according to the specified percentages.

You can match credit and debit entries of multiple transactions on the same ledger account with each other. A matching transaction can be generated to post differences that are within the specified tolerances.

A cash flow statement provides information about the history of the cash flow. The statement provides an overview of the sources and uses for cash, and is used to assess the ability of the company to meet its short-term obligations. In some countries, a cash flow statement must be submitted periodically to authorities.

In an integrated ERP system, most of the financial postings result from logistic transactions. For example, a warehouse issue is an operational transaction that requires financial postings. For each transaction that must be reflected in Financials, LN generates an integration transaction.

You can import journal transactions into LN from an outside source.

Recurring journal transactions are journal transactions that LN can generate periodically, based on the transaction details and templates that you set up in the recurring journal master data.

In a multicompany environment, transactions between the logistic companies and between financial companies create the need to balance the accounts through intercompany transactions.

General Ledger transactions can also occur between groups of financial companies that have separate chart of accounts, calendars, and so on, but are affiliated in a multisite structure.

You use the year-end procedure to move the closing balances from one year to the opening balances for the next year. If the books are not final and you require the opening balances for the next year, you can run a provisional year-closing procedure.

The dimensions can be specified manually or populated automatically through Integration transactions. The user can manually specify the dimensions using manual journal voucher. The dimensions can be populated automatically with the segment value of the source transaction (that is the credit side of the integration transaction).

In a number of countries, journal voucher numbers must be consecutive for each month or year. You are not allowed to have gaps between a given number and the next number. The application includes Protocol Codes and Number functionality which has been enhanced to support different formats and numbering methods.

The functionality is extended so that external journal batches can now be modified, based on the Authorized User for External Journals in the Company Parameters (tfgld0503m000) session.

In Italy, when the customer is a public sector company the tax liability shifts to the customer. The tax component paid by customer directly to tax authority must not be included in the receivables. The Vat Book reports must display the sales tax amount, as not payable. The Shifted sales tax must be handled as non-deductible for VAT book & VAT liquidation report. The Accounts receivable created directly from finance must allow shifted tax codes for domestic sales transactions.

The integration transaction can now be printed in the home currency.

The application can uniquely identify and report the VAT corrections. The VAT corrections must be distinguished in the VAT Report.

The legal regulations binding in Poland require that accounting books be periodically printed and/or transferred into another durable storage medium by a company. According to Art. 13.1 of the Accountancy Act, accounting books consist of sets of accounting records and constitute the following