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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Micros 3700 - Auto clock out employee after 8 hours 1

Status
Not open for further replies.

Serenitee

IS-IT--Management
Oct 24, 2012
30
US
Hi,

I am trying to come up with a way to have our 3700 automatically clock out certain employees (salaried employees) 8 hours after they clock in. If I can get it working it will allow us to use a budgeting component of our above store reporting system (which would make my boss very happy). I've bumped my head against it a few times and feel like I am missing something obvious.

Any advice/guidance would be most appreciated.
 
I wish I could share the getdba tool with you but I was expressly forbidden from sharing that with anyone. Have you tried regular old micros as the dba? I can't remember what Micros normally used for DBA.
 
I totally understand, I appreciate all the help you've been giving.
I'm friendly with one of the techs that worked on our installs and he said the same thing about the tool. Supposedly since about the time that Oracle purchased Micros (roughly since V5) they have been using distinct passwords, but that may just be a rumor. Just out of curiosity {ahem} do you recall if the tool is named getdba.exe?
 
It most definitely is named getdba.exe - I don't mind describing it. It requires that you turn off integrated login if you're using it, and then basically enter the username and password for a property expert account, from which it then produces the dba password.
 
I wouldn't mind helping you retrieve that if you can think of a way to do it that doesn't involve my posting a "DO NOT EVER SHARE!!!" tool on the forums, lol.
 
You mean something like an alias I gave myself just for today?

tool at serenitee dot com
 
I've reached out to you - no idea if our corporate firewall blocked me or not.
 
Looks as though it was probably blocked since it was an exe, perhaps if it was zipped? I really appreciate this btw.
 
Well, its possible my outgoing was blocked because while I didn't have an exe on the email, I was sending an email somewhere unknown. We have very, very tight security. If you didn't get my second one I'll email you from my personal computer, by remoting into my home computer. Corporate security at its finest.
 
Hate to say it, and not that there are any nefarious reasons in this instance, but we're getting a little bit shady here.

Have you looked into using micros.sp_UpdateTmClkInfo to enter time clock adjustments? You could add a "salary shift" reason code to pass in and identify these adjustments. That would make this more like a ledger adjustment that leaves a record and nets out to the desired result, rather than an erase/rewrite, which borders on compromising data integrity.
 
I agree that using a built in function is likely the way to go just because it makes it a lot easier to keep things from breaking on you. I definitely shy away from ever directly editing tables like this. I'm assuming though that that stored procedure can't be run from the custom/custom account because it is still updating the time_card_dtl table. It is a relatively straightforward stored procedure though, so I'd recommend taking pmegan's advise and using it. Plus you'll be able to account later what exactly did the editing - if someone went in and changed it themselves, or if there is a glitch in the script, for example.
 
The custom user won't have privileges to run this. You'll have to add that account to the reports group. That will allow execution of most stored procedures, but still disallow direct editing of the detail tables. That's something you'll need dba for though.
 
Just to give an example of why directly editing a table can be bad, we had a Micros tech working on one of our systems once and he directly edited some of the chk_dtl table information. I have no idea what exactly he was going for, but he managed to produce a situation that completely prevented any totals procedures from posting. It turned out to be a minor, easy to fix thing (I got dragged into it when Micros told our tech he was on his own, after being the ones to break it in the first place), but it definitely illustrates why directly editing tables, without a complete understanding of absolutely everything going on, can produce disastrous results. The site couldn't run any sales reports during this time because all of the reports obviously have to post their totals!

So yeah, use the stored procedure for safety.
 
Yeah it definitely looks like writing to the table is bad idea on multiple levels. [scraps that idea] I hadn't looked at the time clock adjustment function, I'm in that odd (yet common to the IT world) place where I do not know, what I do not know, when it comes to Micros (for example: micros.sp_UpdateTmClkInfo). Before Oracle I could get Micros techs to share at least a bit of their knowledge (and what small bits of documentation they could), but not since (which is why I'm so happy this forum exists). As 'all things micros' makes up only 10% of my job description I usually get pulled away just when some item or other is starting to make sense to me.



 
Anyone know how micros.sp_UpdateTmClkInfo reacts if it gets passed a clock out time which is in the future?
 
I would imagine it works fine given I'm pretty sure its the same procedure that manager procedures and payroll preprocessing call, neither of which I've ever seen complain about future dates.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top