|
<quote>...payroll which is a batch process if ever I saw one.</quote> depends on the application... if you swiping time on a shop floor, and a persons may swipe in/out of many orders in a day, real time with validation may be required (like swipe in to a closed order?). Realtime also allows you (with good equipment) to send back to a digital display a person's accumulated time, so they can keep track of their "40 hours". Saves all the headaches and "time" of changes required after payroll run. Kronos, GFC, and perhaps some others have realtime systems that work well with the 400. btw- the hardest part of the last time/attendence project I did was getting the users and managers to sign off on a set of specs (in 32 states, some shops union, some not). Rounding, swipe in early or late, swipe out early or late, lunch/no lunch, clocked into a shift when payroll ends (Fri-midnite), clocked in during daylight savings shift, minimum/maximum shifts, failure to punch in after lunch, corrections and who can make changes, etc, etc. Walk the users thru the consequences of every rule! Code nothing till they all agree and sign off on it. And if you have a site in California, I'll pray for you. They change the rules quite often. have fun, jim franz ----- Original Message ----- From: <jpcarr@tredegar.com> To: <midrange-l@midrange.com> Sent: Friday, November 23, 2001 8:07 PM Subject: RE: Time and Attendance > > Dave's on the money. You can get what ever hardware for the swiping you > want. I can go into an ASCII file > just fine on the IFS. I can write a 50-100 line RPGIV program to read > that PC file realtime and process it > and update REAL DB files with it. Already doing that with an Inventory > system we did. I read the ASCII file > from the file that was loaded to the IFS from the scanner gun. No sweat. > > The consultants are like children, Give them a hammer and suddenly > everything needs to be hammered. > Give consultants a way to make money on what they know(ie PC solution) > EVERYTHING needs to be a PC > solution. > > John Carr (I'm a consultant BTW) > > > > The only thing that you missed out on is that our 400 Payroll application > > is also being upgraded but this could be taken off the 400 as well... > > If they're only looking at PC solutions then you're going to end up with a > PC solution. Why is the payroll being upgraded? Does it not do the job, or > is it simply not a Windows app? > > As far as swipe card input goes, I've worked with a system that was > integrated into J.D. Edwards World (for meal accounting rather than payroll > though). Basically the badge readers build ascii files that you then import > into your 400 through Client Access, ftp, or whatever. It's not a big deal. > You can have more sophisticated systems that send wireless data transaction > by transaction, but I can't imagine you'd need that for payroll which is a > batch process if ever I saw one. > > Dave... > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.