Touch Screen POS (No keyboard)

[gregorj]

This is the golf course solution I recently spoke about. I have finished all the layouts and navigation and I think I have a handle on the printing of receipts and daily reports. Where I need your collective guidance is the scripting of the flow of a typical transaction as follows:

Golfer wants to play 18 holes of golf and rent a golf cart. Normally he would present the cashier with a membership card which the cashier would scan. The 5 digit bar code (a Unique number) would be input on the transaction table layout as a new record in the member_id field.

The program must first check to see if this unique number has been used today and if so, the cashier will make a Yes/No decision to allow the card to be used again today. Each new transaction is not only datetime stamped but issued a transaction number starting with 001 at the beginning of the day.

If the member "forgot" the membership card but knows the 5 digit number, the cashier can input the number using the on-screen keypad which will be entered in the member_id field.

The cashier would touch the button on the layout for "18 holes plus Gas Cart"

OK - the member is a student which is one of many profiles that affect the price paid. The 3 digit profile for a student playing 18 holes is 103 for a price of $20.00. I believe this would be a lookup? ...(the fees table shows 103 = $20.00 etc.)

The gas cart is a universal price no matter what but it is a seperate entity in that it must have its own place on the receipt given to the customer plus shown as a seperate summary charge by its own 3 digit code for the daily report. The price of the cart rental is $ 20.46 plus tax $1.54 = $ 22.00

There is room on the transactions layout to show all the fields I mentioned here plus many others...

but I've gotten long-winded and I've probably overstepped my ground.

Thanks for reading this...thanks for responding.

Greg

[Ender]

In general, scripting a process follows how the process would be done manually (step-by-step). So if the process should start by finding the membership#, start the script by entering Find Mode and waiting for user interaction. Then proceed through each thing that happens (including all the branching for different conditions).

The specifics all depend on how you want the process to work, and on the particular layouts and structure in your solution.

The pricing should be based on lookups from another Fees table. You might also make the Sales Tax rate a lookup or auto-enter calc, so it can be changed in the future without changing existing data.