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:

• Multiple hardware interfaces (USB vs serial vs parallel)
• Multiple command sets (most prevalently Star and ESC/POS)
• Multiple modes of operation (spooled vs non-spooled for example

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.