Self check out? - And a few feature ideas of my own.

[ZeeMan]

Ok, I'm sure that Dale has much better things to do than design a self-checkout function but I am going to ask anyway.

I would like to see a self checkout function either built into the program or made as a seperate program. My friend has a store that is kind of medium-ish that is quickly growing out of their current software (some quirky little program that was coded by his cousin, I think). I have told him about DHPOS and he has been doing some testing and he likes it. However, before I got him to switch, his cousin (or whoever) had been working on the program and was developing a self-checkout function for the program.
Here is what the self-checkout was going to be (I have changed it around to suit DHPOS):
First, the user comes up with his/her items and then pushes a "Start" button on a special keyboard (such as the one found here: http://www.fentek-ind.com/keypad.htm#kpp24ps).
Then, it says to start scanning your items. As you scan your items it automatically shows the total and other information. If you have an item such as produce or meat, you can push a special button that says something like "No Barcode". This is where it gets a little fuzzy, the plans were to either have it go through a process similar to the "Groups" function on DHPOS except with sub-menus, or, you would enter the code for the item.
After you scanned or entered all of your items, you then push the "Continue" button which then asks you which form of payment you wish to use, etc. When the system was originally designed, they planned to have built in payment processing for credit cards and checks and such. However, since this is not possible, I figured the best option would be to have an attendent watching over what was happening and when a user needed to pay, he or she would walk over to the attendant and show their recipt. Then, the attendant would then process their payment appropriately and send them on.
The attendent would have a special workstation that has a section for each terminal and can see what each user is doing and if they need help. I would reccomend that you limit the number of terminals shown at once to about six.
There is a list of people who have checked out that shows how much they need to pay and also lets you view information about that sale such as how they want to pay and what items are in their cart. I would probably set up the system so that when about 20 people are waiting to pay, the system stops letting people begin to checkout.
The point of limited the attendants involvement is to ensure that the attendant can quickly get the line moving and avoid any hassles.


I know that there are probably a lot of holes here but this is the main idea of what they want. It's pretty complicated but you don't have to have all the features right away.

I know that my friend could probably just use a programmable keyboard that has none of the exit keys available but the interface is more designed for a cashier than a user.

[ibmsystems]

Ok, I'm sure that Dale has much better things to do than design a self-checkout function but I am going to ask anyway.

I would like to see a self checkout function either built into the program or made as a seperate program. My friend has a store that is kind of medium-ish that is quickly growing out of their current software (some quirky little program that was coded by his cousin, I think). I have told him about DHPOS and he has been doing some testing and he likes it. However, before I got him to switch, his cousin (or whoever) had been working on the program and was developing a self-checkout function for the program.
Here is what the self-checkout was going to be (I have changed it around to suit DHPOS):
First, the user comes up with his/her items and then pushes a "Start" button on a special keyboard (such as the one found here: http://www.fentek-ind.com/keypad.htm#kpp24ps).
Then, it says to start scanning your items. As you scan your items it automatically shows the total and other information. If you have an item such as produce or meat, you can push a special button that says something like "No Barcode". This is where it gets a little fuzzy, the plans were to either have it go through a process similar to the "Groups" function on DHPOS except with sub-menus, or, you would enter the code for the item.
After you scanned or entered all of your items, you then push the "Continue" button which then asks you which form of payment you wish to use, etc. When the system was originally designed, they planned to have built in payment processing for credit cards and checks and such. However, since this is not possible, I figured the best option would be to have an attendent watching over what was happening and when a user needed to pay, he or she would walk over to the attendant and show their recipt. Then, the attendant would then process their payment appropriately and send them on.
The attendent would have a special workstation that has a section for each terminal and can see what each user is doing and if they need help. I would reccomend that you limit the number of terminals shown at once to about six.
There is a list of people who have checked out that shows how much they need to pay and also lets you view information about that sale such as how they want to pay and what items are in their cart. I would probably set up the system so that when about 20 people are waiting to pay, the system stops letting people begin to checkout.
The point of limited the attendants involvement is to ensure that the attendant can quickly get the line moving and avoid any hassles.


I know that there are probably a lot of holes here but this is the main idea of what they want. It's pretty complicated but you don't have to have all the features right away.

I know that my friend could probably just use a programmable keyboard that has none of the exit keys available but the interface is more designed for a cashier than a user.

ZeeMan> This is already in devlopement by me and is progressing towards the beta stage very quickly and has taken piroty #2 in my To Do list (My blog is #1 *I love blogging its fun and gives me something to do besides vb

[PWEB-Mike]

Oh boy....now he's going to work on it.....Last I heard it was a dead topic..

-00-
Mike
http://pweb.info

[Dale Harris]

IBMsystems,

You know it is not really all that helpful to copy the text of the message you are replying to when you are replying to the post directly above yours. Or even if it is two or three posts earlier.

We can all pretty much figure it out.