This project was for the same client as the previous tipping solution; as the project evolved, certain issues arose from the previous solution that were undesirable.

As with the first solution, the main challenge for this project is that Micros RES 5.5 does not transfer service charges. When orders come in via the PosResApi (common for online ordering solutions), they’re typically put in under an API employee. A tip applied like this then sticks to that employee after the check is transferred and closed under whatever employee handled it.

There are actually a couple ways this was tried, some of which were pretty successful.

The previous approach was to use the PosResApi to add the tip after the order (storing the tip data in a database between order entry and check closing). The issue that we ran into there was with the actual payment process; applying a credit payment this way would not cover the tip amount, leaving the tip amount as a cash payment. This was undesirable to the client, and so another solution was devised.

In this case, I looked to the database itself; for the most part, the client uses standard reporting and the Micros Cash Management app for employee cashouts. So, rather the try to modify the check and the owning employee, I modified the employee level tracking totals (that drive reporting), and the Cash Management detail table (that drives Cash Management). A SIM interface is used to trigger this on check close, but only for the order type being used for online orders, and only if there is a tip amount (requires a specific service charge for the tip).

To adjust the data in Cash Management, the following is adjusted:

The applicable rows are selected from micros.cm_transaction_dtl using these pieces of data

  • Transaction sequence numbers from micros.trans_seq, which maps to pos_transaction_id.
  • Service Charge sequence number from micros.dsvc_def, which maps to res_item_id.
  • Receptacle sequence number, which represents a server bank of deposit in Cash Management, from micros.cm_employee_receptacle_assignment_dtl, which maps to transaction_receptacle_seq.

The transaction_receptacle_seq is then changed to the receptacle assigned to the employee, from the receptacle assigned to the API employee.

Adjusting the tracking totals involves manually removing the tip amount and adjusting the tracking count. The service charge needs to be added to a tracking total before this is possible (which is required for it to show up in reporting anyway).

The table modified is micros.shift_emp_trk_ttl_temp using these pieces of data.

  • The emp_seq of the API and employee from micros.emp_def
  • The tracking total number (as defined in the tracking group setup)
  • The shift_seq from micros.shift_emp_dtl (typically the current shift, which has no shift_end_time) for both employees.

The data is then adjusted by reducing the cnt field by the number of tips, and the ttl field by the amount of the tips for the API employee, then adding them to the employee that handled the check.

Leave a comment