|
|
|
|
|
|
This screen allows a cashier to reconcile a till with the entered payments and the actual cash received. The cashier enters the breakdown of the money in the cash till which is then compared with the system calculated float value to determine if an imbalance over or under has occurred.
At any time, the cashier may ‘save’ this reconciliation by selecting the Intermediate Cash-Up action. This will record the reconciliation in the Till Session Cash-Up table and allow the cashier to continue entering receipts for the same open Till Session. If the cashier re-enters the screen once an Intermediate Cash-Up has been performed for this till session, it can be copied by using the Retrieve action and the Cash-Up can continue from when the entry was saved. Note the retrieve action will rebuild the actual payment totals (in case new payments were made since the last Intermediate Cash-Up was performed).
The cashier has options to perform:
If an Imbalance exists, the cashier (or supervisor if authorisation security has been defined) will then accept the imbalance by logging into the screen and an over/under posting can be made to account for the difference. The till session will then be closed along with any attached open cashier sessions that are currently using that till and a till session activity report will be produced (in a similar manner to the cashier session activity report). Once closed, the till session is then available for selection by the bank deposit listing process to identify the payments that require banking and for entry of the paying-in slip references when using the pseudo-bank posting indicators on screen MMHO. Entry of the paying-in slip references may optionally be entered at the time of cash-up thus already auto populating the references on the MMHO screen.
A Till session may be authorised later by a user performing an intermediate cash-up and the supervisor using the till session list screen MMHQ to action the authorisation of a full cash-up. If SSO is in use, then the in-line authorisation (via the authorise window) will not be available (as there is no actual user id that the authoriser can enter). In this situation, the authoriser would sign on at a different terminal using SSO and navigate to the till session list to perform the authorisation.
Reconciliation in non-base currencies can also be made by selecting the currency required (using the left/right arrows) and entering the denominations for that particular currency. A reconciliation is required for the base currency (even if it’s zero) but other currencies can optionally be reconciled.
For this release 5.5, the denominations for currencies ‘GBP’, ‘USD’ and ‘EUR’ can be entered. Denominations for other currencies are not broken down and can only be entered as a single value and must be accumulated by the cashier (if currency ‘CAD’ (Canadian Dollars) was received, the cashier will have to add the notes/coins received into one value e.g. 4,523.12 CAD for comparison against the received Canadian payments). Note, if one of the pre-determined currencies above was defined in e5 using a non-ISO standard (UKP), then an entry must be made on the user-defined table 01/QBC01 (BASDA Currency definition) that translates the e5 currency code to an ISO standard currency code (so in this example, UKP would translate to GBP).
For non-cash payments, the payments are broken down by a payment reconciliation indicator. Each payment mode has this indicator present (which is a pre-determined code from ‘1’ to ‘9’) and the non-cash payments are accumulated by this reconciliation indicator to produce a total on the cash-up screen. These totals can then be reconciled with the actual totals from the till to determine the over/under position. A mnemonic group CRPAYREC can be amended to change the description of these indicators on the cash-up screen to display a more meaningful label alongside the accumulated payment value. However, only the non-cash payments which have a medium of Bank Deposit will be included in the banking totals. The other non-cash payments are only used for reconciliation purposes.
A partial cash-up can also be made by entering the banking values (and optional paying-in references) against each reconciliation group, the last row on the list being the partial banking value for cash payments. Entering any of these values will ensure a partial banking takes place and an extract for the bank depositing listing process is made to identify the amount of money banked.
If a Full Cash-Up was taken, then authorisation may be required depending upon the settings on the till. This authorisation (or duty separation if set) will either require the user to save the current Cash-Up as intermediate to then allow another supervising user to authorise a full cash-up afterwards or on the same screen, allow the authorising user to enter their e5 user-id/password to confirm that a full cash-up can take place.
Once a full cash-up has been performed, the till session is closed and a till session activity report is produced showing a summary of the above reconciliation screen. At this point, the cashier may also change the float value (subject to security) if they require a new float value to be used when creating a new till session for further receipts. Any differences to this float value will be reflected in an Imprest Account in GL.
The bank depositing listing process can now be run to extract the above till reconciliation (plus any other outstanding till cash-ups which have not yet been extracted) to produce the BDL report and create the entries for the reconciliation code matching screen where the paying-in slip references can be entered (if not previously entered during cash-up).
If an imbalance was detected (by the presence of the message ‘Totals do not balance’), then the authoriser may set the correct GL Postings flag to allow the system to generate an adjustment posting to GL correcting the balance in the bank account (or pseudo bank account) and posting the difference to the Reconciliation Account. If not set, then no corrective postings will be made. Comments may also be recorded at any point during the reconciliation if required.
The Till code for which the search is being submitted.
The currency associated with the Till code.
Enter Text that you may want to record as a brief note pertaining to the reconciliation check. It is then displayed protected in cash up history enquiry mode.
Cash (values)
Denotes the cash values received.
Non Cash / Reconciliation (all fields)
The entered Cash Reconciliation Value. On a Cash Up the user may enter either a count of the currency denominations in the till, for example 5 x 5 denomination notes and so on, or alternatively they may enter values. Where they enter detail of this nature the total that it equates to is displayed in this field. Alternatively they may simply enter the cash value they have counted in this field.
When enquiring on a Cash Up history this displays the value they entered as being the cash count.
The following two fields are relevant to each of the Non Cash / Reconciliation fields.
Enter the value being taken out of the Till to be banked. This will be display protected when in enquiry mode on cash up history.
Optionally enter the paying in reference that will be used to update the Reconciliation code on GL postings if known at the point of cash up. Alternatively the MMHO Reconciliation code update process may be used.
Banking
Represents the Closing Float value of the Till on a Full cash up. Normally this would be the same as the opening float, but may be changed during a full cash up.
Authorisation
If an imbalance is detected on cash up between the system expected totals and the cashier entered totals a message is output in red text warning of the imbalance. The authoriser may set the Correct GL postings flag which will lead to the system generating an adjustment posting to the GL.
This will impact the pseudo bank account (or bank account) and a Cash Receipting reconciliation account. If not set, no GL corrective posting is made to account for the imbalance.
This Cashier Group is used to identify the Bank Account to be adjusted when posting imbalances or float changes to GL. This defaults to the cashier group held against the till but can be changed.
Once the cashier group has been identified, then the bank code/GL fund type can be derived and from then on the bank location/bank accounts can be identified.
If not described in this topic, click on a field and press F1 to view help. See Common Fields for more information.
Fast prompt allows you to quickly view a list of options for certain fields.
See Using the Command Line on opening the screen without going through the menu.
See also
Externally Raised Transactions List
|
© Advanced, Jan 2021 |
|
