Transaction and Process Auditing Controls with in Ticketing
The Mandalay CS Ticketing application contains a number of features and behaviours that improve the ability for the system to be audited. This includes collecting reasons for altering a ticket to recovering tickets due to system crashes. The following article describes the different options scenarios.
Events
A number of processes within the ticketing system will require that a user provide a reason for the action they are performing. Along with the reason the user may also need to provide a note about the situation.
The following events can be configured to request a reason from the user when an action is being performed.
- Alert Override
- Cancel Ticket
- Manual EID
- Manual Ticket
- Overloaded Vehicle Arrival
- Overloaded Vehicle Departure
- Price Override
- Replace Ticket
- Ticket Modification
Each event is configured with its own set of reasons that the user can use to indicate why the action is occurring. These reasons are then available for reporting in the Web Based Reporting system using the Ticket Event Detail view.
Aborted Transactions
When a transaction is started in ticketing the system will immediately generate a transaction record. For good auditability any transaction record created should never be deleted. With this in mind the Ticketing system will now either force the operator to cancel a transaction using the correct ticket cancellations or will leave the transaction as an aborted transactions.
At the Payment Tendering Screen
Normal Transaction
If the payment tendering screen is cancelled during the process of collecting the payment for a transaction and then the transaction is aborted by the selecting the In button, the system will generate a parked ticket. A parked ticket is an orange button on the vehicle in list. To remove this parked ticket the operator will need to either select the vehicle and cancel use the cancel button in the command bar or locate the ticket in Ticket History and cancel it. Either way they will need to provide a reason for the aborting of the transaction. This is specifically important if EFTPOS integration is active and an EFTPOS payment had been processed as cancelling the ticket will then force a refund.
Hotkey
Aborting a hotkey ticket will not result in a parked ticket as it is easy to accidentally select a hotkey. However the transaction will still exist but it will be deactivated , indicating an aborted hotkey. These tickets will appear in the Ticket History as a cancelled ticket.
Before the Payment Tendering Screen
To provide a consistent transaction numbering sequence the system will not retain the transaction record without an issues docket number. This record will have all details collected but will not appear in the ticket history as it no an officially issued docket.
System Crashes
If the system crashes during the process of capturing a hotkey or during the process of completing a normal transaction, then a parked ticket will be created. The operator can then chose to complete the transaction by selecting the parked ticket or cancelling the ticket and selecting the correct reason.
If the system crashes during the collecting of the transaction details it will be considered an aborted transaction so will not generate a parked ticket.