Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Aloha - Command to grind past 7 days at EOD

Status
Not open for further replies.

MisterAloha

IS-IT--Management
Jul 31, 2012
12
US
I am looking for a simple way to grind the past 7 days at EOD. A similar request was made in but I don't see the commands listed. I was hoping grind.exe would have a switch built in for this, such as "grind /date -7", but that doesn't seem to be the case.

This is to band-aid a known problem with grind not being called after editing punches, causing incorrect labor hours to be sent to payroll.

Thanks in advance for any assistance.
 
Simple? Not that I can think of. Easy to do if you're good at programming in VB, which I'm not. I've written similar programs a long time ago. Involves running a program at EOD that looks at the system date and converts it to YEARMONTHDAY format, then counts backwards to either run grind or remove GNDDBF30.XXX from each dated sub.
 
Thanks dauphin2. Other aloha utilities for reporting use the /days switch, but it doesn't work with grind. Wouldn't that have been nice?
 
Can I ask what version this is for, I've noticed the newer 6.7+, 7.0+ versions seem to initiate grind after editing punches a lot better then the older versions
 
TS 6.5.23 is the version exhibiting the no grind after editing punches. Yes, I think it's better in the newer versions.
 
This could completely destroy everything you hold dear, so use at your own risk, but...

Add a line to your winhook that renames every grind dbf in the Iberdir and subdirectories to something else, like adding an X on the beginning of the filename, or just delete them all. Then call RPT with the /days -7 argument, tell it to export some bogus report to some bogus folder. It'll need to regrind all the folders it's trying to pull data from.

The potential problems that this could cause are too many to list, but if you do this after backing the day's dated sub up to a location that isn't touched by this, you shouldn't have any problems with missing data or files. The usual caveats apply: You've been warned that this could get real ugly real fast, no lifeguard on duty, etc.

The winhook addition should look like this:

backup of dated sub for the day (and wait for this to complete)
delete gnd*.dbf files
rpt.exe /whatever /days -7

There's probably a better way to do this (god knows it couldn't get much worse), and if I come up with it, I'll post it.


J
 
I agree with dauphin2, we are actually running a vb program to delete the gddbf30.xxx of the previous seven days on mondays. but if you run a labor report proir to exporting your payroll, the ADJTIME.dbf would be correct, so another way COULD be(not tested) is to run a labor report using rpt.exe on your winhook at EOD. Never tried the winhook option since we have the deletion of the gnddbf30.xxx working.
The only downside is the few minutes waiting for grind to run after deleting gnddbf30.xxx.
 
Thanks. We have a vb script that seems to be working. We are hoping to upgrade POS soon though so that we don't have to depend on it.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top