GL Journal Transactions

Overview

To enter and post journal transactions into e5 GL, use the Data Entry Header and Detail screens. Entering journal transactions involves data entry of both header and detail information. For example, header information includes the journal transaction type, transaction amount total and number of transactions. Detail information includes account numbers, amounts and transaction descriptions.

A journal transaction must meet the following validation criteria:

Standard Data Entry - Use this method for routine or customary journal transactions.

Template Data Entry - Use this method for set up model or template for journal transaction data entries. This method eliminates and minimises repetitive entry of frequently used data.

Transaction Types

Identify transaction batches by the following batch types:

Data Entry Modes

The Data Entry Detail screen MEDB includes ten possible variations. e5 GL is delivered with two Data Entry Detail formats. The eight remaining formats are user-defined.

The system-supplied screens are data entry modes Fast and Detailed. Fast mode is the default. Detailed mode is a slightly different format of Fast mode.

Review Batches

You can review batches of transactions previously entered on the system, limiting the review to the batches that meet specific criteria. One of these criteria is Status. To limit displayed transactions to a specific status, enter a Status code at the end of a Fast Path or on the Extended Selection screen. Or, select a different option from the General Ledger Data Entry Menu, for example, Review Incomplete Batches, Review In Error Batches , Review Unauthorised Batches or Review Disabled Batches . The following are the possible statuses and their corresponding codes:

Code

Status Meaning

A

Report

The voucher will not post to GL, but is available for reporting.

B

Held

Held awaiting funds

0

Waiting

Awaiting processing

1

In Use

Currently in use by another user

2

Incomplete

Suspended by user

3

Unauthorised

Requires authorisation before processing

4

In Error

Suspended due to errors. Re-access to correct error and then update

5

Disabled

Disabled by user. Further action is required before processing

6

Authorised

Journal transaction is authorised.

7

Unprocessed

Processing is delayed until requested.

8

Being Processed

 Journal transaction is currently being processed.

9

Processed

Journal transaction is processed and posted to GL.

Standard Data Entry

You can use standard data entry to enter routine or customary journal transactions. The following describes journal transaction types:

Standard journal transactions represent exact and complete transactions that neither recur nor reverse in future periods.

To indicate a standard journal transaction, leave the Recurral Periods and the Accrual Reversal Period blank on the Data Entry Header screen MEDB.

Recurring Journal Transactions

A recurring journal transaction is a set of transactions that posts repeatedly over a number of consecutive periods. Instead of manually entering these transactions as standard journal transactions each period, enter them as a recurring journal transaction and post them to all required periods simultaneously.

To indicate a recurring journal transaction, enter the recurrent batch type and the number of times the journal transaction is to recur in Recurral Periods on the Data Entry Header screen MEDB. You can enter the number of periods up to the end of the following year.

To control recurring journal transaction validation on the Batch Type screen MAKL, create a journal transaction type exclusively for recurring journal transaction processing. When using this type, the number of periods must be entered on the Data Entry Header screen MEDB. You can also set up a journal transaction type that is normally, but not exclusively, used for recurring journal transaction processing. If using this type, the system issues a warning if Recurral Periods is left blank.

Accrual/Reversal Journal Transactions

Expenses and liabilities that have been incurred in a fiscal period, but not yet invoiced must be accrued at the end of the period to accurately reflect the financial position of the company. For example, wages earned by employees in the current period but after the last pay period or commissions earned but not yet collected or billed to customers.

You can reverse accrued entries in a future period. The adjusting entry made at the end of one period is reversed at the beginning of the future period. For example, the account debited in period one is credited in period two or the account credited in period one is debited in period two.

To indicate an accrual journal transaction, enter the accrual batch type and the accrual reversal period on the Data Entry Header screen MEDB. When posting an accrual, the reversal can occur in any period up to a year in advance.

To control accrual type batches on the Batch Type screen MAKL, create a journal transaction type exclusively for accrual journal transaction processing. When using this type, the accrual reversal period must be entered on the Data Entry Header screen. You can also set up a journal transaction type that is normally, but not exclusively, used for accrual journal transaction processing. If using this type, the system issues a warning if Accrual Reversal Period is left blank.

Any transaction type may be marked as foreign currency to reflect transactions that use a non-base currency. If using Intra company Accounting (ICA), every batch that posts to balance class AB must belong to a BTZ element. You must enter this at BTZ Element on the Data Entry Header screen MEDB.

Inter Departmental Transfers

Invoice transfer batches allow operators from different departments to create journal entries which cross charge other departments for inter departmental work. Operators can update batches with detail lines that previously they could not access.

Before completing an inter departmental transfer, you must create a batch type on the Batch Type screen MAKL and set Transfer Invoices to either optional or required .

To indicate an inter departmental transfer journal transaction, enter the invoice transfer batch type and the security group on the Data Entry Header screen MEDB. The security group represents the `transfer to' department. If you transfer an invoice and your security group is not the security group defined on the batch header, then Business Event Manager (BEM) creates a notification. The notification contains the batch number requiring entry of the contra account and is sent to each operator who is part of the security group on the batch header. You receive BEM messages when you sign on. If signed on, you receive a message informing you of an event in your diary. The BEM message is only generated the first time a batch is transferred.

You can navigate directly from the business events diary to the GL Data Entry Batch List screen MEDA to update the GL batch. Once the batch is successfully processed, the system removes the remaining diary events.

Template Data Entry from Template

You can use template data entry to set up a model for journal transaction data entry. This model lets you minimise repetitive entry of frequently used data. For instructions on posting template batches, refer to the previous instructions on Standard Data Entry.

You can optionally provide a percentage value against each line on a journal template to be used to allocate a specified value and / or quantity during journal entry. At journal entry, the system will allocate the entered quantity or value across each journal line on the template according to the percentage held against each template line.

If you are using ICA, you do not have to enter the BTZ Element until you are using it for standard data entry.

The system does not validate the information entered on the template screens until the template is fetched with the Fetch Retrieve action during Standard Data Entry. When completing the template screens, you can leave all fields blank on the Header screen, except Type , until the template is fetched and validated during Standard Data Entry.

Reviewing Funds Check Failure Details

If you are using Commitment Accounting and a funds check failure occurs during data entry, a failure message appears when you try to update the batch. You can use the three funds check list screens to obtain details about the funds check failure.

The Funds Check Failures screen MESC displays details of the funds check failure and lets you select failure lines for detailed inquiry.

The Funds Check Detail screen MESD lists all of the attempted commitment postings in a financial period for the full account/path key you selected on the Funds Check Failures screen MESC. There are two versions of this screen: base currency and non-base currency.

The Funds Check Budget Details screen MESS displays more details of the budgets associated with the funds check failure.

If the funds check failure occurred because funds were unavailable and you saved the transaction, once funds become available you can select Review Funds Check Failure Batches from the General Ledger Data Entry Menu. This option lets you select the failed batch and make corrections on the Data Entry Header screen MEDB, allowing the transaction to post.

NOTE The menu path shown is the default for the system. Your company may have customised menu options, so the path shown may not be accurate. Please contact your system administrator for details.

See also

General Ledger Home Page