Hi,

I'm just a PHP rookie, but i've written a POS system for Parking Management (in Delphi/Win98) that works online with car detectors, barriers and empty/full signals but is based in a single computer.

after selling and installing 12 succefull systems in the last 6 months I started looking at a MySQL/Jaba solution to provide full distributed functionallity in the next version of my system, but,... really, I just gave up.

Well, regarding the Hardware I can give you some advice:

a EPSON TMT80 Printer (serial) for barcode tickets and receipts,

a EPSON DM106 or 206 Display (serial) for displaying messages at the entry/exit terminals and prices at the cashier,

any drawer compatiple with the printer (there's a escape code you can send to the printer that outputs a drawer kick impulse through a RJ45 connector).

a PSC QuickScan 6000 Barcode Reader that comes with a keyboard wedge connecter and works paralel to the keyboard sending keyboards events to the program.

Those were the best devices I found, after working with cheaper, but less reliable devices like Star's POS components.

And don't forget to use a UPS system, otherwise your database will really suffer from operator generated "accidents". I learned this one the hard way

Good luck.

André

    Any advice will be greatly appreciated.

    For starters, forget about MySQL and try something like PostgreSQL
    that really and truly supports real transactions. MySQL is great
    for quite a few web-based applications where the requirement is
    speed ueber alles, but just ask your (potential) POS customers
    how eager they are to have their accounting or inventory information
    get out of balance!

    I find MySQL's official comments on transactions to be quite
    unreasonable:

    We at TcX had a greater need for a real fast database than a 100%
    general database

    That's not too bad for starters, although to be completely accurate
    they should have use "safe" in place of "general". But reading further
    on, we come to:

    To avoid using ROLLBACK, you can use the following strategy:

    1.Use LOCK TABLES ... to lock all the tables you want to access.
    2.Test conditions.
    3.Update if everything is okay.
    4.Use UNLOCK TABLES to release your locks.

    2 and 3 are the killers here--instead of putting the responsibility for
    this inside the database, they expect each and every place in
    your application code to do all this?

    And then he says:

    This is usually a much faster method than using transactions ...
    The only situation this solution doesn't handle is when someone kills
    the threads in the middle of an update. In this case, all locks will be
    released but some of the updates may not have been executed.

    Well, you're welcome to progam this way using a web browser as
    a client if you want, but my experience with both NS and IE
    would lead to classify them both as a bit unstable--exactly the
    kind of situation that might lead to crashing in the middle of an
    update.

      Here are some more of my though process:

      1. Linux server with PHP4, Apache, and MySQL.
      2. All dynamic contents will be written in PHP including authenication (log-in) for clerks, buying process (very smiliar to on-line ecommerce with a shopping cart), dynamic inventory control, charge accounts, session tracking, and etc...
      3. MySQL will server as backend. It will provide customer, user, inventory, etc databases.
      4. Win98 with IE / Netscape as client's interface.
      5. Java applets will control the CC terminal type thermal printer and open the cash drawers attached to the Win98 clients. This will occur at the end of buying process.

      Is this project feasbile? Any suggestions / recommendation is greatly appreciated.

      Thanks for your time.

        I too would suggest postgresql for a transaction/accouting type system.

        I'd use galileo or equivalent for a web browser on top of a minimal Xwindows environment (i.e. make it the sole program that runs on top of X, so the users don't go playing solitaire all night, or "adjusting" they're terminals. If you want it to be REAL fast, do it with console linux and lynx, so there is no X11 or Windows overhead. Then any old computer could make a fast terminal.

        I second the recommend on the Epson TM80 series thermal serial receipt printers, they are very reliable and make nice output, plus they are pretty easy to do graphics and such on if you want.

          If you want it to be REAL fast, do it with console
          linux and lynx, so there is no X11 or Windows overhead. Then
          any old computer could make a fast terminal.

          Interesting idea, but is there a version of lynx out there that does
          a reasonable job supporting tables? Otherwise, it's not going to
          mix well with any gui browsers.

            screw lynx. use links instead. it supports tables wonderfully.

              I use lynx with tables all the time. Now, frames, frames it doesn't support so well, but for fast interface, it does fine by me.

              I have no experience with links, but the messages I've read about it say it's not quite ready for prime time yet.

              You could design the setup so the user logs into the lynx program directly with no shell, i.e. a single use system.

                4 months later

                No, it's not feasible in some ways,

                1) Java applets (to my knowledge) operate in a sandbox and can't deal with anything client-side. So unless you're going to have a servlet running locally on each client that handles input from the bar code reader and handles the printer and connect to it using sockets, I don't know how to do it.
                1a) Well, that's not completely true. The way I'm going to do it is have the bar code reader process update a database (or temp file or whatever) and then have a never ending script running in a frame that flush()'s the output every time something new is printed (pulling from the db queue) and that's how the user will be able to see that they successfully scanned a bar code. I just started thinking about this and haven't really come up with any better ideas, but let me know if you do! I'd of course have to increase the PHP script timeout to do this....
                2) Regarding MySQL vs PostGreSQL, they're both excellent databases. Specifically regarding the "application crashing" and since IE/NS aren't stable, the "application" in this case is the web server w/ the PHP module or the PHP CGI process itself. These processes are stable. Whether the browser disappears from the face of the earth doesn't really matter -- once the PHP interpreter has started talking to MySQL, it's going to finish unless the script times out. 99.999% of all database will take less than 30 seconds, but if you need more than that increase PHP's script timeout. So for most applications, either MySQL or PostGreSQL are great choices -- pick whichever you're more familiar with. If you're an expert, then you don't need me telling you which one is a better choice. If you're a novice, go with MySQL -- there's a lot more documentation out there on it. And while we're on the subject -- autoincrementing counter fields are something that PostGreSQL doesn't have that MySQL does -- and I use them constantly. :-)

                Good luck!

                  QUOTE *******

                  And while we're on the subject --
                  autoincrementing counter fields are something that PostGreSQL doesn't have that MySQL does -- and I use them constantly. :-)

                  END QUOTE ***********

                  Yes it does, they are defined much more simply as well, like so:

                  create table test (last_name text, first_name text, id serial);

                  There, isn't that easier than the long funky stuff you have to type to get an auto-incrementing field in mysql?

                    4 months later

                    Hi! I am trying to find out if you got the POS system working. if so, is it OpenSource or can I see the source code. I was working on one but i had losts problem with. thanks.

                      Pagla,

                      Sorry - we got undercut on the contract so we never started it. I know there are a number of them but I'm not so sure about which ones are production-ready. I know Home Depot here in the US (a very large home supply chain, now part of the Dow Jones) uses Linux for their POS systems. I also believe Federated, a Western US used Linux for their POS systems. You might be able to glean some details of the pieces they used from news articles about them. (For example, Java w/ Oracle on Linux or something). I would be surprised if their code was open-source, but there are probably some very high quality opensource products out there. Some places to check would be Sourceforge.net, Freshmeat.net, Slashdot.org, and of course Google.com. Use the search facility on each site for things like POS and Linux. You could also use the "Ask Slashdot" feature to post the question to all the readers if none of these searches turn up anything -- your question is applicable to many readers and would likely get posted and get a huge amount of response.

                      Good luck!

                      -Jamie

                        9 months later

                        I am now working on a POS system for fast food restaurants. I have coded a receipt printing function that print a receipt on HP LaserJet4 printer as a prototype. I wonder if anyone can teach me how to print a receipt on an Epson receipt printer or a Stsr receipt printer as I don't how to use the receipt printer control characters to control the printers. I am now using PHP (with PHP Printer functions) and MySQL. Please advice.

                        Thanks & regards,
                        Kevin

                          Write a Reply...