tfgld domains

When starting a session to create financial transactions, manually or by job, the background process is not started after posting of the financial transactions. The background process starts during finalization.

When starting a session to create financial transactions, by job, the background process is not started after posting of the financial transactions. The background process starts during finalization and finalization is postponed until the background process is completed. However, if the process is started manually, the background process is started immediately after the posting of all the financial transactions.

When starting a session to create financial transactions, manually or by job, the background process is started after the posting of all the financial transactions.

Users are authorized to match transactions only.

Users are authorized to (un)approve, process, and reset transactions that they matched or approved themselves, and for which the amounts are within the tolerances set in the Account Matching Authorization Scheme Details (tfgld1154m000) session.

Users are authorized to (un)approve, process, and reset all transactions for which the amounts are within the tolerances set in the Account Matching Authorization Scheme Details (tfgld1154m000) session.

The account is used for transactions relating to the balance sheet items, that is the company's assets and liabilities. The value of the closing balance for a particular year, in relation to this type of account, is equal to the value of the opening balance of the next year for this ledger account.

The account is used for transactions relating to costs and revenues. No balance sheet values are calculated for the ledger accounts in this type of account. The values of these ledger accounts should be closed by the fiscal year.

The account is used for balance sheet accounts that include transactions between different companies controlled by the same holding company. This applies to transactions between companies in the same group and to transactions between companies from different groups.

Accounts of this type are used to print text in a balance sheet. You must define a ledger account in which no transactions can be entered. If you select this ledger account during printing, LN prints the text you have defined for this account in the correct position.

The Profit & Loss accounts are individually cleared against the Retained Earnings account.

Each Profit & Loss account is individually cleared against the related Source of Earnings account. You can use this method to view the composition of the total profit for the year, for example, what percentage of the total profit is from operating profit, extraordinary profit, and so on.

All Profit & Loss accounts are cleared directly against the balancing account that you select in the Finance Company Parameters (tfgld0503m000) session and the total amount on the balancing account is posted to the Retained Earnings account.

The Profit & Loss accounts are individually cleared against the balancing account that you select in the Finance Company Parameters (tfgld0503m000) session. The balancing account is cleared against the Closing Balance account. The non Profit & Loss accounts are also individually cleared against the Closing Balance account.

LN uses the Norwegian 10 check algorithm to verify bank reference numbers. To overrule this default check algorithm, add the < operator at the end of the specified or generated number.

LN uses the Norwegian 11 check algorithm to verify bank reference numbers. To overrule this default check algorithm, add the > operator at the end of the specified or generated number.

LN uses the Finnish check algorithm to verify bank reference numbers. No operator is added at the end of the specified or generated number.

LN uses the Swiss check algorithm to verify bank reference numbers. No operator is added at the end of the specified or generated number.

LN first uses the 10 - Check algorithm and then, if this check fails, the 11 - Check algorithm. Either one of these checks must be successful. No operator is added at the end of the specified or generated number.

LN does not verify bank reference numbers. The - operator is added at the end of the specified or generated number. You can use this option for bank reference numbers that cannot be checked with the available check algorithms.

The bank reference number functionality is not available.

LN uses the Swiss check algorithm to verify bank reference numbers. You can use this option if the Used for QR-billing check box is selected and the International Bank Account Number is specified.

LN uses the Bank Reference Check value defined in the Finance Company Parameters (tfgld0503m000) session.

The batch has been created but does not contain transactions or the transactions are not balances. The batch cannot be finalized.

A user is entering or modifying transactions in the batch. The batch cannot be finalized.

Changes in the transactions are being processed. The batch cannot be finalized.

The batch is error free and ready for finalization.

The batch has been selected for finalization and finalization is in progress.

The batch has been finalized.

The batch and the transactions have been deleted.

Errors occurred during finalization of the batch. The batch cannot be finalized.

The version has not been checked for consistency. The version cannot be made Active.

The version has been checked for consistency and blocking errors were found. The version cannot be made Active.

The version has been checked for consistency and no blocking errors were found. However, inconsistencies were found that resulted in warning messages. You can make the version Active if you wish.

The version has been checked for consistency and no errors or warnings were found. You can make the version Active.

Data is displayed for one company.

Data is displayed for all companies of the financial company group.

Amounts are only stored in the local currency.

Amounts are only stored in the reporting currencies.

Amounts are stored in all the home currencies.

The amount is debited to the account.

The amount is credited to the account.

Used, for example, to monthly assign estimated fixed costs such as depreciation costs and fixed asset tax, of which the actual amounts are usually determined semi-annually or annually, to the departments. In the last month of the financial period, the journal transactions for the estimated monthly costs are reversed and the actual monthly costs are assigned pro rata to the departments.

You can use this type to create:

• Regular recurring journal transactions
• Reversal journal transactions
• Periodic reversal journal transactions

Used to create simple recurring cost invoices.

For example, you can use this type to pay fixed and periodical amounts of long term contracts such as the office rent, insurances, and lease payments. Usually, the head office makes the payments and the related costs are periodically transferred to each department or branch.

Used to create recurring sales invoices.

For example, you can use this type for the self-billing of subsidiary costs such as various types of service costs. Usually, the head office pays the costs for the whole organization. The subsidiary companies are billed monthly and at a fixed rate. Recurring journal transactions facilitate the billing of these regular payments.

It is possible to enter a dimension.

It is mandatory to enter a dimension.

For segment reporting, this option is required.

It is not possible to post transactions to a dimension for this ledger account.

The document number has been assigned but the document has not yet been posted to the general ledger. For example, the document number can be reserved for a document generated in Invoicing .

A non-finalized or finalized document with this document number exists.

A non-finalized document with this document number was deleted.

A statutory account, part of the accounting scheme for fiscal annual accounts. A statutory account can have a statutory account or a complementary account as a parent.

A complementary account, part of the accounting scheme for commercial annual accounts. A complementary account must have a complementary account as a parent.

A ledger account used for official accounting purposes according to legal requirements.

A ledger account that you can use for the amounts that are complementary to the amounts in the statutory accounts. For example, you can link a statutory account and a complementary account to a parent account. If you print the Management report based on the parent accounts, on the report ERP LN adds the amounts in the complementary account to the amount in the statutory accounts.

The document is not in use.

A user is busy entering or amending transactions in the document.

In connection with real-time update, the background process is busy with the document.

The currency that is used in the Financial Budgeting System module. You select this currency in the Financial Budgeting Parameters (tffbs0100s000) session.

The local currency as defined in the company details in the Companies (tcemm1170m000) session.

The reporting currency as defined in the company details in the Companies (tcemm1170m000) session.

The reporting currency as defined in the company details in the Companies (tcemm1170m000) session.

The related master data.

Actual data in the Cost Accounting module and the General Ledger modules.

Budget data in the Financial Budgeting System module and the General Ledger module.

Both actual and budgeted data.

Actual, budgeted, and meta data.

The Common Data package.

The Common Data package.

The Common Data package.

The number of periods for which the data is grouped

The year start date and the end date.

Import data from Hyperion.

Export data to Hyperion.

The transactions are updated directly when the debit values entered for a document correspond with the associated credit values, and you start to enter transactions for another transaction.

The transactions are updated during the posting process, which can be started in the Finalization Run Number (tfgld1609m000) session.

One batch is created daily which contains all the transactions of that day.

A number of batches is created daily. One batch is created per transaction type of the integration document types.

A number of batches is created daily. One batch is created per transaction type and integration user group of the user who posts the transactions.

investment

maintenance

asset disposal

The transaction was successfully logged. The financial periods to which the transaction must be posted have been verified. You can view the transaction data in the Integration Transactions (tfgld4582m000) session. You can map and post the transaction.

The transaction was successfully mapped to the integration ledger accounts and dimensions. You can post the transaction. If required, you can remap the transaction with a different mapping.

The transaction was successfully posted in the general ledger. You can no longer change the mapping.

LN could not log the transaction due to an error. Use the Print Integration Transactions Error Log (tfgld4484m000) to list the errors.

LN could not map the transaction due to an error. Use the Print Integration Transactions Error Log (tfgld4484m000) to list the errors.

LN could not post the transaction due to an error. For details, refer to Solve the posting errors. Use the Print Integration Transactions Error Log (tfgld4484m000) to list the errors.

A user whose approval authorization is set to Approve/Process/Reset All Transactions, and for whom no amount restrictions apply.

A user whose approval authorization can be one of the following:

• Match Only
• Approve/Process/Reset Own Transactions
• Approve/Process/Reset All Transactions

LN derives the actuals from the General Ledger module.

LN adds all amounts of the previous year, from period 0 up to and including the last period.

LN posts the receipt transaction without checking the integration transactions of the advance installment.

If the integration transactions for advance installments are not posted, LN displays a warning message. If you acknowledge the message, LN continues to process the receipt transaction.

For automatic processes, Warn User and Block User often have the same result. LN blocks the process.

If the integration transactions for advance installments are not posted, LN blocks the receipt transaction.

The recurring journal definition has been entered but not validated. You can add and change the transaction details and instructions. LN cannot use the recurring journal definition to generate journal transactions.

The recurring journal definition and transaction details have been validated and the required recurring journal instructions have been defined for it. You cannot make changes to the recurring journal definition. LN can generate journal transactions based on the recurring journal definition.

You can set the status to Released if these conditions are met:

• If the Recurring Journal Type is Journal Voucher, the total balance of the transaction details must be zero.
• If the recurring journal type is Purchase Invoice, the total balance of the transaction details must be a negative amount because a credit posting is made to the control account.
• If the recurring journal type is Sales Invoice, the total balance of the transaction details must be a positive amount because a debit posting is made to the control account.
• If the Reversal Type of the instruction is Included for Periodic Reversal, a corresponding Periodic Reversal instruction must be present.
• If the reversal type of the instruction is Periodic Reversal, at least one Included for Periodic Reversal instruction must be present of which the reversal date is the generation date of the Periodic Reversal instruction.

You cannot make changes to the recurring journal definition, and LN cannot use the recurring journal entry definition to generate journal transactions.

For example, you can temporarily set the status to Not Used if you want to check its details.

The status of a newly created cross validation rule.

A rule with status Draft cannot be used yet.

The status of a cross validation rule after it was released.

A rule with this status can be used to determine the validity of entered ledger account / dimension combinations.

The status of a cross validation rule can only be changed from Draft to Active if all mandatory fields were entered and rule elements were defined.

The status of a cross validation rule after it has been closed.

A rule with status Closed can no longer be used.

When you generate the journal transactions, LN changes Debit into Credit and Credit into Debit.

The journal transactions are marked for periodic reversal. A recurring journal definition that includes this type of instructions must contain a Periodic Reversal instruction. The Reversal Date must match the generation date of the periodic reversal.

The generated journal transactions reverse the recurring journal transactions of the same recurring journal definition of which the reversal date matches the periodic reversal schedule line's generation date. A recurring journal definition that includes this type of instructions must contain an Included for Periodic Reversal instruction.

The recurring journal transactions are not reversed and do not reverse other journal transactions.

The transaction has not yet been posted to the general ledger.

LN could not post the transaction due to an error. Use the Print Integration Transactions Error Log (tfgld4484m000) to list the errors.

The transaction was successfully posted in the general ledger.

The data is sorted based on the ledger account code order.

The data is sorted based on the order specified for each ledger account in the Print Sequence field of the Chart of Accounts (tfgld0508m000) session.

The data is sorted by parent/child relation.

The selected reports are sorted by Legal Ledger Account assigned to the Ledger Account in the Chart of Accounts (tfgld0508m000) session. If Legal Ledger Account are not assigned, the Ledger Account are not printed.

Indicates that one or more modules status is 'Open'.

Indicates that one or more modules status is 'Closed' and no module status is 'Open'.

Indicates that all the modules status is 'Finally Closed'.

The report is sorted by dimension type, dimension code.

The report is sorted by dimension type, print sequence, dimension code.

The report is sorted by parent/child relation.

The journal book section has been officially reported on legal paper.

LN is generating the report.

The journal book sections and the summary journal book have been officially reported on legal paper. You can archive and/or delete journal book sections that have this status

The journal book section has been deleted in the Archive/Delete Journal Books (tfgld5212m000) session.

No reports have been printed of the journal book section.

A draft version of the journal book section has been printed.

The journal book section has been archived in the Archive/Delete Journal Books (tfgld5212m000) session.

Deferred tax or suspended VAT applies to the transaction. The VAT Type of the tax code is On Payments.

The transaction document was deleted. To preserve consecutive document numbering on the report, deleted documents must be included.

The Tax Code field of the transaction is left blank.

None of the previous values apply.

When taxonomy is defined for the first time, the status is set to “Draft”.

Indicates that the blocking error occurred during validation. The errors can be viewed in the Errors and Warnings per Taxonomy session.

Indicate that the taxonomy has cleared the mandatory checks and ready to be activated. Warning messages can exists and need to be accepted, before activation of the Taxonomy.

Indicate that the taxonomy can be used for reporting, imported to FST and published using a BOD. The taxonomy now cannot be updated or deleted. If changes are required, a new version (copy) of the taxonomy is created.

Indicates that the taxonomy cannot be used.

Cash Transactions created with type of transaction as Supplier Payment within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Bank Transaction. Reconciled payments on purchase invoices are also considered as supplier payments.

Cash Transactions created with type of transaction as Customer Receipt within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Bank Transaction. Reconciled receipts on sales invoices are also considered as customer receipts.

Cash Transactions created with type of transaction as Unallocated Payment within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Bank Transaction. Reconciled unallocated payments are also considered as unallocated payments.

Cash Transactions created with type of transaction as Unallocated Receipt within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Bank Transaction. Reconciled unallocated receipts are also considered as unallocated receipts.

Cash Transactions created with type of transaction as Advance Payment within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Bank Transaction. Reconciled advance payments and standing orders of the type Advance Payment are also considered as advance payments.

Cash Transactions created with type of transaction as Advance Receipt within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Bank Transaction. Reconciled advance receipts are also considered as advance receipts.

Cash Transactions created with type of transaction as Cash Journal within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Bank Transaction. Reconciled standalone payments, and standing orders of the type Costs are also considered as Cash Journal Transactions.

Non-Cash Transactions created on a Cash Account within a transaction type that does not have Transaction Category as Cash and Transaction Subcategory as Bank Transaction.

Cash Transactions created by assigning unallocated or advance payments to purchase invoices within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Assign Advance/Unallocated Payment

Cash Transactions created by assigning unallocated or advance receipts to sales invoices within a transaction type that does not have Transaction Category as Cash and Transaction Subcategory as Assign Advance/Unallocated Receipt.

Intercompany transactions that are a result from intercompany payments/receipts and that are generated when:

• A Supplier payment is paid from company A for an invoice from company B.
• A Customer receipt is received in company A for an invoice from company B.
• An Unallocated or advance payment is paid from company A on behalf of company B.
• An Unallocated or advance receipt is received in company A which is meant for company B.
• A Cash journal is created where the receipt or payment is done in company A and the related journal transaction is created for company B.

These transactions are created within a transaction type that has Transaction Category as Cash and Transaction Subcategory as Bank Transaction.

Realized profits/losses. For example, when the exchange-rate difference is in effect at the moment a purchase or sales invoice is paid. In addition, profits/losses are calculated, if the Calculate Currency Differences (tfgld5201m000) session is executed.

Expected profits/losses,for example, when you expect that the exchange rate at the time when the invoice is paid will differ from the exchange rate used on the invoice. In this case the selected ledger account is an interim account which will be reversed when the invoice is actually paid.

Tax lines have been selected for the tax declaration.

You have verified that the tax declaration contains the correct selection of tax lines.

Automatic transfer of the XML tax declaration file failed.

Automatic transfer of the XML tax declaration file was completed.

The collection office has provisionally accepted the tax declaration.

The payment order has been sent to the bank.

The tax declaration has been manually paid.

The tax declaration has been paid.

The tax declaration header exists.

Percentages of the transaction amount are posted to specific ledger accounts and dimensions. The sum of the percentages must be 100.

Fixed amounts are posted to specific ledger accounts and dimensions. The sum of the amounts must be equal to the transaction amount.

Proportional parts of the transaction amount are posted to specific ledger accounts and dimensions.

Financial transactions of the type Purchase are printed in the tax analysis.

Financial transactions of the type Sales are printed in the tax analysis.

All financial transactions subject to tax will be printed in the tax analysis.

The company claims the paid output tax paid for bad debts, or adjustments to Input Tax are made if the amount specified on the supplier invoice is not paid.

Bad debt relief is claimed, and a company pays (part of) an invoice to the supplier.

The invoice is paid and the discount is deducted, based on country specific regulations.

An invoice is paid, and a certain amount is written off as a payment difference.

The invoice is paid, and the late payment surcharge amount is deducted from the payment.

Tax on purchase transactions. Tax on these transactions can be claimed.

Tax on sales transactions. Tax on these transactions is payable.