 |  |
How To: Manage Ad-Hoc Employee and Vendor Statements
1. BackgroundAd-Hoc statements can be used to pay an employee or vendor in circumstances where a normal pay period statement would not suffice. The Ad-Hoc statement functionality allows you to issue a statement based on whatever dates you wish.
The Ad-Hoc statements should be used with caution: if the user is not posting statements, duplicate payments can be issued if not tracked with a fair bit of diligence. Be aware that the whole purpose of creating pay statements by pre-defined pay periods (rather than on an ad hoc basis) is so that the user cannot accidentally generate a statement that includes tickets for which a vendor has already been paid. So, if you choose to use ad-hoc, you need to be aware that the system will not prevent you from having the same ticket appear on multiple statements because you happened to select a date range that overlapped with a statement that you already created and gave to the payee.
Note: ad hoc statements are only applicable for load-based payments and miscellaneous entries. They do not include hourly based payment or production slip payment.
2. Steps
Enable Ad-Hoc Statements in Basic Setup
The Ad-Hoc Statement functionality is not available by default but must be turned on by a switch in Basic Setup.
You must be logged in as an administrator in order to enable the Ad-Hoc settings.
3. Working with Ad-Hocs
To access the Ad-Hoc statements, navigate to Reports | Ad Hoc Statements and either choose Vendor or Employee. A Filter selection window will pop up:
The filter will allow you to narrow down the contents of the statement based on block (tract) and destination. After selecting the criteria, click OK and the report will appear in the grid. For those who use posting please be sure to review the section below on posting with Ad-Hocs.
If the grid for each vendor is satisfactory, the set of statement you are reviewing can be saved by clicking Save/Exit. When the statements are saved, a unique statement number is assigned to each statement. You can then recall them at any time by navigating to Reports | Vendor Statements | By Vendor, Statement #. Select your vendor and click OK.
Note: if you click Cancel (instead of Save/Exit), the statement(s) will not be saved, and no statement # will be assigned behind the scenes. If you realize that you've made a mistake, you should use the "Cancel" button rather than the Save/Exit button to leave this window.
Once the grid is up you can scroll through the Statements for the Vendor you have chosen. Note that the Ad-Hoc Statements have a suffix of '-Spot'.
If you wish, print the statement from the grid by selecting File | Print Current. This will print the information from the grid.
4. Posting and Ad-Hoc Statements
When viewing Ad-Hoc statements, the load and time records are colour coded based on posting activities. That is, if you select a date range that includes tickets that have already been included on another saved statement, those records will appear in a different color. If the records have no colour coding they have not been posted.
If the records are green, the records have been posted on another statement and will not be printed or saved on the current statement. (Records will appear green regardless of whether loads were posted first to an ad hoc statement, or to a regular statement. The example below shows the case where a regular statement was posted first, and the ad hoc shows green records. It is also the case that if an ad hoc statement was posted first, the regular statement would display the overlapping tickets in green as well.)
If the records are pink, they are on another non-posted (but saved) Ad-Hoc statement that overlaps. (The pink color will only be invoked if the ticket was originally on one ad hoc statement, and you are now including that ticket on a new ad hoc statement. In this case, the ticket is "stolen" (that is moved) from the original to the new ad hoc statement.)
Finally, If the records are orange, the records need attention because they are at risk for not having been paid by a somewhat obscure (but certainly possible), sequence of steps that the user may have taken. These steps involve posting and unposting in a particular sequence. This scenario is described later in this document.
As stated
earlier, there will be no color warning if you paid a person using a regular
pay period statement, and then created an ad hoc statement that included
some tickets that were already included on the regular statement. The
user needs to be careful when using ad hoc statements to manage this risk
with their own processes.
The first example shows a grid for Jr Maxwell for the Dec 16-31 pay period. The statement has been posted. The second grid shows an Ad-Hoc statement grid for Dec1-31. As shown in the screen shots, the loads from the 16-31 appear green on the Ad-Hoc grid indicating they have been previously posted (on a regular statement).
The second example shows the loads when they turn orange. Orange records indicate items that are currently unposted, and ultimately may not have been included on a vendor or employee's statement.
A scenario where the records become orange is as follows. Suppose you post an ad hoc statement for a vendor that includes tickets from the 1st-5th of the month. You then run a regular pay period statement for a period that encompasses the 1st-5th --- say the 1st - 15th of the month. Because the tickets from the 1st-5th were already included on a posted (ad hoc) statement, they initially appear in green, so that they will not be repaid on the statement for the 1st-15th. You go ahead and post this regular period vendor statement as well. Next, you realize that you mistakenly created and posted the original ad hoc statement, and you now decide to unpost it. You then re-run the regular period statement for the 1st-15th, hoping to pick these tickets up on this regular statement. The tickets for the 1st-5th will now appear on that statement in orange because they are now in "limbo." They are not posted on the 1st-15th statement because they were originally posted on the ad hoc statement. If you actually want to post them to the 1st-15th statement as well, you first need to unpost the 1st-15th statement, and then repost it. At that point, the orange goes away.
As you can see, it takes a bit of creativity to get orange records on a statement. Therefore, you should investigate records that are orange before proceeding.
The last example shows the case when pink records appear. This will occur when an Ad-Hoc is saved (not posted), and an overlapping Ad-Hoc is done. The pink records indicate that those records are being taken from the old Ad-Hoc to the new Ad-Hoc (effectively being "stolen"). In the following screen shots an Ad-Hoc is created from the 1st to the 15th. Then an Ad-Hoc is made from the 1st to the 31st. The records from the 1st to the 15th show up as pink in the second ad-hoc, as they are being "stolen" from the original unposted ad-hoc statement.
4. Other Important Points
1. If you used ad hoc statements prior to version 4.5.0, you should be aware that the old ad hoc statements (that is, those created prior to the upgrade) will no longer be accessible in the new version. You can always re-create them by selecting the same date range, block/tracts, destinations, and vendors, but you will not be able to pull the old statements up by statement number.
2. The color coding does not prevent you from having a set of tickets appear on an ad hoc statement, and having those same tickets appear on a statement generated for a regular pay period. That is, if a ticket appears on an ad hoc statement, and your date range for the ad hoc overlaps with a regular pay period, the system will still create a vendor statement for the regular period. Therefore, you should decide up front whether you will be using normal pay periods, or ad hoc periods for a particular vendor. Once you make your decision, you should stay with that decision. Otherwise, you open yourself up to inadvertently having the same ticket appearing on multiple statements (if the dates overlap), and thus paying the same person multiple times for the same ticket.
