Enable General Ledger Management

General Ledger and Voucher Management

The field indicates whether debit and credit transactions are recorded with signs other than plus or minus.

The field indicates whether internal transactions are used in the system. This way, internal transactions are flagged as such in the general ledger, and you can select internal or external transactions in inquiries and reports. Internal transactions have their own journal number series.

The field indicates whether the values of each transaction are checked during entry.

These are the alternatives:

0: No check

1: Check

2: Same as alternative 1, but no check of currency discrepancies is done.

If you select alternative 1 or 2, every transaction value specified in the basic file and the parameter file are checked to make sure they are correct. This also keeps unbalanced vouchers out of the general ledger. Alternative 1 is recommended.

The field indicates field values applied when a voucher is canceled after it is assigned a voucher number, but before the accounting journal is printed. To avoid a break in the voucher number series, a voucher is created with only one transaction in the amount of 0.00.

The field indicates whether books of account are used to divide sub-ledgers and the general ledger into smaller units. If this alternative is selected, information on the voucher number series is stored with each transaction in each book of account in the general ledger file. This information can then be used for inquiries and sorting purposes.

You can review vouchers per book of account and FAM function used for the entry in 'Book of Account. Display' (CRS408).

The field indicates whether reconciliation is to be used in 'Account. Reconcile Externally' (GLS180) and 'Account. Reconcile Internally' (GLS185), or 'Account. Reconcile Internally' (GLS385).

The field indicates whether cross-division vouchers are used.

The field indicates any third currency used in the financial system and the exchange rate type to be applied.

The field indicates whether, and in which way, exchange rates are managed for calculation of third currency amounts.

These are the alternatives:

0: No. Third currency amounts are calculated by converting amounts from local currency to third currency. The third currency amount on AR and AP transactions is calculated at payment using the current exchange rate. For this alternative, the exchange rate type on the (CRS750/F) panel and the accounting date on the transaction is used to retrieve the third currency rate.

1: Yes, based on local currency. Third currency amounts are calculated by converting amounts from local currency to third currency. The third currency amount on AR and AP transactions is calculated at payment based on the exchange rate on the invoice. If needed, a separate currency gain or loss transaction in third currency is created. A rounding transaction is also created to balance the voucher in third currency, if needed. For this alternative, the exchange rate type and invoice date, payment date, or accounting date on the transaction is used to retrieve the third currency rate.

2: Yes, based on foreign currency. Third currency amounts are calculated by converting amounts from foreign currency to third currency according to the applicable third exchange rate in (CRS058). The third currency amount on AR and AP transactions is calculated at payment based on the exchange rate on the invoice. If needed, a separate currency gain or loss transaction in third currency is created. A rounding transaction is also created to balance the voucher in third currency, if needed. For this alternative, the exchange rate type and invoice date, payment date or accounting date on the transaction is used to retrieve the third currency rate.

Currency gain or loss transactions in third currency for AP are created using accounting event AP91. See Accounting Rules for AP - Accounts Payable.

Currency gain or loss transactions in third currency for AR are created using accounting event AR91. See Accounting Rules for AR - Accounts Receivable.

When selecting alternative 1 or 2, revaluation done in ‘Unrealized Exch Rate Variance. Update’ (GLS160) is performed for both local and third currency. The result of the third currency revaluation is printed as a second row of each printer file, GLS162PF, GLS165PF, and GLS168PF. When updating to the general ledger, the third currency amounts are updated using the regular accounting types and events applicable for (GLS160).

The field indicates whether to prevent balance accumulation on the selected dimension for balance key 8 in the General Ledger balance file. When selected, the dimensions are treated as dimensions without a value in the balance file. By activating this functionality for a dimension where, for example, order number is used, the number of records stored in the balance file will decrease significantly. This in turn improves the performance in programs using balance key 8, for example, (GLS215), (GLS210), (GLS535), (GLS130), (GLS940), (GLS915), (GLS905), and (RGS600).

Note that you cannot select an activated dimension in those programs when balance key 8 is used. Instead, you should select another applicable balance key that holds the information for the dimensions that are prevented for balance key 8. For example, this could be balance key 6.

Example before activating this functionality: See Accounting transactions created in (CAS300)

The number of records created for balance key 8 in the FBAKEY table (keys for the balance file), when transferred to GL, is equal to 6 since one record for each unique accounting string is created.

After activating the functionality for dimensions 6 and 7, the number of records created for balance key 8 in the FBAKEY table is equal to 1 since no accumulation will be done in dimensions 6 and 7.

Since it is common (for various analysis purposes) to include the order number in the accounting string, the number of records in the balance file increases rapidly for a business with large transaction volumes. Therefore, by activating this functionality, unnecessary accumulation will be prevented and the performance will improve in programs using the balance file.

The field indicates whether account addition is used to automatically update specific accounting strings with one or several identities. This is then triggered by other selected accounting identities. All transactions can then be mass-updated so that they are recorded for one accounting identity (such as Project X), as well as automatically recorded for a different accounting identity (such as cost center Y).

The normal use of account addition is to report management and statutory accounts. A French example: The statutory account is in accounting dimension 1. You use the account addition function to automatically post transactions to management accounting identity in accounting dimension 7. The management accounts for all divisions can use dimension 7 and the French legal reports can use dimension 1.

These triggering accounting identities are defined in 'Account Addition Table. Open' (GLS020).

This field indicates whether an accounting identity can exist in more than one accounting structure. If you select this check box, a check is done when connecting an accounting identity to an accounting structure in 'Accounting Structure. Open Lines' (CRS646) to ensure that the same accounting identity does not exist in any other structure within the same From and To period.

Accounting structures are used in balance keys to display information in a structured way in the general ledger balance file.

Tax Management and Legal Reporting

The field indicates the date from which transactions are to be selected for VAT reporting in 'VAT Run. Open' (TXS100).

The 'VAT from date' in (CRS750) is used to provide (TXS100) with a default value. It is not used to prevent transactions from being included in a VAT run. Transactions marked with 9 in the general ledger table (FGLEDG) in the 'VAT reported' field, EGVATR, are not included. This field is updated when you update the VAT declaration voucher from (TXS100).

It is possible to select transactions with an earlier date than the 'VAT from date' because you may want to check that no transactions are back-dated into a previous period. Therefore, the date from (CRS750) is only a default value.

The field indicates the date for the latest VAT run (displayed for information purposes only).

The field indicates whether to check the calculated VAT against the recorded VAT for each VAT code when a voucher is specified, as well as whether to define the maximum allowed deviation.

The field indicates the maximum deviation allowed during the automatic online VAT check.

The field indicates which date to use as a basis for the VAT reporting.

These are the alternatives:

1: Invoice date

2: Accounting date

3: Delivery date (based on accounting date)

4: Delivery date (based on invoice date)

5: Due Date

In many countries, VAT reports to the authorities must be based on invoice date. In others, you are allowed to report VAT based on the accounting date.

In some regions, VAT is based on the date the goods were delivered. If you select delivery date as VAT date type, a delivery date must be specified when recording supplier invoices in 'Supplier Invoice. Record' (APS100/F).

See Manually Enter Supplier Invoice for Payment.

Example:

If you create a VAT report for February a specific year, do you want to include all invoices dated in February or all invoices with an accounting date of February?

1. An invoice dated January 28 might be processed (accounting date) on February 2.

2. An invoice dated February 28 might be processed (accounting date) on March 2.

You might report January's VAT on February 5. Do you include invoice 1? You might report February's VAT on March 5. Do you include invoice 1 and/or 2?

The VAT amount based on the VAT report is posted automatically to a clearing account using accounting event TX01. You can review the difference between the VAT amount based on the invoice date that is posted to this clearing account and the VAT amount based on accounting date on your VAT Payable/Receivable account in 'General Ledger. Display Transactions' (GLS210).

The field indicates how VAT amounts in local currency are managed for invoices in a foreign currency.

These are the alternatives:

0: Not managed. VAT is calculated using the invoice rate.

1: Local VAT amounts are not managed in accounts payable, but are printed on customer invoices as additional information.

2: Local VAT amount is calculated based on the invoice rate but can be overridden at supplier invoice entry in accounts payable. The difference is posted automatically as an exchange rate gain or loss. Not printed on customer invoices.

3: Managed in accounts payable (like alternative 2) and printed on customer invoices.

The field indicates whether cash discount records for EU sales are included as a separate line in the quarterly EU report created in 'EU Quarterly Sales Report. Print' (CRS345).

See Reporting Trade Statistics.

Accounts Receivable Management

The field indicates how the calculation of doubtful customer debts is to be done.

Alternatives:

0: Based on net amount (excluding charges and taxes)

1: Based on gross amount (including VAT).

Doubtful debts are managed in 'Customer Invoice. Process Doubtful' (ARS360) and 'Doubtful Account. Create Allowance' (ARS130). Refer to the documents in the See Also section for details.

This field indicates whether a doubtful debt allowance will update the general ledger.

This field indicates whether VAT and blocked invoices are included when customer credit limits 1–3 and accumulated amounts are updated.

Credit limits and accumulated amounts are displayed in 'Customer Order. Stop' (OIS120/E). Refer to the documents in the See Also section for details.

The field indicates whether offset transactions for interest invoice transactions with the same accounting string are accumulated and totaled. If the field is selected, only one credit transaction with transaction code 11 is created, based on accounting rule AR50-320 (Interest revenues).

The field indicates whether account entries are created when discounted drafts are processed in 'Customer Risk Cancellation. Create' (ARS330). Refer to the documents in the See Also section for details.

0: Not used

1: Payment receipt per document

Commitment Calculation

The field indicates whether the committed value is calculated for monitoring the company's purchase commitments for non-inventory items. The purpose of this function is to help controlling overhead and capital expenditure. Refer to the documents in the See Also section for details.

If this check box is selected, the other fields on the panel must be filled in.

The field indicates the number and version of the empty budget that will contain the committed values.

The field indicates the number and version of the budget that contains any manually specified overspend (optional).

The field indicates the number and version of the control budget with all budgeted expenditures.

The field indicates what happens if a user creates a purchase order (PO) using an accounting string for which there is no budget limit left:

1: The PO is blocked and receives status 15

2: A warning message is displayed

The field indicates against which value the actual expenditures should be compared:

1: Full-year budget

2: Budget up to and including current period

The field indicates the date from which the committed value is calculated:

1: PO order date

2: Date of delivery

The field indicates when the committed value is reduced:

1: At goods receipt in 'Purchase Order. Receive Goods' (PPS300)

2: At invoice matching in accounts payable

The field indicates which accounting dimensions are used for storing the committed value and which are checked during PO order entry. Accounting dimension 1 and at least one another dimension must be selected.