hi im need some information on how to go about making a business POS system... should I use vb.net or vb 6...
Printable View
hi im need some information on how to go about making a business POS system... should I use vb.net or vb 6...
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.Quote:
Originally Posted by westconn1
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].
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
That was not what I said. Read my previous reply one more time.Quote:
Originally Posted by 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
Just use VB.Net.
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?
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.
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.
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!
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.
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
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).
ok thank you. sounds like i'll learn alot with making this system
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.
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.
Very good suggestions - sounds like a lot of hard-won experience. I'd like to add a couple of points:Quote:
Originally Posted by 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. (This is not entry-level coding, but neither is a POS, to begin with.)
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.Quote:
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.
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.
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. :sick:Quote:
Originally Posted by Al42
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. :eek:Quote:
Originally Posted by Al42
Modularization would have probably helped give each set of users what they wanted better than a single, monolithic, application did.
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
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?Quote:
Originally Posted by bgmacaw
Here's an article I wrote that discusses one aspect of POS systems: Tip Sheet: Configuring Restricted Systems.
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.Quote:
Originally Posted by 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.
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.
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.
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.
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.
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.
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.
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.Quote:
Originally Posted by leinad31
http://vbforums.com/showthread.php?t=281767 is the link for the baracode scanner thread
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.
Quote:
Originally Posted by leinad31
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?
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.
most of them don't even require drivers. they hook in between the keyboard and computer with a pass-thru.Quote:
Originally Posted by 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?
Yes, alphanumeric equivalent of barcode sent to textbox.
and some card scanners work the same way.
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.Quote:
Originally Posted by szlamany
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.Quote:
and close it out in the evening.
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.Code: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)
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.Quote:
How do you account for the take during the day
That's your system param for the float at the start of the day.Quote:
and what's left in the drawer for making change the next 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.
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.
@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?
the receipt goes in the drawer. You don't want to hardcode ccsales because you might switch cc companies. The ccsales are totalled separately with a ccsales button and compared to the receipts at the end of the day and there are any discrepencies you also have a weekly statement from the cc company to compare it to.
I've worked with 2 credit card machines.Quote:
Originally Posted by szlamany
One, for a large retailer with a few hundred stores, used a full featured touchscreen PIN pad unit that pretty much did everything, even taking the customer signature. Our program sent the transaction dollar amount and only got back a status code from the unit. We never saw the card number or any other customer info. Our interface to it was a COM object and drivers supplied by the manufacturer. It was more like interfacing with a separate networked computer than an attached device. All the accounting and reporting was handled within our program so no receipt copy was needed unless system problems caused the backup plan to go into action.
Another project, this one for a small group of medical offices, used a simple card reader. It piggybacked on the keyboard and when the card was swiped the program got the number and some other info as keyboard input. The transaction info was sent either over the Internet or phone line to the processing center's computer which would return an approve/decline response. The receipt copy was kept for accounting purposes since our program only provided rudimentary reporting.
what about how the program is made... should it be designed to load before windows so that the only thing running on the computer is the POS system...
As I mentioned in the article I linked earlier, it is usually best to do this by managing the user rights and privileges. This makes it easy for administrators to maintain the system while keeping things like Task Manager and even the Taskbar out of reach to ordinary users. The POS program would load on startup by placing the appropriate command(s) in the Run section of the registry for POS users.Quote:
Originally Posted by TheUsed
The alternative is to use a command shell replacement. While this has the advantage of making the system totally dedicated it has the disadvantage of being harder to code, harder to maintain, and more difficult to customize and extend. For the clients I did POS systems for flexibility was the most important consideration. Other companies I know about wanted tight standardization and went with a dedicated POS program.
Our POS system will not be a dedicated app - the user will want to run other apps on that same machine.
replacing the command shell doesn't really screw anything up. You can create a password-protected link in the program to launch the taskbar.
ok what if it did load before windows but had an option to boot windows? that way system admins can do whatever.. I mean I just dont know which is best. Like what do you mean run the shell command that's used to open other programs through another program right?
yeah. Or you could just put common buttons on the menu such as calculator (useful always in a program like that)
You're really talking about 2 different things.Quote:
Originally Posted by TheUsed
Not booting Windows would imply a separate OS configuration, such as running Linux and Windows from the same HD. I think this would make things too complicated to code and maintain. Only run one OS.
Overriding the Windows command shell and booting to alternate configurations is another. I don't recommend coding this because you can buy alternative security shells for considerably less than what it will cost you in time and money to code a secure and stable one. Plus, Windows XP (and I suppose Vista as well) itself provides all that you should need for most POS environments as long as you take the time to configure it right.
all you have to do is replace the explorer.exe with your own filename in the win.ini file. If you don't use the standard explorer.exe, you don't have the task manager running, and the user won't be able to tab off of it. If you ctrl-alt-del you can still start other programs, but you can lock that command with a password.
The sysadmins I worked with on one POS project gave an emphatic "NO!" to that idea. Most notably they called it a major security risk and said that it would be very difficult to maintain reliably and to support.Quote:
Originally Posted by Lord Orwell
On the other project the program had to work and play well with other programs since the system wasn't a fully dedicated POS system but an add-on to a medical office management system.
well there's always the full-screen and on-top of other windows option. Wendy's system does that.
I recently coded something like that for our medical apps. It put a bit of critical info up front first where the user, a medical tech, had to act on it before doing anything else. If the user had access to Task Manager they could bypass it easily, but they don't have access to it. I think it's a rather clunky and obtrusive way to do it but it works.Quote:
Originally Posted by Lord Orwell
Also, going back to general POS, with a touch screen and specialized limited keyboard you can get away with a lot more. Sometimes it pays to look at a hardware solution in addition to a software and system administrative solution.
The hardware I ordered for my customer left Louisville, KY at 4:07 am today - and arrived in Windsor Locks tonight at 8:47 - must be at the airport (UPS - 2nd Day Air).
I'll check Track Shipments in the AM and it should be on a truck to my office.
Now I get to figure out how to get my VB client program to interface with the cash drawer and the receipt printer. It's got a POS keyboard - whatever that is - I guess I'll find out in the morning.
a POS keyboard is one that you can customize every button on it. Print your own keytops and they go under a plastic cover. That way you can have a button for "milk" or one for "dairy" or whatever. Or more useful is a $1 button, a $5 button, and "Exact Change" button, etc.
And interfacing the printer is easy. It is recognized by windows as a printer. Interfacing the cash drawer can be easy but it depends on the interface. I believe most of them are serial and i would expect it would have a driver disk, but not necessarily. it basically is just a relay in there that opens it. I've actually seen them hooked into the pc speaker and you open the drawer by calling the beep command.
Here's the POS machine - cash drawer - POS keyboard - nice thermal receipt printer - nice barcoder reader - and a magstripe reader
i didn't know hp made cash drawers. But you see what i mean by pos keyboard? Nothing printed on the buttons.
Yes - some of them have the old F1...F5 type buttons under the clear covers.Quote:
Originally Posted by Lord Orwell
Do you just print on some colored paper and cut-out "new key meanings"?
We found the OPOSCashDrawer functions on a CD that came with all this - and already can open the cash drawer - rather simple. Very little programmer documentation though...
What is the expected use - OPEN/CLAIM/OPENDRAWER - then what?? Do we detect that the drawer was closed manually to close the transaction?
Any general assistance you can offer on the use of these OPOS functions in regard to cash drawer and receipt printer (I was kind of surprised the cash drawer plugged into the receipt printer) would be appreciated.
Thanks!
Many credit card software comapnies have (Activex contraols) that you can use in your software to make it a seamless transaction. (Search for Credit Card Active x Controls)
the way it is usually done is you check to make sure the drawer is closed before you store the order. If not, you pop up a dialog telling operator drawer is still open.