any suggestions? POS system development

[TheUsed]

hi im need some information on how to go about making a business POS system... should I use vb.net or vb 6...

[westconn1]

if you need to ask that use vb.net

[RhinoBull]

if you need to ask that use vb.net

I concur that - if you're looking for a brand new fresh start then VB.Net is the way to go.

However, if you're working in the shop where VB6 is still the god then you won't have any choices.
Also, it may but not necessary be mandated by the client what language prefer - there are lots of businesses that have no plans for deploying .Net framework [unfortunately].

[TheUsed]

ok so where should i start making a POS system, what exactlly do they include.. anything really will be useful... and rhino so would you suggest just doing it in vb6... vb6 is where im strong.. vb.net im trying to learn

[RhinoBull]

...and rhino so would you suggest just doing it in vb6...

That was not what I said. Read my previous reply one more time.

[TheUsed]

sorry was more a question than a statement... and you say from a fresh start use vb.net... then you say most businesses wont deploy .net development... meaning vb.net can't be used?? so I am confused

[RhinoBull]

Just use VB.Net.

[TheUsed]

ok so with using vb.net what type of things am i looking to program.. i can observe how the POS system works at my work, as to what it does and incorporate it into my program.. any other suggestions?

[CVMichael]

The company I used to work had many stores, but the POS they had was just a client program (with no server) using Access as data storage. That brought many problems because they wanted to have a centralized database, and that was not possible with the POS they used to have.

So, in short, make a client/server POS. Every client connects to the server where they get/store data.
Also... do not use Access as your database, even if it seems to be enough at first, but after 2-3 years of data entry, you will see that it adds up to a lot of data.

[Lord Orwell]

with a point of sale system, a main decider is the system. The POS at my old job was on such a weak computer base that it ran windows 95 because 98 wouldn't fit on the media.

[bgmacaw]

Here's an article I wrote that discusses one aspect of POS systems: Tip Sheet: Configuring Restricted Systems.

Designing and coding a POS system isn't as easy as it seems. Here are some design suggestions I can offer that would apply to VB.NET, VB6, or just about any other language.

1. Don't use a MDI interface. You'll spend a lot of time trying to force a square peg into a round hole if you do this. Instead, build it around user controls and other components for greater flexibility and reuseability.

2. Design for flexibility in both your interface and backend. Changes to things like tax tables, product inventory, logos, marketing promotions and so forth are very common. Your app has to handle them quickly and easily.

3. Design your UI for people who who don't have a lot of computer knowledge. Solicit input on the design from actual users and their managers as early as possible.

4. As I mention in my article, use built-in Windows user management features and don't try to write this into your program. Whatever you do, don't allow POS users to run as local admins!

[CVMichael]

Another thing I want to add:

The client program should have it's own local database (for temporary transactions only). This is because sometimes there is no internet (or some kind of networking problems), and during this time, they won't be able to sell anything.
But if you have a local database, then during that time, you can still sell, and when the internet/network is back, the client application should automatically send the transactions to the server.
Or if there is a problem with the server, then all clients won't be able to sell anything, so having a local database for temporary transactions is pretty important.

[TheUsed]

wow thank you guys so much for all the help.. you guys offered valuable information. I'll keep you guys posted on how things go, thank you again

[leinad31]

Read up on basic accounting... to ensure that your system has all the necessary info for integration with an accounting system (which is bound to happen sooner or later).

[TheUsed]

ok thank you. sounds like i'll learn alot with making this system

[leinad31]

Yes, research is a must. So you'll be able to make a flexible, scalable design... eg. consider other payment types (credit card, gift check), discounts, tax computations, scheduled payments such as 6 mos to pay, design according to hardware (cc swiper, barcode reader), etc.

[Lord Orwell]

cc sale integration might not be necessary. Most places lease the scanning machines anyway and you could just put a 2nd pay button on the POS labeled "cc sales" and earmark the data accordingly.

[Al42]

Here's an article I wrote that discusses one aspect of POS systems: Tip Sheet: Configuring Restricted Systems.

Designing and coding a POS system isn't as easy as it seems. Here are some design suggestions I can offer that would apply to VB.NET, VB6, or just about any other language.

Very good suggestions - sounds like a lot of hard-won experience. I'd like to add a couple of points:

Keeping the database structure IN the database can make it easier if the database structure has to be changed. You don't have to rewrite the program, you just have to update the data in the tables that hold the database structure. (This is not entry-level coding, but neither is a POS, to begin with.)

3. Design your UI for people who who don't have a lot of computer knowledge. Solicit input on the design from actual users and their managers as early as possible.

I don't just solicit their input, I let the user design the program. I just change their design into something the computer can execute. If they want X to be filled in with the last 3 characters of Y when Y is entered, so be it. They know how they do things a lot better than I do.

Make sure that the accounting part of the program follows local laws. Sales tax can be tricky - does your taxing authority tax each item separately, then total the tax, or does it tax the entire purchase? If the latter, what does it want on single-item refunds from that purchase? Prorated tax refund or refund the tax for the item? Some agencies get sticky on audits, so it's best to follow their written rules.

And make sure the accounting part follows industry standard accounting practices - account numbers, audit trail, double-entry bookkeeping, etc. If you've never taken any accounting courses, writing a POS system is an education in accounting, if nothing else. (I learned everything I know about accounting writing an extensive POS system in the 90s. Spent months with the company's CFO, picking his brain for what amounted to about 2 years of college-level work.) If the program is written correctly, the CFO, accountant, accounting firm - whoever they use - will be looking at reports that makes sense. If not, your customer is going to have to spend many man-hours changing your reports into financial statements - which is NOT a good thing.

[bgmacaw]

Keeping the database structure IN the database can make it easier if the database structure has to be changed. You don't have to rewrite the program, you just have to update the data in the tables that hold the database structure.

Using metadata and good OOP practices can really help in this area while having a very procedurally written VB6 app (essentially an upgraded VB3 app) with a poorly designed Access DB can make you and the rest of your team quite miserable.

I don't just solicit their input, I let the user design the program. I just change their design into something the computer can execute. If they want X to be filled in with the last 3 characters of Y when Y is entered, so be it. They know how they do things a lot better than I do.

The problem I encountered was with exactly who the real user was. Operations people had one idea. Marketing folks had another. Accounting yet another. In-store personnel had their own ideas. It was like the classic tale of 6 blind men describing an elephant. I think our end result looked a bit like the elephant illustration at the end of that story.

Modularization would have probably helped give each set of users what they wanted better than a single, monolithic, application did.

[TheUsed]

wow you guys are doing great with ideas. except alot of this i dont understand i'll have to reread it when I have more time, but deffinately im getting more posts that I thought I would, so thank you guys

[TheUsed]

Originally Posted by bgmacaw
Here's an article I wrote that discusses one aspect of POS systems: Tip Sheet: Configuring Restricted Systems.

so in short just let the system administrator do the security instead of programming it because it can be bypassed easily if it's programmed?

[bgmacaw]

so in short just let the system administrator do the security instead of programming it because it can be bypassed easily if it's programmed?

That's right. Also because putting in 'secret handshake' security for administrative purposes in applications is not appreciated very much by sys admins. They strongly prefer to use their own automated tools to manage the systems in their domain.

[leinad31]

Also, rarely will you develop a POS on its own...if POS is for sale of goods then it has to be tied to an inventory system (or database holding inventory info at the very least), otherwise there would be minimal gains to offset cost. The idea is centralized management of the goods; track the goods from purchase to sale, across the board update of prices (if barcode implemented), and generate all relevant reports (and accounting entries if applicable) from it.

[szlamany]

This is a great thread to have found...

I'm developing a POS system for a friend right now - to run a dance studio and shop that sells dance wear.

I'll keep this thread posted with what we discover and do as we go along...

Here's a question - how do you open the cash drawer in the morning and close it out in the evening. How do you account for the take during the day and what's left in the drawer for making change the next day?

I was going to ask the coffee shop below my office this question - but figured it fit here as well.

[leinad31]

That's part of the business process and not just the application/system process, so it can't be fully automated (for audit/accounting purposes there has to be an audit or paper trail, and the system totals have to be counter checked by physically counting the money by hand or machine counter). Make start/stop login (if register doesn't have that feature already) of manager/supervisor dependent, only they can open/close and other similar activities such as cancelling transactions.

[szlamany]

Thanks for that - and I was asking mostly about the business process involved - and a bit on how to incorporate that into the app process.

[leinad31]

You'll have to coordinate with his accountant regarding that... But it will probably be a breakdown of the denominations, with other pertinent info like dates, signatories (prepared by, checked by, etc), name of cashier (for accountability of loss purposes), etc.

[Lord Orwell]

having used a pos, i would say not only is someone logged on a drawer, but the drawer follows them if they get moved to a different register. You also need to support drawer-skims where the management pulls cash out of the drawer at periodic times to keep the drawer from having too much cash in it.

[Lord Orwell]

also i just came up with an issue on the POS i designed for an auto-parts/garage. Some items have core-returns and i didn't add that to the main database, so now i'm having to redo a whole bunch of access forms and a couple of calculations.

[TheUsed]

Also, rarely will you develop a POS on its own...if POS is for sale of goods then it has to be tied to an inventory system (or database holding inventory info at the very least), otherwise there would be minimal gains to offset cost. The idea is centralized management of the goods; track the goods from purchase to sale, across the board update of prices (if barcode implemented), and generate all relevant reports (and accounting entries if applicable) from it.

I had thought of the whole inventory tracking system.. but I kinda gave up on my whole POS system idea a few months back because how can I make the program read from baracode scanners or anything... sounds intense... i know a long time back on my other account name (krpto) i had helped a guy develope an application to accept data from a baracode scanner using winsock... after I posted he never returned to the post so i dunno if he got it to work or not, i'd like to think he did.... any suggestions on how to strengthen that? I know that with implementing the inventory system it could help alot of bigger businesses like home depot-- as i hear they lose so much money with missing inventory and what not... which really sparked my POS idea, until like I said I gave up on the idea, but then my friend has a client who is looking to get a new POS system so i offered to take the job... im currently waiting on getting info from the person who needs the system to see what he wants it to handle and what not while I started this thread to get more usefull info.. so keep it coming it's coming along really great.. so how to implement the baracode. Can I access the data from the baracode scanner from a socket? UDP or TCP? I see that as my biggest struggle as im sure all of the development will be a struggle.



http://vbforums.com/showthread.php?t=281767 is the link for the baracode scanner thread

[leinad31]

There are barcode scanner models that act similarly to a keyboard... a textbox simply has to have focus then when you scan something the code appears in the textbox like it was typed.

[TheUsed]

There are barcode scanner models that act similarly to a keyboard... a textbox simply has to have focus then when you scan something the code appears in the textbox like it was typed.

so how technically the scanner will have to be hooked up to the server computer that the pos is on.. otherwise you would have to use winsock to get the scanners that are let's say used at grocery stores and what not, right?

[leinad31]

The scanner of the POS will be connected to the cash register. It will be the application in the cash register that will connect elsewhere (eg. local network server). If the setup your planning is different then the implementation would be different.

[Lord Orwell]

so how technically the scanner will have to be hooked up to the server computer that the pos is on.. otherwise you would have to use winsock to get the scanners that are let's say used at grocery stores and what not, right?

most of them don't even require drivers. they hook in between the keyboard and computer with a pass-thru.

[TheUsed]

ah ok so as said previously the client side of the POS would just have to have focus on a text box and the scanner can send the data to that?

[leinad31]

Yes, alphanumeric equivalent of barcode sent to textbox.

[Lord Orwell]

and some card scanners work the same way.

[Al42]

Here's a question - how do you open the cash drawer in the morning

Usually any particular business operates by starting the day with the same float (cash on hand), so allow system input to set that as one of the system parameters.

and close it out in the evening.

A separate function (I use a separate form). The user counts cash, Amex, MC, etc., and enters each total. I reconcile the entered amounts with what should have been there, and call out any discrepancies in red.

		Counted		Calculated		Difference
Cash:		$123.45		$123.55		$0.10 [in red]
Amex:		$100.00		$100.00		$0.00
etc.

Deposit:		$173.55 (Assuming a $50 float)

Have a textbox for them to enter the deposit amount (the cash take-out) after they reconcile any differences. Then your calculation will stay in sync.

How do you account for the take during the day

A separate function (passworded, maybe?), adding to a total of cash removed during the day. When you rconcile the drawer at the end of the day, you account for that total.

and what's left in the drawer for making change the next day?

That's your system param for the float at the start of the day.

For taking out cash, you should also allow for taken-out cash to be put back (I took out $100 and entered it ... oops, I meant to take out $50), and for the cash take-out to be accumulated during the day, or to be deposited as taken out. (Some businesses make periodic deposits during the day - to the bank or to the safe - others make one deposit after close of business.)

Add a function to print a deposit slip, even if it's not in a form the bank will accept. It makes it easier for the employee to take the cash, print the slip, then go to the office and write out a real slip.

[Lord Orwell]

every place i have worked for has a set dollar amount a drawer starts with. It has nothing to do with the register itself, they just subtract that amount out of the cash total when they count the drawer down.

[szlamany]

@Al42 - thanks for the info...

Have any of you managed the credit card machine directly or do you have your users take a copy of the receipt from the machine and put that in the cash drawer?

Can you interface with a cc machine - so that it can feed info about a transaction to the app?