Point of Sales code 1

[yomyom]

Is there any free / available 'point of sales' code floating about? I.e. Code for supermarket teller for entering / scanning items in the shop that are being bought (why re-invent the wheel?).
Are there such routines bundled with D6 or D7, or avasilable as freeware?
yom yom.

 

[awarnica]

If you are just looking to capture a keyboard-wedge barcode scanner you need no code to do so.

If you are looking for a full application for use in supermarkets I doubt you will find any freeware out there.

Give a little more info as to what you want to do.

 

[colttaylor]

Can't offer you any complete application source code, but I will share one of my experiences. I needed an A/R and G/L application quick, so I bought one of the complete source solutions which was advertising in Delphi Magazine. It was source complete, as advertised and I made a few small modifications to make it fit my customer's expectation. Everyone was happy at first, since I had literally delivered a large, customized solution in less that a week.
Unfortunately, I had made some mistakes.
First, the source complete solution came with several modules which were not part of my customer's expectations and I neglected to comment them out or hide them in my final delivery. Soon the customer was using (and asking for support on) features which I had never even looked at. I didn't understand the software I had delivered well enough to support it, and this became a more significant problem as the months went by.
Second, the source complete solution found some bugs in their code and emailed me an update. Time to re-insert all my modifications and redeliver the software to this increasingly disgruntled customer. This lead to a flurry of new support issues, since the update included some new features and screen changes (which again, I knew nothing about).
Finally, the data files which the source complete solution had chosen was not my first choice and I ended up having to learn how to maintain, repair, compress this database, even though I never would have used it. To this day, I have exactly one customer who uses this application and database and given the amount of additional effort which has gone into that customer, I cannot call it a profitable relationship.
Those of us who can write code are blessed with a choice when it comes to selling someone else's solution or creating a solution which meets our style and technical/design prejudices. Don't underestimate the value of that blessing!

Peace,
Colt. If it's stupid but it works, it isn't stupid

 

[yomyom]

Dear Colt,
Thank you for your advise. You are absolutely correct. It would be silly to abduct someone elses code without fully understanding it etc...
I have not been commissioned to produce a point of sales code, I only wanted to have something generic and basically useful to supermarket operators. Having not done anything for them before, I was looking for the key ideas / areas that need to be coded for since as you say, we have the blessing of being able to create code.
Thanks and I look forward to you enlightening me about the key areas.
yomyom.

 

[colttaylor]

Hi YomYom,
Thanks for letting me rant in the previous message.
I was having a strange day! I hope this response will
actually be of help to you.
Although I haven't done a supermarket solution before,
I've written several Points of Sale and the concepts
are pretty straight forward.

THE SALES PROCESS
A point of sale system tries to capture what happens
from the moment that customer puts their intended
purchases on the counter, to the moment the leave the
store with them. It may be helpful to storyboard this
process...

An anonymous customer wants to buy three ITEMS.
The CLERK logs into the system and starts a new RECEIPT.
He then adds the items to the receipt which automatically
totals up the individual item prices.
He then settles the receipt by choosing a PAYMENT METHOD.
The payment method may have additional requirements
such as the entry of a credit card number or the scanning
of a gift certificate barcode. These additional pieces
of information should be recorded as part of the receipt.
Once adequate payment has been identified and collected,
the software opens the cashdrawer and prints a receipt.
At the end of each day's business, a report totalling up
the receipts is printed and a matching amount of money
is taken from the cashdrawer to be deposited in the bank.

This extremely simple storyboard identifies only four data
elements...

ITEMS : Those goods and services which can be sold. At a
minimum, items should have a unique identifier, description,
and unit price. It might also be a good idea to have a field which distinquishs goods (which you can run out of) from services (which you cant). If this is done, then the item record should also contain a quantity on hand. If you plan to support bar-coding, include a field for the UPC-CODE (which is just an indexed string field).

CLERKS : The human beings authorized to use the software. At a minimum, clerks should have a unique identifier, name and password. It might also be a good idea to have some fields dictating what the clerk is allowed to do (refund items, void entire receipts, print the end-of-day report). If a clerk doesn't have the right to do something, the software should allow (and record) the entry of a second clerk password so that administrator/managers can authorize the action.

PAYMENT METHODS : Predefined templates describing the methods by which a customer pays for the items they purchase (CASH, CHECK, VISA,...). At a minimum, payment methods should have a unique identifier and a description. If additional information should be collected during the sales process, that additional information should be identified here. For example, checks may need a check-number field. Visa may need a card number and expiration date, plus the approval code provided by the veriphone or voice-approval process. Payment Methods do not store the
actual information collected, rather they are templates, informing the software what addition information should be gathered. If your payment methods do call for the collection of additional information during the sales process, make sure to print that information on the end of day report.

RECEIPTS : A group of ITEMS gathered together by a CLERK and
settled to a PAYMENT which is of a particular PAYMENT METHOD. This is the central table of the system where all the other data elements come together. As a result of its role, alot of thought should go into it. At its simplest, it should have fields for a unique identifier, date, time, and clerk-id. It should also have multiple fields for holding item-ids and one or more fields for identifying payment methods. Finally, the receipt should store the dollar amount involved.
Some additional things to consider...
If you cannot predict the maximum number of items which will be added to a receipt, then you should probably use two tables (one for the fixed elements of receipt such as unique id, date and time... and the other for the items sold). If you cannot predict the maximum number of payment methods which may be used to settle a single receipt, you should again use two tables for this part of the process. If you do end up with multiple tables to represent your receipts data element, link them together with the receipt's unique identifier.

This is an extreme simplification of a general point of sale. I have not covered the necessary interfacing with hardware (cashdrawers, receipt printers, barcode scanners, mag-swipe readers, pole-displays, etc...) nor have I discussed the user interface which can range from keyboard entry to touch screens. If your items have quantity on hand figures then some method to receive new stock and a way to enter stock level adjustments for loss or spoilage will be needed. You may want to track your customers, offer discounts and preferred purchaser features (free candy bar on every tenth visit). Customer contact (email) can grow from there while a complete stock management system (predictive ordering) can grow from the receive stock feature. There will be no end to the number and variety of reports which can be added. The possibilities exceed the infinite!

I think you can tell that I like POS work. I'm currently working on one for my business and another more revolutionary system in my spare time.
I hope this has been of some help and would appreciate your keeping me informed of your progress and insights.
Good Luck and Peace,
Colt
colt@computergolf.com If it's stupid but it works, it isn't stupid