At the same time, I am looking at a way to delete some annoying information from de database. If someone could contact me in regards with that, it would be greatly appreciated.
My email address is jjredox@hotmail.com
azrobert: support/support will get you into the db for mostly read only access.
custom/custom will allow you to create custom tables, but you won't be able to add or edit data in existing MICROS tables, except in some minor cases. What are you looking to do?
jjredox: "annoying" information? I can't think of many legitimate reasons you'd need that kind of access to the database. Check your historical totals setup and you can see how long certain types of information are retained in the database (configurable). Your void history should be used as a tool for running your restaurant. It shouldn't be altered to remove evidence of mistakes or malfeasance.
There have been times where a manager does not claim his cash deposit at the end of the night and a few times paid outs have not been entered that I would like to go back and edit those amts. I run a vb program that picks up the amts from those tables and sends it to our Corp. office and we base all of our reporting and account ballances on those totals.
Well, you could see if the custom user has access to the tables you are looking at, but my general feeling is that it isn't a good idea to get involved in that unless you are absolutely sure of no side effects.
What about approaching it from a procedural standpoint? e.g. there may be ways to modify your EON procedure to flag imbalances (although missing paid outs should be immediately noticable with a basic cashier report...). Something along the lines of the stock cashier sequence which will print an open check report and refuse to print the cashier report while there are open checks.
If you know what you want to check for in advance, you could create a custom stored procedure that can be called from an autosequence. If it finds an imbalance, it can error, then branch the autosequence to run the cashier report again, or throw up an error, etc.
Another tactic is to simply not worry about making the corrections in MICROS. Sounds like they are cashiering issues that can be post-adjusted in your accounting system.
a lot of this is true, I still have managers that at times are complete idiods (said out of frustration) not sure how many faxes and memos it takes to make them understand that problems can not be corrected the following day like our old pos system. I would also down the road like to impliment our own gift card system and possibly populate the tables with valid cards. and be able to move groups of menu items from store to store when we do a menu change rather than reprograming them over and over.....
probably the biggest thing i would like to have access to the databases is for time keeping and editing. we unlike most micros customers process our own payroll and while i love Micros the timekeeping is very clunky and cumbersome to edit employee times. I would love to write a program to be able to edit say... all servers without having to run a report, then pull up each employee one at a time to edit.
we are not using the adp interface and I am already pulling the times and shifts directly out of the tables. but I would like to be able to do daily edits and have them show in Micros.
Well, the custom user will allow you to create your own tables, so you can create tables and stored procedures for your gift card program. Do you have SIM/PMS licenses for your locations?
Menu changes are something that should be doable without dba access. You'll want to have your object numbers synchronized across locations and you'll need to consider touchscreen placement, SLU's, etc. It will be some work, but you'll just need to weigh the cost against using something like Product Managment or 3rd party system.
Also, I think it is pretty common to use the built in timesheets and manually enter into the payroll system. But I agree, the interface for editing clockins is a bit clunky. However, I come back to the idea that if you are repeatedly finding the need to mass edit timesheets, then perhaps this is something you can address in a less technical manner. For servers, it's usually effective to require them to show they've clocked out before they receive their tips. Late clockins can be assisted by using the scheduling tools. It's a bit of a pain to maintain schedules depending on your type of restaurant, but you can disallow clocking in 15 min after scheduled and require a manager to authorize the clockin.
That said, you may find you have write access to some of the timekeeping tables. Just be aware of the dependent tables and stored procedures.
I've found its usually easier to create a table to hold non-standard info I need for reporting and a stored procedure to post to it. (The 3700 db is almost over-normalized, so you're probably going to be requiring data from multiple tables anyway.) You can then write your program to edit, report and export from that table instead interacting directly with the micros tables. This also eliminates the possibility of micros support coming back with "you modified the tables so this will be billable" every time you need their help.
I don't know if its an option for you, but my company uses FM for the balance sheets. The initial setup w/o EM is a pain, as is making enterprise wide changes, but you can set failure points on almost anything. I've got AM/PM deposits as user entry fields with a fail condition. If either one is left blank the manager can't close the day.
We also have a few procedures that can't be handled through micros. When a manager forgets or screws one up our controller has the option of hitting them with a bonus deduction. It's a bit hard-core, but the managers rarely make the same mistake twice.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.