GM-X ERP for Blockchain - The GENERAL LEDGER subsystem

By Nelson Nones

28th September 2018
Amended: 30th March 2024

Introduction

1. Organisational Structure

CHART_OF_ACCOUNTS

EXCHANGE_RATE_TYPE

GL_EXCHANGE_RATE

GL_ACCOUNT

FISCAL_CALENDAR_HEADER

FISCAL_CALENDAR_PERIOD

FUNCTIONAL_UNIT

2. Journal Entries and Account Balances

GL_ACCOUNT_OPENING_BALANCE

JOURNAL_ENTRY_HEADER

JOURNAL_ENTRY_ITEM

JOURNAL_ENTRY_STATUS_TYPE

JOURNAL_ENTRY_STATUS_HIST

GL_ACCOUNT_PERIOD_BALANCE table

Journal Entry Posting logic

Opening and closing fiscal periods

3. Recurring Journal Entries

RECURRING_JE_HEADER

RECURRING_JE_ITEM

4. Standing Journal Entries

STANDING_JE_HEADER

STANDING_JE_ITEM

5. Default Overrides for General Ledger Accounts

FUNC_UNIT_PRICE_COMPONENT

FUNC_UNIT_PROD_CAT

FUNC_UNIT_FEATURE_CAT

FUNC_UNIT_INV_VAR_REASON

FUNC_UNIT_WRK_EFF_PURPOSE

6. Constructing Journal Entries Originating from Subsystems

SUBSYSTEM_JE_TEMPLATE_HEADER

SUBSYSTEM_JE_TEMPLATE_ITEM

7. Subsystem Posting to the General Ledger

Subsystem Journal Entry Templates

is_batch_post Property

is_summary_journal Property

is_approval_required Property

uom_id_statistic Property

8. Invoice Revaluations

Constructing the Account Distribution for Invoice Revaluations

Overview

Traversing the SUBSYSTEM_JE_TEMPLATE table

Determine the account_id from an account_usage value

Debits and Credits for First Side and Contra Side Entries

Accounts Receivable processing

Accounts Payable processing

Constructing journal entries

Construct JOURNAL_ENTRY_HEADER

Construct JOURNAL_ENTRY_ITEM

9. Control Data

Amendment History

Introduction

A general ledger represents the formal ledger for an organisation's financial statements with debit and credit account records validated by a trial balance. The ledger provides a complete record of financial transactions over the life of the organisation. It holds account information that is needed to prepare financial statements and includes accounts for assets, liabilities, owners' equity, revenues and expenses.

General ledgers are used by business entities and other organisations that employ the double-entry bookkeeping method, which means that each financial transaction affects at least two general ledger accounts and each entry has a debit and a credit transaction. Double-entry transactions are posted in two columns, with debit postings on the left and credit entries on the right, and the total of all debit and credit entries must balance.

The balance sheet includes cash and accounts receivable as assets in the balance sheet accounts. The accounting equation or balance sheet formula is stated as Assets - Liabilities = Equity.

After journal entry transactions are posted to the general ledger accounts, a trial balance report listing all the accounts and each account's balance is prepared at least once every year and reviewed by management. In addition, an accountant may perform an independent audit. These examinations may reveal the need to amend the trial balance by posting additional adjusting journal entries. The adjusted trial balance is used to prepare the organisation's financial statements.

Organisational Structure

The PARTY and ORGANISATION tables contain entries for every organisation which is required to be known to the GM-X application. At least one of these organisations is the "client" and it is the one for which the application is being run. This organisation is known as the "functional unit" and can be identified by adding it to the PARTY and ORGANISATION tables using a single party_id. This data provides the following:

• The identity of the internal party in various transactions, such as sales orders and invoices.
• The home currency for all such transactions, which is known as the "functional currency".

It is also possible for a GM-X installation to handle the business for a group of organisations which do business under separate names, possibly using different functional currencies. Those organisations can be added as functional units to the PARTY and ORGANISATION tables. Each of them is identified in those tables by its own party_id.

The GM-X application can maintain separate general ledgers for these organisations. In this case each of those organisations must be added to the FUNCTIONAL_UNIT table using its party_id, in addition to the PARTY and ORGANISATION tables.

A chart of accounts (COA) is an accounting tool that provides a complete list of accounts in a general ledger. An account is a unique record for each type of asset, liability, equity, revenue and expense. The COA lists the identification codes, names and brief descriptions of accounts that an organisation has identified and made available for recording transactions in its general ledger. These establish the level of detail tracked in the general ledger.

A fiscal year (FY) is the time interval that an organisation uses for preparing annual budgets and financial statements. This interval may or may not coincide with a calendar year. The fiscal year may be divided into 12 calendar months ending on the last day of each month or may be divided into 12 periods of four or five weeks each comprising a 52- to 53-week fiscal year, where each period ends on the same day of the week.

The GM-X application allows charts of accounts, fiscal years and periods to be defined separately for each general ledger. Alternatively, when general ledgers are maintained for related functional units, it is often beneficial for each of the related Functional Units to adopt a standard chart of accounts and fiscal calendar. Standardisation makes it possible to compare and consolidate financial statements.

Figure 1 - Functional Unit, Chart of Accounts and Fiscal Calendar

CHART_OF_ACCOUNTS table

This holds the identifier, name and description for each chart of accounts utilised by the various functional units for which a general ledger is maintained in the GM-X application.

It also identifies the accounts, which are held within the GL_ACCOUNT table, where currency translation gains or losses as well as rounding differences are posted when translating financial statements from functional to reporting currency.

Currency translation is the process of converting a foreign entity's functional currency financial statements to the reporting entity's financial statements. The foreign entity's financial statements in the functional currency should use the following exchange rates for translation:

• Assets and Liabilities: Exchange rate between the functional currency and reporting currency at the end of the period.
• Income Statement: Exchange rate on the date that income or an expense was recognised; a weighted average rate during the period is acceptable.
• Shareholder Equity: Historical exchange rate at the date of entry to shareholder equity; the change in retained earnings uses historical exchange rates of each period's income statement.

Foreign currency translation gains and losses are a component of accumulated other comprehensive income.

• Because these are not taxable under United States Internal Revenue Service (IRS) rules, they are recorded on a company's consolidated statements of shareholders' equity and carried over to the consolidated balance sheet under shareholders' equity.
• In other countries, these are recorded on a company's consolidated income statement.

EXCHANGE_RATE_TYPE table

This identifies the various types of exchange rates utilised when translating an entity's results from functional currency to reporting currency.

Here are some examples:

GL_EXCHANGE_RATE table

This holds the exchange rates between functional and reporting currencies that are utilised for currency translation processing.

GL_ACCOUNT table

This holds the list of accounts for each chart of accounts.

Accounts may be grouped on financial statements. For example when each bank account has its own general ledger account, those accounts can be grouped into a 'cash in banks' category which, together with petty cash, cash in banks, funds in transit, marketable securities, commercial paper, Treasury bills and short-term government bonds can be further grouped into the 'cash and cash equivalents' ('CCE') category. In this case there will be two categories, one called 'cash and cash equivalents' and another called 'cash in banks'. By defining the 'cash and cash equivalents' category as the parent of the 'cash in banks' category you are creating a hierarchy of categories. When you create a general ledger account representing a specific bank account you should identify 'cash in banks' as its parent. In this relationship 'cash in banks' is called the senior or parent and each bank account is called the junior or child. You may create categories of your choosing and define hierarchies of your choosing. The categories are known as 'summary accounts' and may contain other summary accounts as well as detail accounts.

If you have defined a hierarchy then you can only post to detail accounts at the bottom of the hierarchy. Using the example above you may post financial transactions to any of the general ledger accounts representing specific bank accounts, but not to the 'cash in banks' or 'cash and cash equivalents' accounts for which only subtotals or totals are displayed on financial statements.

Account numbers often have multiple dimensions which allow assets, liabilities, equity, revenue and expense transactions to be tracked from different perspectives or identifiers within the general ledger. For example they may contain a four-digit account number, three-digit division code and two-digit department code separated by a delimiter. In this case the account number '100104110' can be formatted like '100.10.4110'. When formatted account numbers are specified, to save data entry time the GM-X application allows either formatted or unformatted account numbers to be entered.

FISCAL_CALENDAR_HEADER table

This holds information about each fiscal calendar system, including settings which determine the beginning and ending dates for fiscal years and periods at any time in the past or future.

FISCAL_CALENDAR_PERIOD table

This identifies every fiscal period with each fiscal year within a particular fiscal calendar.

FUNCTIONAL_UNIT table

This holds the identifier, reporting currency, chart of accounts, fiscal calendar and last closed fiscal period for each general ledger maintained within the GM-X application. It also identifies various accounts that the GM-X application utilises by default or to automate specific accounting functions.

Each of the organisations for which a general ledger is kept is also known as a Business Entity.

Journal Entries and Account Balances

A journal entry ('JE'), sometimes called a 'journal voucher', is a transaction that is recorded in a functional unit's general journal and consists of the following:

• The appropriate date.
• The amount(s) and account(s) that will be debited.
• The amount(s) and account(s) that will be credited.
• A short description or memo.
• A reference such as a cheque number.

Following the double-entry accounting method, if the journal entry affects at least two accounts, and the amounts to be debited and credited balance, these journalised amounts (which will appear in the journal in order by date) are then posted to the accounts in the general ledger.

Each journal entry has at least two states, pending and posted. After a journal entry is posted, its amounts and accounts must not be changed. Instead, if corrections are needed, two new journal entries should be entered and posted, one to reverse the original journal entry and the other consisting of the corrected amounts and accounts.

It is also possible for journal entries to have additional states. For example, journal entries may require approval before they are posted.

Figure 2a - Opening Balances, Journal Entries and Period Balances

Figure 2b - Relationships with other database tables

GL_ACCOUNT_OPENING_BALANCE table

This holds the opening balances and budgets for each functional unit and account. Opening balances reflect the effects of journal entries that were already posted before the GM-X application was placed into service. This means that organisations which commenced operations after the GM-X application was placed into service will not have any opening balances.

JOURNAL_ENTRY_HEADER table

This holds information about journal entries.

JOURNAL_ENTRY_ITEM table

This holds accounts and amounts for each journal entry item.

JOURNAL_ENTRY_STATUS_TYPE table

This holds user-definable journal status values. Values used by the software are defined in a system file and cannot be altered.

Here are the values used by the system which cannot be altered:

JOURNAL_ENTRY_STATUS_HIST table

This holds the status history for each journal entry.

GL_ACCOUNT_PERIOD_BALANCE table

This holds the current balances and budgets for each functional unit, account and fiscal period.

Journal Entry Posting logic

Every Journal Entry starts off with a 'Pending' status and is not eligible for posting into the GL_ACCOUNT_PERIOD_BALANCE table until its status is changed to 'Complete'. This is not possible unless the following conditions are satisfied:

• The journal must have at least two line items.
• The journal must have at least two line items with different account_ids.
• The sum of all debit_functional amounts must equal the sum of all credit_functional amounts.

Depending on the organisation's policy journals may need to be approved before they can be posted. Posting may be done either online by selecting a journal and pressing the navigation button labelled 'Post', or by a scheduled batch job which will process all eligible journals. Once a journal has been posted it cannot be amended.

The steps taken by the journal posting process are as follows:

1. Determine the earliest period which will accept postings. The will either be the period which immediately follows the last closed period, or, if no periods have been closed yet, it will be the period of the earliest posting. If no postings have been made yet then any period is valid.
2. Examine all records on the JOURNAL_ENTRY_HEADER table which satisfy the following conditions:
   • The value of is_posted is 'N'.
   • The values of fiscal_year and fiscal_period do not point to a closed period.
   • The journal's status is either 'Complete' or 'Approved' depending on what has been set on the Control Record.
3. Each journal's items will the be revalidated using the rules identified previously. If the line items fail this validation in any way then the journal's status will be changed to 'Errors found when attempting to post' and it will be excluded from the posting process. The journal will have to be corrected before it will be eligible for posting. If the validation passes then the journal's is_posted flag will be set to 'Y' and its status will be changed to 'Posted'.
4. For each valid journal item ensure that a corresponding entry exists on the GL_ACCOUNT_PERIOD_BALANCE table for that combination of party_id_functional, chart_id, account_id, fiscal_calendar_id, fiscal_year and fiscal_period. If one does not exist then it will be created, otherwise the existing record will be updated.
5. Instead of updating the totals on the GL_ACCOUNT_PERIOD_BALANCE table with amounts from each individual line item being processed in the current run the software will instead perform a SUM operation on all the values from all relevant journals which have their is_posted flag set to 'Y'. This will ensure that the total is always calculated as the sum of its parts.

Opening and closing fiscal periods

The idea of closing a fiscal period is to prevent any more journals from being posted into that period. Journal Entries can only be posted into the current open period or future periods. Whenever a Journal Entry is created the posting_date is used to obtain the fiscal_period which covers this date from the FISCAL_CALENDAR_PERIOD table.

• Closing Period 12 prevents any further postings to a year's regular fiscal periods, but it does NOT close the year. The year is not considered closed until its audit period (period 13) is closed. There is only ever 1 current audit period at a time; and it is the audit period of the fiscal year immediately following the last closed fiscal year (or Period 13 of the earliest posted fiscal year, if no last closed fiscal year exists). That year may be termed the current fiscal year.
• Closing the audit period will close the current fiscal year. This action will implicitly re-point the current audit period to what was formerly the next fiscal year (now the current fiscal year), and it also automatically forces the last_closed_fiscal_period from 12 to NULL. The audit period is initially closed by virtue of the user having changed the value of is_audit_period_closed from 'N' to 'Y' so no postings to the audit period will be allowed until the user changes its value from 'Y' back to 'N'; this can be done manually at any time during what is now the current fiscal year but the audit period will be opened automatically if the user changes the last_closed_fiscal_period of the current fiscal year to 12. Forcing the last_closed_fiscal_period from 12 to NULL when closing the audit period will allow periods in what is now the current fiscal year to be closed as and when necessary.
• During the time interval which ensues after Period 12 of a fiscal year is closed, and before audit period (Period 13) is closed, the current fiscal year remains the same but the current regular period becomes Period 1 of the next fiscal year. This allows unlimited postings into both the audit period of the current fiscal year, and into the current regular period (as well as all subsequent fiscal periods defined to the FISCAL_CALENDAR_PERIOD table) but the current regular period cannot be closed until the audit period is closed, because none of the fiscal periods in the Last Closed Fiscal Period dropdown refer to that period yet. This makes perfect sense. You cannot close any periods in a subsequent fiscal year until all prior fiscal years are closed, because you cannot produce a final trial balance.

Recurring Journal Entries

A recurring journal entry is a journal entry that is recorded in every accounting period. For example, a company might record monthly rent by debiting Rental Expense for $3,000 and crediting Accounts Payable for $3,000 each and every month.

Recurring journal entries can also have identical accounts but amounts which vary by month. For example, the journal entry to record property insurance expense might involve Insurance Expense and Prepaid Insurance every month, but the amounts will change when the amount of the prepaid insurance premiums change. Other recurring entries will involve the identical accounts, but the amounts will be different in each accounting period. An example is the payroll entry. Each payroll entry will have the same accounts but different amounts due to the number of hours worked. Other examples of recurring entries with amounts that differ each period include sales, interest earned, interest expense, bank service charges, and so on.

The GM-X application also performs allocation processing using recurring journal entries created specifically for this purpose.

Figure 3a - Recurring Journal Entries

Figure 3b - Relationships with other database tables

RECURRING_JE_HEADER table

This holds information about recurring journal entries.

RECURRING_JE_ITEM table

This holds accounts, amounts and instructions for each recurring journal entry.

Standing Journal Entries

Standing Journals are saved journal entries that you use frequently and can be recalled to make manual journal entries faster.

Figure 4a - Standing Journal Entries

Figure 4b - Relationships with other database tables

STANDING_JE_HEADER table

This holds information about standing journal entries.

STANDING_JE_ITEM table

This holds information for each standing journal entry item.

Default Overrides for General Ledger Accounts

The default accounts for a business entity are defined on the FUNCTIONAL_UNIT table, but there may be situations where the default account needs to be overridden. These tables provide that ability.

Figure 5 - Default Overrides for General Ledger Accounts

FUNC_UNIT_PRICE_COMPONENT table

This identifies various accounts that the GM-X application utilises for specific price components, if different from the default accounts utilised by the entire organisation which are held in the FUNCTIONAL_UNIT table.

FUNC_UNIT_INV_VAR_REASON table

This table identifies the income or expense account that the GM-X application utilises for each inventory variance reason, if different from the default accounts utilised by the entire organisation which are held in the FUNCTIONAL_UNIT table.

FUNC_UNIT_PROD_CAT table

This identifies various accounts that the GM-X application utilises for specific product categories, if different from the default accounts utilised by the entire organisation which are held in the FUNCTIONAL_UNIT table.

FUNC_UNIT_FEATURE_CAT table

This identifies various accounts that the GM-X application utilises for specific product feature categories, if different from the default accounts utilised by the entire organisation which are held in the FUNCTIONAL_UNIT table.

FUNC_UNIT_WRK_EFF_PURPOSE table

This identifies various accounts that the GM-X application utilises for specific work effort purposes, if different from the default accounts utilised by the entire organisation which are held in the FUNCTIONAL_UNIT table.

Constructing Journal Entries Originating from Subsystems

Journal entry templates are used for constructing journal entries from GM-X subsystems that are integrated with the GM-X General Ledger subsystem. While default accounts used for posting journals are defined on the FUNCTIONAL_UNIT table these may be altered by entries on the Default Override tables.

Journals generated from the Accounts Receivable subsystem are described in Constructing Journals for the General Ledger.

Journals generated from the Accounts Payable subsystem are described in Constructing Journal Entries for Vendor Invoices and Constructing Journal Entries for Payments.

Figure 6 - Journal Entry Templates

SUBSYSTEM_JE_TEMPLATE_HEADER table

This holds information about journal entry templates for different GM-X subsystems.

SUBSYSTEM_JE_TEMPLATE_ITEM table

This holds line item information, including accounts, for each subsystem journal entry template.

Values for the account_usage field:

• cash_in_bank (Cash Account)
• trade_receivables (Trade Receivables Account)
• tax_wh_prepaid (Prepaid Income Tax Account)
• vendor_deposit (Vendor Deposit Account)
• ffe (Fixed Asset Acquisition Account)
• inventory (Inventory Account)
• wip (WIP Account)
• trade_payables (Trade Payables Account)
• sales_tax_payable (Sales Tax Payable Account)
• customer_deposit (Customer Deposit Account)
• commission_payable (Sales Commission Payable Account)
• pension_payable (Employee Pensions Payable Account)
• commission_liability (Sales Commission Accrual Account)
• sales_tax_liability (Sales Tax Liability Accrual Account)
• accrued_expense (Accrued Expense Account)
• sales_supply (Revenue Account - Goods)
• sales_use (Revenue Account - Use)
• sales_service (Revenue Account - Services)
• exp_recovery (Revenue Account - Expense Recovery)
• tax_recovery (Revenue Account - Tax Recovery)
• revenue_other (Revenue Account - Other)
• cogs (Cost of Goods Sold Account)
• ppv (Purchase Price Variance Account)
• tax_reimb (Direct Reimbursable Tax Expense Account)
• commission_expense (Sales Commission Expense Account)
• direct_labour (Direct Labour Account)
• staff_direct_reimb (Default Reimbursable Cost Account - Staff)
• staff_direct_mileage (Direct Mileage Cost Account - Staff)
• staff_direct_air (Direct Air Transportation Cost Account- Staff)
• staff_direct_hotel (Direct Hotel Cost Account - Staff)
• staff_direct_meal_own (Direct Subsistence Cost Account - Staff)
• staff_direct_entertain (Direct Entertainment Cost Account - Staff)
• staff_direct_other (Other Direct Cost Account - Staff)
• direct_cost_other (Direct Cost Account - Other)
• commissions_fees (Fee and Commission Expense Account - Financial Transactions)
• pension_expense (Employer Pension Expense Account)
• staff_indirect_reimb (Default Reimbursable Cost Account - Indirect)
• staff_indirect_mileage (Indirect Mileage Expense Account)
• staff_indirect_air (Indirect Air Transportation Expense Account)
• staff_indirect_hotel (Indirect Hotel Expense Account)
• staff_indirect_meal_own (Indirect Subsistence Expense Account)
• staff_indirect_entertain (Indirect Entertainment Expense Account)
• staff_indirect_other (Other Indirect Expense Account)
• debtor_fin_dsc_offered (Financial Discounts Offered Account)
• creditor_fin_dsc_taken (Financial Discounts Taken Account)
• interest (Interest Expense Account)
• tax_wh_final (Final Withholding Tax Expense Account)
• book_gain_loss (Book Gain or Loss Expense Account)
• crystallised_gain_loss (Crystallised Gain or Loss Expense Account)
• indirect_expense_other (Indirect Expense Account - Other)

Subsystem Posting to the General Ledger

Subsystem Journal Entry Templates

Control over how journal entries are posted from subsystems is governed by the properties of whatever subsystem journal entry templates are set up and used for those subsystems. The table below shows field descriptions for the five relevant properties on the SUBSYSTEM_JE_TEMPLATE_HEADER table as described in the Accounts Receivable functional specification.

The applicable template to use in a particular situation is specified as follows:

• For Invoicing and Accounts Receivable: the AR_PARTY_RELATIONSHIP table has 4 fields:
  • je_template_id_invoice
  • je_template_id_credit_note
  • je_template_id_debit_note
  • je_template_id_payment
• For Accounts Payable: the AP_PARTY_RELATIONSHIP table has 4 fields:
  • je_template_id_invoice
  • je_template_id_credit_note
  • je_template_id_debit_note
  • je_template_id_payment

All of the above fields are optional, which makes it possible to post journal entries from those subsystems without using a template. In this situation the following values must be used by default:

• uom_id_statistic = NULL
• is_approval_required = NO
• is_batch_post = NO (except for revaluation processing as described in the is_batch_post Property section, next)
• is_summary_journal = NO

is_batch_post Property

When the value of the is_batch_post property is NO, the following tasks *MUST* be utilised for creating journal entries and posting them to the general ledger:

• For Invoicing and Accounts Receivable: tasks
  • acc_invoice_header(upd4)post (Post Customer Invoice; also used for posting customer credit and debit notes)
  • far_settlement_header(upd4)post (Post Settlement)
• For Accounts Payable: tasks
  • fap_invoice_header(upd4)post (Post Vendor Invoices, Credit Notes and Debit Notes)
  • fap_payment_header(upd4)post (Post Payment)

In addition, the following tasks will automatically create journal entries and post them to the general ledger:

• For Accounts Receivable: task far_invoice_header(upd4)reval (Revalue Foreign Currency Accounts Receivable)
• For Accounts Payable: task fap_invoice_header(upd4)reval (Revalue Foreign Currency Accounts Payable)
• For Fixed Assets: task ffa_asset_book_event(upd4)post (Post Fixed Assets Transactions to the General Ledger)
• For Work Effort: task wrk_timesheet(upd4)post (Post Timesheets to the General Ledger)

The 8 tasks listed above are known as "online" tasks. Users activate each of them one at a time by selecting one or more rows from a LIST screen (i.e. entries on the INVOICE_HEADER table for Invoicing, Accounts Receivable, Accounts Payable and Work Effort; entries on the SETTLEMENT_HEADER table for Accounts Receivable; entries on the PAYMENT_HEADER table for Accounts Payable; and/or entries on the ASSET_BOOK_EVENT table for Fixed Assets) and then clicking the navigation button for that task to process those selections. Each of those navigation buttons *MUST* require context pre-selection.

NOTE: It is not possible to control the execution of the ffa_asset_book_event(upd4)post and wrk_timesheet(batch)post tasks using subsystem journal entry templates, because no templates can be specified anywhere within their respective subsystems. This means that the value of the is_batch_post property will always be YES for these tasks.

Further, when the value of the is_batch_post property is YES, the following tasks *MAY* may be utilised:

• For Invoicing and Accounts Receivable: tasks
  • acc_invoice_header(batch)post (Post Customer Invoice; also used for posting customer credit and debit notes
  • far_invoice_header(batch)reval (Revalue Foreign Currency Accounts Receivable)
  • far_settlement_header(batch)post (Post Settlement)
• For Accounts Payable: tasks
  • fap_invoice_header(batch)post (Post Vendor Invoices, Credit Notes and Debit Notes)
  • fap_invoice_header(batch)reval (Revalue Foreign Currency Accounts Payable)
  • fap_payment_header(batch)post (Post Payment)
• For Fixed Assets: task
  • ffa_asset_book_event(batch)post (Post Fixed Assets Transactions to the General Ledger)
• For Work Effort: task
  • wrk_timesheet(batch)post (Post Timesheets to the General Ledger)

The 8 tasks listed above are known as "batch" tasks, and each one utilises the same subclass as its online counterpart. Each batch task may be activated in one of the following ways:

• By clicking a navigation button requiring no context pre-selection; or
• By linking the task to a CRON job which causes the task to execute automatically at scheduled time intervals

When each of the batch tasks executes, it must "qualify" entries which have not yet been posted. This serves the same purpose as context pre-selection for the respective online tasks.

For all tasks EXCEPT far_invoice_header(batch)reval (Revalue Foreign Currency Accounts Receivable) and fap_invoice_header(batch)reval (Revalue Foreign Currency Accounts Payable), qualified entries are determined as follows:

1. Traverse the respective INVOICE_HEADER, SETTLEMENT_HEADER, PAYMENT_HEADER, ASSET_BOOK_EVENT or TIMESHEET table to identify any entries which have not yet been posted. In all cases each qualified entry will have an is_posted value of NO.
2. In addition, the fap_payment_header(batch)post (Post Payment) task will identify any entries which have an is_void_posted value of NO when traversing the PAYMENT_HEADER table. These entries are also qualified for posting to the general ledger. Note that the posting of a void payment, which will set the is_void_posted value on the PAYMENT_HEADER to YES, creates an additional journal entry which is separate and distinct from the journal entry created by the original payment, which will set the is_posted value on the PAYMENT_HEADER to YES.
3. In addition, for entries in the ASSET_BOOK_EVENT table having an is_posted value of NO, the ffa_asset_book_event(batch)post (Post Fixed Assets Transactions to the General Ledger) task will determine if the entry's event_type_id value is NOT one of the following which have no general ledger impact:
   • 1 (Construction)
   • 3 (Checked out)
   • 4 (Checked in)
   • 7 (Fault)
   • 8 (Serviced)
   • 10 (Retired)
   Entries which have an is_posted value of NO, AND have an event_type_id value which is not 1, 3, 4, 7, 8 or 10, are also qualified for posting to the general ledger.

For the far_invoice_header(batch)reval (Revalue Foreign Currency Accounts Receivable) and fap_invoice_header(batch)reval (Revalue Foreign Currency Accounts Payable) tasks, qualified entries are determined by traversing the INVOICE_HEADER table to identify each entry having a currency_code_tx which is different from its currency_code_fn, AND which has a balance_tx value unequal to zero. These entries can be revalued at any time, because spot rates of exchange fluctuate very frequently.

For each selected or qualified entry, the subclass utilised by each of the 8 online and 8 batch tasks listed above does the following:

1. Validates the entry to ensure that all status and other conditions for general ledger posting have been satisfied. The exact logic for doing this will vary depending upon the subclass utilised. Refer to the Accounts Payable Journal Entries section for additional information.
2. If all status conditions have been met at Step 1, constructs a proposed JOURNAL_ENTRY_HEADER and one or more JOURNAL_ENTRY_ITEM entries in memory. The posting_date and transaction_date for the proposed journal entry are current date in the GM-X application server's time zone, and its initial is_posted value is NO. The exact logic for doing this will vary depending upon the subclass utilised. Refer to the Accounts Payable Journal Entries section for additional information.
3. Validates the proposed in memory journal entry in the same manner as described in Journal Entry Posting logic, EXCEPT that the system assumes that the journal entry's je_status_type_id is either 'COMP' (Complete) or 'APPR' (Approved) instead of inspecting the proposed journal entry to determine that this is actually the case. Note that this validation will evaluate if the posting_date set at Step 2, above, falls within a fiscal period which is not currently closed, and throw a validation error if this is not the case.
4. If no errors are detected during validation at Step 3, above, and the proposed journal entry is considered complete and balanced, attempts to insert the proposed JOURNAL_ENTRY_HEADER and JOURNAL_ENTRY_ITEM entries into the FINANCE_GL database.
5. If no errors were detected during the insert at Step 4 then update the is_posted value to YES on the qualified entry within the INVOICE_HEADER, SETTLEMENT_HEADER, PAYMENT_HEADER, ASSET_BOOK_EVENT or TIMESHEET table; or, for the fap_payment_header(batch)post (Post Payment) task, update the is_void_posted value to YES when posting a void payment.

Refer to the is_summary_journal Property, is_approval_required Property and uom_id_statistic Property sections, below, for additional information.

For online tasks, any errors found during the validation at Steps 1 and 3, or during insert at Step 4, above, will be displayed in the message bar of the LIST screen. For batch tasks, those errors will be written to a batch error log. Note that if any such errors occur, the system will take no action other than displaying error messages on the user's screen or writing them to the batch error log, and will then move on to the next entry - which will be the next pre-selected entry on the LIST screen for online tasks, or the next qualified entry for batch tasks.

is_summary_journal Property

Whenever creating a proposed journal entry, the system will set the value of subsys_id on the JOURNAL_ENTRY_HEADER as follows:

• 'FINANCE-AP' (Accounts Payable) when executing the task:
  • fap_invoice_header(upd4)post
  • fap_invoice_header(batch)post
  • fap_invoice_header(upd4)reval
  • fap_invoice_header(batch)reval
  • fap_payment_header(upd4)post
  • fap_payment_header(batch)post
• 'FINANCE-AR' (Accounts Receivable) when executing the task:
  • far_invoice_header(upd4)reval
  • far_invoice_header(batch)reval
  • far_settlement_header(upd4)post
  • far_settlement_header(batch)post
• 'FINANCE-FA' (Fixed Assets) when executing the task:
  • ffa_asset_book_event(upd4)post
  • ffa_asset_book_event(batch)post
• 'INVOICE' (Invoicing) when executing the task:
  • acc_invoice_header(upd4)post
  • acc_invoice_header(batch)post
• 'WORK-EFFORT' (Work Effort) when executing the task:
  • wrk_timesheet(upd4)post
  • wrk_timesheet(batch)post

Also, whenever creating a proposed journal entry, if a subsystem journal entry template is utilised then the system will set the value of je_template_id on the JOURNAL_ENTRY_HEADER to the value of je_template_id found on the relevant AP_PARTY_RELATIONSHIP or AR_PARTY_RELATIONSHIP record for the entry on the INVOICE_HEADER, SETTLEMENT_HEADER or PAYMENT_HEADER being processed. Otherwise the system will set the value of je_template_id on the JOURNAL_ENTRY_HEADER to NULL.

Whenever processing one of the 8 online tasks listed in the is_batch_post Property section the value of the is_summary_journal property will be set to 'NO'. This means that online tasks will never produce summarised journals, only detailed journals as indicated in step #1 below.

For all batch tasks the value of the is_summary_journal property will be taken from the SUBSYSTEM_JE_TEMPLATE_HEADER is the value of je_template_id is not null. If there is no template header then the value of the is_summary_journal property will be set to NO. If a template header does exist and its value of is_summary_journal is YES then only summarised journals should be produced as indicated in step #4 below.

For DETAIL journal entries the processing is as follows:

1. There will be a separate JOURNAL_ENTRY_HEADER for each individual document, either pre-selected for online tasks or qualifying from batch tasks, where a "document" is one of an INVOICE_HEADER, SETTLEMENT_HEADER, PAYMENT_HEADER, ASSET_BOOK_EVENT or TIMESHEET.
2. There will be one or more JOURNAL_ENTRY_ITEM entries for each document component:
   • INVOICE_ADJUSTMENT, INVOICE_ITEM, INVOICE_ITEM_ADJUSTMENT and/or INVOICE_ITEM_FEATURE for customer and supplier invoices, credit notes and debit notes
   • PAYMENT_ITEM_SETTLED, PAYMENT_ITEM_APPLIED for payments.
   • SETTLEMENT_ITEM and SETTLEMENT_ITEM_APPLIED table for settlements.
   • ASSET_BOOK_EVENT for assets.
   • TIMESHEET for timesheets
3. Each JOURNAL_ENTRY_ITEM will contain the following fields, thereby making it possible for a user to drill down from the journal entry to all its component details:
   • party_id_transacting
   • document_reference
   • invoice_type
   • invoice_id
   • invoice_adjustment_seq_no
   • invoice_item_seq_no
   • invoice_item_prod_feature_id
   • invoice_item_adjustment_seq_no
   • payment_id (linked to settlement_number on the PAYMENT_HEADER table)
   • payment_line_no (linked to settlement_line_item on the PAYMENT_ITEM_SETTLED table)
   • payment_applied_line_no (linked to applied_line_item on the PAYMENT_ITEM_APPLIED table)
   • receipt_id (linked to settlement_number on the SETTLEMENT_HEADER table)
   • receipt_line_no (relates to settlement_line_item on the SETTLEMENT_ITEM table)
   • receipt_applied_line_no (linked to applied_line_item on the SETTLEMENT_ITEM_APPLIED table)
   • order_type - for INVOICE_HEADER entries linked to an order, ONLY when posting journal entries for invoices, debit notes or credit notes
   • order_id - for INVOICE_HEADER entries linked to an order, ONLY when posting journal entries for invoices, debit notes or credit notes
   • asset_id (relates to asset_id on the ASSET_OWNER table)
   • asset_seq_no (relates to asset_seq_no on the ASSET_BOOK_EVENT table)

For SUMMARY journal entries the processing is as follows:.

4. Instead of writing out a separate JOURNAL_ENTRY_HEADER for each document followed by its corresponding JOURNAL_ENTRY_ITEM records, all the data from the component details must be stored in memory for each summary key which is comprised of party_id_functional, fiscal_calendar_id, fiscal_year, fiscal_period, chart_id, account_id, subsys_id and je_template_id. (the subsys_id and je_template_id values are found on the related JOURNAL_ENTRY_HEADER)
5. For each of these keys the following values must be accumulated - debit_functional, credit_functional and (for invoices only) statistic. This means that all the other fields which are listed in step #1 above will have their values set to NULL, all except journal_desc in the JOURNAL_ENTRY_HEADER record which will require one of the following values:
   • fap_invoice_header(batch)post - "Vendor invoice, credit note or debit note"
   • fap_payment_header(batch)post - "Vendor Payments"
   • far_settlement_header(batch)post - "Customer Settlements"
   • ffa_asset_book_event(batch)post - "Asset"
   • acc_invoice_header(batch)post - "Customer invoice, credit note or debit note"
   • fap_invoice_header(batch)reval - "Revalue foreign currency accounts payable"
   • far_invoice_header(batch)reval - "Revalue foreign currency accounts receivable"
   • wrk_timesheet(batch)post - "Timesheet"
6. Once all input records have been processed the details held in memory must be sorted by the summary key before they are written out to the JOURNAL_ENTRY_ITEM table. For each combination of party_id_functional, fiscal_calendar_id, fiscal_year, fiscal_period, chart_id, subsys_id and je_template_id an entry on the JOURNAL_ENTRY_HEADER table must be created and its journal_number added to each corresponding JOURNAL_ENTRY_ITEM record.

Rationale: detail journal entries are a great timesaving feature because users can drill down instantly when tracing journal entries back to their original source documents when performing analyses or audits, but the cost of this visibility is a potentially vastly larger number of JOURNAL_ENTRY_ITEM records in the database. So, during implementation, clients can review their accounting policies and do a cost-benefit assessment in order to answer the question, "Are the user time savings we will realise from drilldown availability worth the cost of extra records to look after in the database?"

is_approval_required Property

Whenever the value of the is_approval_required property is NO, after successfully inserting entries into the JOURNAL_ENTRY_HEADER and JOURNAL_ENTRY_ITEM tables, the 8 online and 8 batch tasks described above will insert three (3) rows into the JOURNAL_ENTRY_STATUS_HIST table as follows:

1. The first row will initialise the je_status_type_id on the JOURNAL_ENTRY_HEADER to 'PEND' (Pending).
2. The second row will update the je_status_type_id on the JOURNAL_ENTRY_HEADER to 'COMP' (Data entry complete and balanced).
3. The third row will update the je_status_type_id on the JOURNAL_ENTRY_HEADER to 'POST' (Posted without errors) and will also update the is_posted value on the JOURNAL_ENTRY_HEADER to YES.

Otherwise, after inserting entries into the JOURNAL_ENTRY_HEADER and JOURNAL_ENTRY_ITEM tables, the 8 online and 8 batch tasks described above will insert two (2) rows into the JOURNAL_ENTRY_STATUS_HIST table as follows:

1. The first row will initialise the je_status_type_id on the JOURNAL_ENTRY_HEADER to 'PEND' (Pending).
2. The second row will update the je_status_type_id on the JOURNAL_ENTRY_HEADER to 'COMP' (Data entry complete and balanced). NOTE that in this situation the is_posted value on the JOURNAL_ENTRY_HEADER will remain NO and it will be necessary to approve the journal entry within the General Ledger subsystem.

uom_id_statistic Property

Just as for the JOURNAL_ENTRY_HEADER and JOURNAL_ENTRY_ITEM tables, the SUBSYSTEM_JE_TEMPLATE_HEADER and SUBSYSTEM_JE_TEMPLATE_ITEM tables each have a uom_id_statistic field.

When constructing a JOURNAL_ENTRY_HEADER, the system will populate its uom_id_statistic field from the value of the uom_id_statistic field on the SUBSYSTEM_JE_TEMPLATE_HEADER table, if any; otherwise the uom_id_statistic field on the JOURNAL_ENTRY_HEADER will remain NULL.

Similarly, when constructing a JOURNAL_ENTRY_ITEM, the system will populate its uom_id_statistic field from the value of the uom_id_statistic field on the SUBSYSTEM_JE_TEMPLATE_ITEM table, if any; otherwise the uom_id_statistic field on the JOURNAL_ENTRY_ITEM will remain NULL.

The system will also write a value into the statistic column of each JOURNAL_ENTRY_ITEM that has an invoice_item_seq_no value which is not NULL, and the statistic value will be the same as the value of the quantity field on the related INVOICE_ITEM entry (for detail journals), OR the rolled-up values of the quantity field on the related INVOICE_ITEM entries (for summary journals).

Invoice Revaluations

When a customer or vendor invoice, credit note or debit note is raised with a currency_code_tx (transaction currency) which is different from the currency_code_fn (functional currency) it uses the EXCHANGE_RATE which was current at the document date in order to convert the document value from transaction currency to functional currency. There could be a delay before the document is actually paid, and during this time the exchange rate could have altered which means that the balance outstanding for the document in functional currency needs to be recalculated and the difference between this latest value and the original value posted to the General Ledger.

Constructing the Account Distribution for Invoice Revaluations

Overview

Each revaluation will refer to a component of a document which is an invoice, credit note or debit note within the Accounts Receivable or Accounts Payable subsystems. Each of those components is represented as an entry on one of the following database tables:

• INVOICE_ADJUSTMENT
• INVOICE_ITEM
• INVOICE_ITEM_ADJUSTMENT
• INVOICE_ITEM_FEATURE

Revaluations *MAY* be performed whenever the currency_code_tx value (i.e. transaction currency) differs from the currency_code_fn value (i.e. functional currency) on the related INVOICE_HEADER entry. If the transaction currency is the same as the functional currency then revaluation is NEVER performed and the document component *MUST* be skipped. Revaluations are only performed on the outstanding balance (i.e. when balance_tx is greater than zero.

When an entry on any of these four database tables is revalued, this action will require two entries to be written to the JOURNAL_ENTRY_ITEM table. Every input will require an output for the account_id which has been associated with the usage 'trade_receivables' (for accounts receivable) or 'trade_payables' (for accounts payable) as a first side entry, plus one additional 'book_gain_loss' usage as a contra side entry. The account_id can be obtained from the account_usage value using the procedure described in Determine the account_id from an account_usage value.

Because only one additional usage is ever identified for a particular monetary value then the value used in the first side entry can be reversed and used in a single contra side entry.

Traversing the SUBSYSTEM_JE_TEMPLATE table

The identity of the records to be read is held in the following fields on the AR_PARTY_RELATIONSHIP or AP_PARTY_RELATIONSHIP tables:

• je_template_id_invoice for invoices
• je_template_id_credit_note for credit notes
• je_template_id_debit_note for debit notes

Note that even though a value for je_template_id may be provided, there may or may not be any eligible records on the SUBSYSTEM_JE_TEMPLATE_ITEM table.

Each valid record read from the SUBSYSTEM_JE_TEMPLATE_ITEM table will result in a record being written to the JOURNAL_ENTRY_ITEM table for each document component.

All the available records must be read and processed one at a time. For accounts receivable revaluations, note that any record with an account_usage which does not appear in the following table is to be ignored:

For accounts payable revaluations, note that any record with an account_usage which does not appear in the following table is to be ignored.

Examination of this table will stop when it finds a record containing a non-blank account_id for the selected account_usage.

Determine the account_id from an account_usage value

This procedure is used to convert an account_usage into an account_id. This value may be provided on any one of a number of records which must be searched in the following sequence:

• SUBSYSTEM_JE_TEMPLATE_ITEM - look for an entry with an exact match in the account_usage column.
• FUNCTIONAL_UNIT - look for an entry in the column which is named account_id_{account_usage}.

Note that the FUNCTIONAL_UNIT table can only be read if the input record from the INVOICE subsystem contains the primary key for that table.

As soon as the first non-blank value for account_id is found then the account determination process will be terminated. If at the end there is no value for account_id then the value for account_usage will be used instead. This record will have to be corrected by the user manually in order to balance the debits and credits for the document before it can be marked as 'complete'.

Debits and Credits for First Side and Contra Side Entries

The "first side" refers to the side (debit side, or credit side) of a JOURNAL_ENTRY_ITEM entry which identifies the balance sheet account (i.e. the trade receivables asset account for accounts receivable, or the trade payables liability account for accounts payable) affected by the document component.

The credit_functional or debit_functional value for the first side is calculated as follows:

1. Calculate the revalued amount - multiply the value of the balance_tx field on the invoice component entry by the current exchange rate, and round the result to the nearest decimal point specified by scale on the CURRENCY_CODE entry linked to the currency_code_fn value on the related INVOICE_HEADER entry. The current exchange rate is obtained from the EXCHANGE_RATE table using today's date. The exchange rate lookup is FROM the currency_code_tx value TO the currency_code_fn value on the related INVOICE_HEADER entry.
2. Calculate the movement amount - subtract the balance field on the invoice component entry from the revalued amount calculated at Step 1, above. The movement amount may be zero. When this is the case, no revaluation or journal entry is required and the document component must be skipped; ELSE the movement amount may be a positive or negative number.
3. Update the document component - add the movement amount calculated at Step 2, above, to the values of the balance and reval_value fields on the invoice component entry, and re-save the entry.
4. Update the document - add the movement amount calculated at Step 2, above, to the values of the balance and adjusted_reval_value fields on the INVOICE_HEADER entry, copy today's date into the last_reval_date field on the INVOICE_HEADER entry, and re-save the entry.
5. If revaluing accounts payable (supplier invoices, credit notes and debit notes), flip the sign of the movement amount calculated at Step 2, above (i.e. multiply the value of the movement amount by -1); otherwise leave the movement amount unchanged.
6. If the movement amount after completing Step 5, above, is a positive number then copy the movement amount to the debit_functional value on the new JOURNAL_ENTRY_ITEM entry; ELSE copy the absolute value of the movement amount to the credit_functional value on the new JOURNAL_ENTRY_ITEM entry.

Relative to the first side entry for a document component, the "contra side" (or "opposite side") refers to the side of its mandatory and opposite entry. Each contra side entry must affect a different account than its corresponding contra side entry. Therefore:

• If the corresponding first side entry is a credit then the contra side entry will always debit the book_gain_loss account.
• If the corresponding first side entry is a debit then the contra side entry will always credit the book_gain_loss account.

Accounts Receivable processing

This includes all INVOICE_ADJUSTMENT, INVOICE_ITEM, INVOICE_ITEM_ADJUSTMENT and INVOICE_ITEM_FEATURE entries which have a non-zero value in the balance_tx column, and which are related to INVOICE_HEADER entries where the currency_code_tx value differs from the currency_code_fn value, AND the entry has the the following invoice_type values:

• 'I' for customer invoices;
• 'C' for customer credit notes; or
• 'D' for customer debit notes.

A separate Segment 1 must be constructed for each of these entries, EXCEPT the following entries which are *NEVER* revalued and must ALWAYS be skipped:

• INVOICE_ADJUSTMENT and INVOICE_ITEM_ADJUSTMENT entries which are linked to a PRICE_COMPONENT entry having a price_type of 'C' (Commission); OR
• INVOICE_ADJUSTMENT entries which are linked to a PRICE_COMPONENT entry having a price_type of 'W' (Withholding tax); OR
• INVOICE_ADJUSTMENT entries which are linked to a PRICE_COMPONENT entry having a price_type of 'E' (Early Payment Discount); OR
• INVOICE_ADJUSTMENT entries which have a non-blank product_id_free value.

To construct each Segment 1:

1. Determine the 'trade_receivables' account and output this as a first side entry using the values calculate at Steps 1, 2 and 6, above.
2. Determine the 'book_gain_loss' account and output this as a contra side entry using the values calculated at Steps 1, 2 and 6, above.

Accounts Payable processing

This includes all INVOICE_ADJUSTMENT, INVOICE_ITEM, INVOICE_ITEM_ADJUSTMENT and INVOICE_ITEM_FEATURE entries which have a non-zero value in the balance_tx column, and which are related to INVOICE_HEADER entries where the currency_code_tx value differs from the currency_code_fn value, AND the entry has the the following invoice_type values:

• 'V' for supplier invoices;
• 'U' for supplier credit notes; or
• 'R' for supplier debit notes.

A separate Segment 1 must be constructed for each of these entries, EXCEPT the following entries which are *NEVER* revalued and must ALWAYS be skipped:

• INVOICE_ADJUSTMENT and INVOICE_ITEM_ADJUSTMENT entries which are linked to a PRICE_COMPONENT entry having a price_type of 'C' (Commission); OR
• INVOICE_ADJUSTMENT entries which are linked to a PRICE_COMPONENT entry having a price_type of 'W' (Withholding tax); OR
• INVOICE_ADJUSTMENT entries which are linked to a PRICE_COMPONENT entry having a price_type of 'E' (Early Payment Discount); OR
• INVOICE_ADJUSTMENT entries which have a non-blank product_id_free value.

To construct each Segment 1:

3. Determine the 'trade_payables' account and output this as a first side entry using the values calculate at Steps 1, 2 and 6, above.
4. Determine the 'book_gain_loss' account and output this as a contra side entry using the values calculated at Steps 1, 2 and 6, above.

Constructing journal entries

The fap_invoice_header(upd4)reval, fap_invoice_header(batch)reval, acc_invoice_header(upd4)reval and acc_invoice_header(batch)reval tasks will create JOURNAL_ENTRY_HEADER and JOURNAL_ENTRY_ITEM entries from each component related to each selected or qualified INVOICE_HEADER entry.

Construct JOURNAL_ENTRY_HEADER

The following table shows the field mappings for constructing JOURNAL_ENTRY_HEADER entries.

1. From the value of party_id_bill_from (for accounts receivable) or party_id_bill_to (for accounts payable) on the INVOICE_HEADER entry linked to the invoice component.
2. From the values of chart_id and fiscal_calendar_id on the FUNCTIONAL_UNIT entry linked to the party_id_bill_from (for accounts receivable) or party_id_bill_to (for accounts payable).
3. Automatically generated by the system when inserting a new journal entry into the database.
4. The posting_date and transaction_date are set to today's date in the application server's time zone. The fiscal_year and fiscal_period are determined by looking up the entry belonging to the fiscal_calendar_id on the FISCAL_CALENDAR_PERIOD table having a start_date on or earlier than the posting_date, AND an end_date on or later than the posting_date.
5. The value of journal_desc is 'Revalue foreign currency accounts receivable' (for accounts receivable) or 'Revalue foreign currency accounts payable' (for accounts payable) as retrieved from the language_text.inc file
6. From the uom_id_statistic field on the SUBSYSTEM_JE_TEMPLATE_HEADER entry having the je_template_id described in Note 6, next, if any; otherwise set to NULL.
7. From one of the following fields on the AR_PARTY_RELATIONSHIP entry linked to the party_id_bill_to and party_id_bill_from on the INVOICE_HEADER entry for the invoice component (for accounts receivable):
   • je_template_id_invoice when the value of invoice_type is 'I'; or
   • je_template_id_credit_note when the value of invoice_type is 'C'; or
   • je_template_id_debit_note when the value of invoice_type is 'D'.
   OR one of the following fields on the AP_PARTY_RELATIONSHIP entry linked to the party_id_bill_to and party_id_bill_from on the INVOICE_HEADER entry for the invoice component(for accounts payable):
   • je_template_id_invoice when the value of invoice_type is 'V'; or
   • je_template_id_credit_note when the value of invoice_type is 'U'; or
   • je_template_id_debit_note when the value of invoice_type is 'R'.

Construct JOURNAL_ENTRY_ITEM

The following table shows the field mappings for constructing JOURNAL_ENTRY_ITEM entries.

8. From the value of party_id_bill_to (for accounts receivable) or party_id_bill_from (for accounts payable) on the INVOICE_HEADER entry linked to the invoice component.
9. From the value of invoice_id_external on the INVOICE_HEADER entry linked to the invoice component.
10. These values accumulate for summary journal entries (refer to is_summary_journal Property).
11. From the values of order_type and order_id on the INVOICE_HEADER entry linked to the invoice component.

General Ledger Control Data

This information exists within a shared table in the MENU database and not a separate table within the FINANCE_GL database. It holds values which can be varied to suit that particular installation. The current values are as follows:

Date created: 28th September 2018

Amendment history:

Copyright © 1999-2024 by Geoprise Technologies Licensing, All Rights Reserved.