This blog is about tips for creating an alert system for data entry errors.  Typos or incorrect entries can become big problems later on if they are not caught.  A proactive approach to addressing data entry errors will make life so much easier for everyone involved.  One way to accomplish this is to develop processes that can notify users and IT staff of data issues.

An Alert System

Oracle has its own ‘Alert’ process, but there may be more efficient ways to accomplish this type of notification.  Tools like Microsoft’s suite of database, reporting, and integration applications is one such example.  At a high level, we will outline some of the major benefits of this type of alert system and how it could be setup.

First, let’s go over a situation where this type of alert would be useful.  Imagine a system that checks for purchased items that don’t have their cost assigned yet.  If these items were to be purchased and received, then the lack of a cost value associated to them could cause accounting issues.

Benefits

  • Email notifications to specific email recipients.  The data returned by the alert could be either attached to the email as a separate file (e.g. .xlxs or .pdf) or embedded within the email itself.  Embedding the data in the email has the advantage of not requiring the recipient to take a second step to open the attached file to see the records with issues.
    • Examples of this might be order entry errors on a specific sales order.  Alerts could be sent out to the specific Order Admin who created the order, and an an Order Admin manager could be sent a consolidated list of all orders with errors.
  • A run history of the alerts and the data returned.
    • Useful when trying to troubleshoot various issues related to the alerts and for users to reference after the fact.
  • A web interface to allow more visibility to users so they be more self-sufficient in getting information.

Alert System Elements

  • A database which would contain the main components of the system.  This includes:
    1. Tables for housing queries that run against the ERP system to look for errors.
    2. Parameters that these queries use, metadata related to each alert, such as its name, description, owner, status, schedule details, and recipient emails.
    3. The alert run history, and tables for storing any runtime errors encountered.
  • An integration tool to connect to the ERP system and manage the execution, email delivery, and monitoring of the alerts.
  • A web interface that could access the alert database to allow for easier editing and viewing of the alert setup data and viewing of the run history.
  • A reporting system where on-demand versions of the alerts could be setup.  Allowing ‘report’ versions of the alerts to be accessible to the users comes in very useful for two reasons:
    1. It allows the users to manually run a report to verify that they’ve ‘fixed’ the issue.
    2. The reports are very useful for both users and IT in the initial development of the alert.  The report version can be used to validate the alert logic before setting up the actual alert.

General Advice

  • Make sure the alert emails clearly state why the recipient is getting this email, what the issue is, and what action they need to take.
  • Have a clear definition of the differences between an alert and a normal report subscription.  Alerts are in contrast with report subscriptions where emails are sent out on a schedule.

Conclusion

Early error detection is a simple way to prevent complicated issues from coming to fruition at a later date.  The use of a proactive alert system can save untold hours of aggravation and time, both for IT and the users.

Learn More