I was wondering if the project of building a point of sale would be a good choice on Linux. I'm going to start small with a closed system, not necessarily designed for credit/debit transactions and only cash as a payment. At the moment, this will only be a personal project to see if I can learn some Linux programming.

Some other questions I have here are things like:
Should I have it run as a program or a standalone OS?
If it's a program, what GUI should I use (KDE/Gnome)?
Is Linux capable of connecting with things like banks to do credit/debit transactions?

These are just a few of the questions floating around in my head right now. Also, could anyone refer me to a solid book or website that I could learn a lot of this basic information? I know I'm trying to tackle the world with something this complicated, but I figure I'll start small and work my way up.

Thanks in advnace for any input I receive as this is something I've been wanting to start doing for a while. I plan on starting this out on a virtual machine and eventually transferring it to a Raspberry Pi (that I wish I could get my hands on!)...

Good choice? Yup, sure would.

A few things you might want to think about (been there, did that, lessons learned during a wasted youth).

Think data base. Specifically, think LAMP (Linux, Apache, MySQL, PHP) -- no display programming, all that's needed at the business end is a browser, doesn't matter what browser, doesn't matter what operating system, the LAMP server does the work and anything that supports a browser can interact with it. You don't have to lock in with MySQL -- other DBMS' work just fine with PHP. A server with thin clients on a LAN or a server on the internet, a mix of both, not a problem. Think Amazon.com (or pretty much any site you've shopped and bought stuff from -- they're mostly some variant of LAMP).

The hard part is the data base design. I could do a few hours on data base design but, essentially, a data base consists of a number of tables each of which holds unique data that is joined to other tables by one or more keys.

You'd have a table that contains the items you're buying and selling. Pretty much everything you'll ever buy or sell is going to have a UPC; that's your key. The table can contain the UPC and a description (which you get electronically from your vendor).

Point of sale? UPC? Scanner!

Want more information about items, add columns for vendor ID, cost per unit, selling price per unit, taxable (not everything is everywhere), effective date of cost, effecting date of selling price, cost of goods sold account ID, income account ID and whatever else you can think of that is unique to an item.

You have a separate table for vendors (ID, name, address, terms, representative ID).

You have a separate table for representatives (ID, name, address, contact information, whatever).

You have a separate table for purchases, another for sales, another for receivers (add stuff to inventory), another for payables and so on. All that goes in them is an ID, a UPC, one or more dates, units and a price per unit. DBMS' do arithmetic (and statistics and a lot of other mathematical functions) so you don't really need to store totals (but you usually do anyway -- there are carbon-base units that look at the stuff).

You've a separate table for customers.

Once you've got all that stuff you start with Apache and PHP -- data entry forms, data reporting forms, search, whatever -- all done in a browser, or a cash register or whatever you've got.

Frankly, this is not a trivial undertaking. It's doable, hardware (like scanners) is available, most of them are pretty much standard (basically they're more or less a keyboard, delivering a number to your server when you hear the beep). UPC is a standard and vendors are more than happy to provide UPC files to you. Accepting plastic is pretty straight-forward (but, boy, do they get you on transaction costs and percentage of sale).

If you can do a LAMP model system you can sell it for a lot less than a custom hunk of hardware that will be obsolete next week. Thin clients (no disk drive, boots from the server) are inexpensive, no operating system maintenance to worry about (can you imagine having to keep 5, 10, 20 or more Windows things up to date? Ugh!). And, you probably won't be answering the phone at 0300; that's a Good Thing.

Give it some thought, do some research (Google is helpful here), maybe buy a couple of books (O'Reilly has some pretty useful books on these subjects). Mull you options.

Hope this helps some.

I concur. Personally I would prefer Perl to PHP but that's life. You can make a system that runs completely solid state from ram and a compact flash card. Upgrade / update ? Simply plugin a new compact flash.

A few years ago, in my senior year of college, I created a POS system using LAMP for my senior design project. I thought it was great because it was truly platform independent, everyone thought I was crazy for creating a web based POS system though for some reason.