Fellow Monks;

I am in the process of building modules and utilities for a point of sale project. My thinking here is as follows and I would like to open it up to other thoughts, review, etc. This may be a bit long, so I hid it as a spoiler

Hardware Support:

Point of sale is all about two things: workflow and hardware. The hardware which is easy is the hardware which handles input. Most of these either pretend to be keyboards or pointing devices. I don't actually have to worry about this at all. The "hard" hardware is hardware that handles displays and output. All hardware interfaces I would prefer to contribute to CPAN.

For the other hardware though the customer-facing pole displays are not too hard. They are usually documented well and have what is effectively a serial, ascii interface. They may, however, connect over USB, RS-232, or parallel ports and so the harder issue usually is just connecting to it and being able to send the data.

For pole displays, my thinking is to offer a unified interface, perhaps Device::POS::PoleDisplay, with a DBI-like interface, which can hand off important functions to the driver. The driver can then unescape strings, advance rows, clear the display, etc. For now I think the easiest way is just to communicate with the serial or parallel port as a file, though for USB devices, this may take some additional work.

Receipt printers, on the other hand, are genuinely difficult to properly support. On one hand they are usually just used as text printers, but they are text printers with peripherals, control sequences that varies from one vendor to another, and there are a wide range of gotchas. Often, you want the printer to respond very fast, which precludes use of a print spooler, but there are times you want to spool, so a unified interface must be able to handle:

My thinking is to break this off into Device::POS::ReceiptPrinter as a DBI-like interface, with device drivers, command sets, modes, and hardware interfaces all going into deeper namespaces. This could mean a lot of modules but it means that code can be shared flexibly. An Epson U220D can share code with an Epson TM80T in terms of a command set, but the U220D can default to activating the autocutter, for example.

I'd like to put all these on CPAN in order to facilitate other point of sale frameworks, share code, and improve support.

Back-end support

Our back-end would run PostgreSQL, and interface using PGObject::Simple::Role (already on CPAN). The database functionality would be using stored procedures against LedgerSMB (and ERP written in Perl). I would like to, long term, break the database routines in LedgerSMB off into a PostgreSQL extension to do the accounting and inventory side (this code would then be shared with LedgerSMB via the database). Licensing has not been decided, but would be either GPL v2 or BSD.

Current Application

Right now I have a basic wxPerl-based program contributed by Andres Basille from Argentina. The code is incomplete, but it generally works in the general outlines, sans hardware support and a whole bunch of other things.

Other Possibilities

Other possibilities would be to move the hardware management (printers, etc) off into a separate daemon either via http with a locally running web server, or via a named pipes interface, and perhaps even use a web-based application connecting to localhost.

In terms of point of sale frameworks, what changes should I consider in order to facilitate more code sharing with other projects?

Comment on RFC: Perl-based Point of Sale Projects
Re: RFC: Perl-based Point of Sale Projects
by Anonymous Monk on Nov 19, 2013 at 16:43 UTC
    When a waitress holding a tablet takes my order, and runs my card, right there while standing at my table, I wonder if POS isn't already changing in a fundamental way that would render the project stillborn . . . obsolete on arrival.

      Point of sale is a large field. You have significant differences between hospitality and retail both in workflow and requirements, for example. Initially I am focusing on retail, which tends to assume fixed locations for cashiers.

      Food service is different.... Touchscreens are usually not optional, mobile may be more important (although in retail mobile may be important for niche applications, like taking inventory) and the business requirements are almost nothing like retail. You have all the "configure to order" problems in food service that you don't in retail.

      Additionally the same hardware issues are present in food service however, if you want to print a receipt and open a cash drawer, but you *also* have typically shared receipt printers in the kitchen to send orders back. Finally here in Asia while folks do a lot more with cards, the rules are actually more strict, so the card swipe terminal is usually separate (many of these are now 3G however).