Request for comment: GnuPOS - A Point-Of-Sale program

[Josh Sled]

On Sat, Jun 23, 2001 at 07:13:11PM +1000, Conrad Canterford wrote:

| I have started development of a point-of-sale program. I'll spare you
| the long story, but suffice to say that I've used QuickPOS (the
| point-of-sale offering from Intuit/Quicken) and its got holes you can

I've never seen QuickPOS, so I'm curious... I'm guessing it's a
Windoze-based program which provides a full-screen user interface for
the management and operation of a point-of-sale environment.  To this,
it provides transaction entry [and eventual payment processing], and
integration with a product database.  Since it's got a product list,
it may also perform inventory tracking and ordering...?

| WHAT I WANT

| - interface to gnucash ('cos that is where my accounts are).

What form does this interface take?  Does this mean that transactions
entered in GnuPOS show up in the appropriate registers in GnuCash... and
other registers exist in those books for dealing with non-POS business
expenses [like rent/utilities bills and paychecks and such]?

| - configurable gui ('cos not everyone wants things looking the same).

What do people really want to configure in the UI?  Seems like they'd
mostly want to customize logos and colors, and maybe some customization
of transaction flow... go from the "ring-up" screen to a "payment-type"
screen, then to a "receipt/finish" screen.  Some installs might want a
"customer information" screen in there, or maybe a "rewards-program"
screen in the mix...  does this seem right?

With respect to this, I'd say that customer information/loyalty tracking is
probably an important [maybe future-] aspect of a POS system.  Security is
very important, here, depending on the nature of the information being
collected.

| produces (this should probably also log to a file). The right-side pane
| is intended as a help/prompt/message window. The stuff output to either
| will be programmable.

Seems like it should simply be "configurable" for most applications... 

| - Most of the functionality to resize works mostly ok for what I've
| done, but it needs cleaning up. There are no doubt other options I've
| not considered that could be added.

OT: seems like a springs-and-struts layout option wants to exist in GTK...
but I digress.

| - After a (miniscule) amount of discussion on irc and with friends, I
| have decided an xml-format file is the go for keyboard programming,
| using a state machine setup. I'm not sure how to explain this, so just
| throw ideas at me, and I'll add/change stuff that seems interesting. It
| is my intention that *all* operation go through the state machine (in
| other words, I want no "automatic" things that happen - everything
| should happen or not happen according to the programming).

At the same time, you don't want each user to have to go through a large
amount of work each time re-creating the stock screens, and especially
their input-handling.  I'm thinking here that you want to major elements
in the state-machine description/configuration file.

. Stock screen with configuration/modification descriptions.
. Novel screen definitions, which become/create an Identifier for the
  state machine.

Similarly, there should be a simple way for the standard keys/transitions
to be used... default actions, perhaps.

Seems like out of that you end up with a set of widgets like "item
entry" and "name/address entry" that can be combined to create screens,
and these have standard navagition and navigational transitions in the
state-machine file.

Said another way, the state machine XML file for a really standard POS
environment shouldn't need to contain anything more than the customization
elements [logos, colors, &c].

Just a few other "stock widgets" you might consider:
. appointment setup
. customer contact information entry/modification
. order/purchase-order generation [for ordering from suppliers]
. inventory lookup
  . I'm thinking video store title-lookup
  . I'm also thinking "we expect this thing we're out of to be delivered
    on Tuesday" lookup.

| - ultimately, some way is going to have to be found to encrypt the data.

This might devolve into "just use a cryptographic file system" argument
at some point.  OTOH, it's nice not to have that dependency, especially
if the focus is on simplicity for the probably-non-technical end-user.
OTOOH, if the idea is a turn-key system installation, the cryptographic
file system can already be setup and hidden from the end-user.

The standard issues apply here: it should be strong enough that losing the
password will make the data unreadable [all security _does_ rest in the
key], but some procedure exists for a lost key to be recovered.  Maybe this
is where a trusted third party can come into the picture, to hold one half
of a key-share that can only be combined with a non-secret key-share that
the user holds [and can write down or whatever w/o compromising security],
which would allow the user to prove identity to the third-party in order
to get their keys back.

The database security angle is different and important, but fundamentally
similar.  The standard problem here is indexing over encrypted data
[important with credit cards, sometimes].


I like this idea a lot.  It could provide a really nice system that people
could get for their small businesses: POS, accounting and is linux based
cost/performance... at the same time, you might want to check out this
week's Risks Digest:

http://catless.ncl.ac.uk/Risks/21.49.html#subj6

...jsled