Cash Receipting - Using

As a guideline to using Cash Receipting the following provides an overview of typical activities that a cashier will perform on a daily basis when using the Cash Receipting module.

• Overview
• External Transactions
• Exporting Data
• Worked Example

Overview

A cashier will log into e5 and access the receipt data entry option.  The act of accessing the data entry option will trigger a session log-on entry to be recorded against that cashiers ID on the Cashiers table. Likewise exiting a new screen, the system reference list, will trigger a session log-off entry on the Cashiers table.

The act of raising cash receipts will allow, at the time of the log-off entry being made, cash in/cash out information to be calculated by the system thus providing float management functionality.

A cashier will be able to raise receipts for the payment of cash sales items (using common e5 item codes); invoices previously raised in e5 AR or invoices previously raised in other line of business systems. This depends on what Fund Type IDs have been set-up in the CR module. Each receipt line will be either a cash sale item or a previously raised invoice, although each receipt record can include any number and / or combination of the three options above.

A cashier will be able to accept a range of payment modes for the above mentioned receipt items.  The various modes to be available are tendered cash, cheque, money order, credit cards, debit cards, direct credit and EFTPOS processing.  Each receipt can be raised with one or any combination of these payment modes.

Other features of the data entry function are:

• By default each receipt will be printed on update although the cashier will have functionality to stop the printing of a receipt record at data entry time.
• Controls over the generation and population of the bank reconciliation code to ensure the bank reconciliation process runs as smooth as possible.
• Change calculator functionality providing the cashier with change amount where cash has been tendered as payment.
• Rounding functionality where the total receipt value is rounded to the nearest 5 cents / pence. This functionality has been specifically designed for Australia and New Zealand environments where the minimum value of coin in circulation is the 5 cent coin, thus the rounding flag has been added to the CR Company controls.
• The cashier will be able to view and print a detail bank deposit listing for taking to the bank when depositing the days/weeks takings.  The bank deposit listing information will be available in both detail and summary form.  The detailed listing can be requested at cashier level while the summary can be requested at company level to provide a complete overview of the days/weeks bankings.

Maintenance functionality will be provided as follows:

• Amendment capability to allow certain, non-financial information to be changed on a receipt record.
• Receipt re-print functionality
• Functionality to allow a receipt to be fully reversed. Authorisation of receipt reversals will be provided.
• Functionality to allow for a single cheque on a receipt to be processed as a dishonoured cheque.

The reconciliation processes within the Bank Reconciliation module will ensure e5 updates a reconciled flag against a receipt record once the related payment modes for that receipt have been fully reconciled in the Bank Reconciliation module.

External Transactions

The External Transaction Take-on process is designed to take on Unpaid Invoices, from non-e5 invoicing or line of business systems.  The process can be scheduled to run automatically or manually submitted using the standard submission screens.

This will allow cash receipting to receive payment on behalf of many disparate business systems, providing updates to those systems via an extract of paid transactions. The integrated business process will involve an orchestration of systems via regular refresh actions to ensure that the current state of each external invoicing (or LOB) system is reflected in the Cash Receipting module.  Each site will need to consider the frequency of the refresh, and the likely impact on the business of regular refreshes. Orchestration will typically involve:

• Initial import to e5 Cash Receipting of outstanding transactions for a business system
• Cash receipting will receive cash in respect of those transactions
• Export from Cash Receipting of Payment details to the business system, to clear the debt record in that system. (See later note on Export process).
• Next import to e5 Cash Receipting of outstanding transactions for the business system. 

The actual transaction format taken on for each business system (Fund Type), is essentially the key transaction details, which in summary are:

• Ledger and Account reference to identify who the transaction is in respect of. (Up to 2 and 12 characters respectively).
• Transaction reference to identify the specific transaction. (Up to 16 characters).
• Transaction Date to further qualify the transaction
• Amount Outstanding of the transaction.
• Currency Code may optionally be defined if the value is other than Base currency.

Translation of customers will occur to allow all the various customer account references within each of the systems being supported by Cash Receipting to be linked so that it is possible to retrieve all account references for a customer, across all Fund Types, from entry of a single valid reference.

Exporting Data

Controls on the Fund Type, allow definition of an e5 device definition, representing a file, to which payment details will be written for export back from Cash Receipting to that business system.  The update indicator on the Fund Type may also be set to update the file in immediate, or delayed mode. In both instances, as receipts are taken a record is written for potential export. The difference is that

• where the update indicator is set to immediate, each transaction generates an individual jobtagged file to the file name defined on the Fund Type.
• where the update indiactor is set to delayed, each transaction is appended to a master file.

The difference is really to allow for instances where frequent update is required to a business system, (i.e. series of small, individual files), and also where it is sufficient to update the business system at more pronounced intervals, (i.e. the master file approach that grows larger as records are appended to it.).

In both instances services work will be necessary on site to pick up the output from Cash Receipting, apply it to each business system and manage any deletion of files that may be necessary.

Worked Example

The following is a worked example of daily activities that a cashier will undertake and the bank reconciliation tasks that would be required:

The Cash Receipting module assigns a bank reconciliation code in the following format:

PNNNNNNNNNMM

Where:

P  = A one digit figure representing the Payment Medium

N = A nine digit end of day system reference comprising a prefix of CR and a seven digit number

M = A two digit figure representing the Payment Mode.

The Payment Mediums available to Cash Receipting are

The Payment Mode mentioned in the formatting of the Bank Reconciliation code above is only used where the Payment Medium is defined as EFT Settlement via Third Party. 

In order to support the allocation of Bank Reconciliation numbers as described above the system is using the following controls / fields and tables:

Payment Mediums

Payment Medium is a field created and held against each Payment Mode defined. While Payment Mode is a user defined code, allowing organisations to perhaps differentiate between various types of Credit Card, the Payment Medium is a higher level attribute defining the type of bank processing connected. The payment mediums available as described above are:

End of Day System Reference Numbers

End-of-Day (EOD) System Reference numbers are created and held against both the Cashier Group and Terminal ID.  Each EOD Sys Ref held is to be a unique number in the CR module.

The EOD Sys Ref held against the Cashier Group will be used by the system where the payment mode used on the receipt record is a manual deposit.

The EOD Sys Ref held on the Terminal ID table will be used by the system where the payment mode used on the receipt record is an electronic deposit.

Terminal / Merchant Number

A Terminal / Merchant Number field is included on the Terminal ID. This field is to hold either the Merchant Number or Terminal Number as supplied by the clients bank.

Bank Reference Number

A Bank Reference field is included on the Cashier Group.  This field is to hold a deposit slip number or some other user entered code that can be received by the bank and returned on the bank file. The intention here is that each value entered by the cashier overwrites a previously entered value (a history of values is not kept against either the Cashier &/or Bank Location).

Cash Receipting Reconciliation Controls

The following information will be held:

• The Bank Reference field (will be either a location, or other used entered code, or the Terminal ID code depending on whether the payment medium is manual or electronic)
• The End-of-Day System Reference field (will be added and updated to this table as part of CR data entry processing)
• Each of the Payment Modes set-up on the Payment Mode table
• A cumulative Payment Total for each payment mode.

Overview of Reconciliation code assignment

When a Cashier closes a session in Cash Receipting, in addition to the cashier controls being updated with logoff date & time and cash in, cash out, closing float values, the following will occur:

• A Cash Draw Tally report will be printed where requested.  The cashier will be asked whether he/she wants the Cash Draw Tally report printed as part of the close cashier session process.
• A new process will cater for the End-of-Day Cashier requirements.  This:

1. • Prints the Bank Deposit Listing report by Cashier Group (can be reprinted where required).
   • Settles the EFTPOS / Credit Card / Debit Card transactions with the bank.
   • Increments the EOD Sys Ref value held against the each of the Cashier Groups and Terminal IDs.

Detailed Examples of Reconciliation code assignment

An organisation has 2 collection points (or bank locations) - Collection Point A and Collection Point B .

Pre-requisite information is

The main assumption in the detailed example set out below is that both Collection Points A & B settle their EFTPOS/ Direct Debit/Credit Card transactions at the end of the working day on 1/12/03.

Receipts raised by Cashier No. 1 at Collection Point A on Monday 1 December 2003 are as follows:

Receipts raised by Cashier No. 2 at Collection Point B on Monday 1 December 2003 are as follows:

Values held on the new CR Reconciliation Control table after the Cash Receipting postings have occurred are as follows:

NOTE Since the Cash and Cheque receipts will be banked as one banking and appear as one value on the bank statement file, the bank statement take-on process will be modified to add the values of the Cash and Cheque payment mediums together when deriving the reconciliation code for the bank statement transaction.

Since the Visa and Mastercard receipts will appear as one value on the bank statement file, the bank statement take-on process will be modified to add the values of the Visa and Mastercard payment mediums together when deriving the reconciliation code for the bank statement transaction.

When the bank statement file is loaded into the e5 Bank Reconciliation module, the take-on process will carry-out the following:

See also

Cash Receipting Home Page