The purpose of running an “Event Query” is to see what events have been created for a particular plant. The event query will show you the event type, the products that were affected, the plants affected, the routes affected, zips affected, the dates, estimated delivery time, recoding time, DSP comments, account status, the user id that entered the information, estimated draw and late products.
Go to the Plant Operations tab and select Event Query which is listed under the hamburger icon.
This is the next screen that you will see:
Once you select the Plant Number it will look like you didn’t make your selection. This is normal.
Select the Event Type that you are looking into. The default Event is ALL. If you want to see everything then you don’t have to do anything in this section. You can choose a specific event from the drop down list.
At this point you would need to select the dates that you want to view. The default date is from today to today. You can select a different set of dates. This is helpful if you wanted to see a whole week’s worth events that were created.
Now you have to determine the status of the accounts that were affected.
Verify all the criteria that has been entered for this query and click on the search button.
If you want to change the criteria or wipe out all the criteria and start from scratch then you can click on the Reset button.
If there were any events created for the dates that you entered they will show up on the query that you just ran. This is what it would look like. For the purpose of the document I ran a query for 05/04 – 05/04.
Event Versions:
Events can be edited. When an event is edited, a new version of that event is created. Version 1 becomes Version 2, and so on.
Why edit an event? For example, if light snow were falling at 3:00am, you might record a Bad Weather event with a delivery time of 7:00 to give your carriers some extra time. But then, at 4:30am, you notice it is snowing much harder, you may want to extend the delivery deadline later. Do this by editing the Bad Weather event you recorded earlier.
Recoding Time:
Recoding time allows gives you the ability to prevent complaints from charging penalties to carriers after an event has expired. Some reasons for using a recoding time later than the estimated delivery time are:
1. You deliver for a publisher who batches up complaints and sends them to Dart long after some subscribers called.
2. Some subscribers don’t have the paper on time when they leave for work, but they don’t report the miss until they get to the office. When they left, the event was in effect, but when the complaint was created in Dart, the event expired, so the complaint might be chargeable.
Use the estimated delivery time to inform publishers and subscribers when they can expect delivery. Use recoding time to prevent penalties later in the morning that the expected delivery time.