Indirect Tipping, a fairly common practice in the casual dining sector, is essentially tips being transferred from a server to other support staff in the front of house (hosts and bussers for instance). Think of it as tip sharing. We had designed a system to accomplish this automatically years ago, but it had several bugs and our needs had changed as far as the constraints. So, in this project, I rewrote the entire process, allowing for a large range of customization.
Requirements on this were anything but simple. We needed to be able to collect tips from certain job codes, on certain items, and only in certain scenarios. We need separate rules for bartenders and servers for instance, and options to include a check based on the time it was opened, the time it was closed, or any overlap.
In the end, I designed a solution that is mostly database driven (as out previous solution was ISL driven using Micros Tracking totals and a lot of hard coded values). The major components are:
- A table that defines the tipping ruleset
- A table that links job codes to a ruleset, and defines how sales should be collected (based on check start, check close, or both).
- A table that links menu items to a ruleset (by family group, major group, or name, with the option to exclude by those criteria as well).
- A view that calculates sales data by employee and shift for the current business date, based on the tipping rule sets defined. This uses a handful of functions and stored procedures to make things more manageable.
- A stored procedure that writes the data to a table for export at end of day (essentially saving the data for that shift).
By simply changing the contents of one of the configuration tables, we can add/remove items, job codes, or change the amount a job code is deducted, while still fixing the bugs we were dealing with before.
Recent Comments