This project is one I did recently for Ruby Tuesday, and as such, I don’t have any source code for it (as this is not public domain).
In an attempt to better market their Garden Bar, the decision was made to implement a self-serve Kiosk for take out Garden Bar orders. Our current system was technically capable of handling this, but our Marketing team wanted a completely new look for this, and this was something no one on my team had done yet.
The primary challenges in this project came from two things: managing requirements, as I had people outside my department consistently suggesting changes, and achieving a working result within the constraints of the Micros RES POS system (which while flexible, is not as flexible as I could have used here).
Creating Custom Touchscreens
Though my group modifies existing touchscreens, or creates new screens with an existing template, we hadn’t fully created a screen from scratch. What modifications we had done in the past were through a graphical “drag and drop” style utility provided by Micros, but this utility only allows you to assign a template and add/remove buttons. The template controls the major parts of the touchscreen (where buttons can be added, where alerts and prompts show up and etc), but there was no option I could find to modify this.
After a bit of research, I found that the templates themselves were defined in a text file (OpsDisplayUser.cfg in the RES\Pos\Etc folder if anyone reading this might find that useful). This file doesn’t follow a format I am familiar with, and I have absolutely no documentation for it. It became a matter of observing differences between templates, and then spending a little time in trial and error on my personal lab. Eventually I was able to determine enough of it to make a template that suited this project (and am in the process of documenting what I have learned for the rest of my team).
The second part of this comes from the fact that default screens are revenue center specific. The requirements called for different screens at credit card authorization, and this was not possible without expanding our system. Creation of a revenue center is not the most difficult thing I have ever done, but it is very detail intensive, as a revenue center has a large number of options to be set (via SQL Update\Insert statements).
Automating Sign In, While Keeping Things Secure
The other major challenge involved here was making this station sign itself in automatically without presenting new opportunities for employee fraud. The station itself was tied to the new revenue center, and offered no access to anything else, but creating an employee account to drive this station has the potential to allow the employee account to be used on other stations, for more “creative” purposes.
In the end, I was able to script the employee to automatically sign in when the workstation starts, which proved to handle the majority of cases, keeping the ID hidden from the store level employees. Again, this is something that Micros doesn’t properly document, so I had to do a fair bit of research on my own to figure it out (apparently RES 9700 uses the same scripting language, and is fully documented, though not all functions are available on RES 3700).
Recent Comments