// Copyright (c) 2004 Kurt M. Brown.
// This file is subject to the terms and conditions of the GNU General Public
// License. See the file COPYING for more details.

intro
    -- all "id"s start with 1
    -- php code (maybe pear at some point)
    -- genddl xml
    -- nothing needed to install or configure
       -- except database-ddl (genddl)
       -- meaning the config input is done outside the core as on add-on
    -- core uses pdo and is passed all necessary input data from callers.
    -- encryption of pan, track2
    -- daemon, connection pooling (pdo?), scoreboarding, recycle
       -- php daemon forking (request counting)
       -- socket interface

core
    has no db knowledge
    does no logging
    does not connect to anything
    just does formatting and even that is modular
        vitalps, paymenttech, etc.
    state transition
        -- valid
        -- allowed with transition
        -- allowed without transition
        -- invalid

functional
    has db access
    has socket https
    has site, cc, user, logging schemas
    has complete script interface
    has no web interface

add-ons
    -- security (admin), users, privialeges
    -- xmlrpc (apache + php)
        -- setup account, terminals
        -- run auths, settlements, void, batch, etc.
        -- list activity
        -- other reports
    -- html ajax (maybe)
    -- xul ajax (first!), build extension and app.
        -- ajax to all core services
        -- config setup, terminals,
        -- need swipe, gather info, also parsing
        -- display of reports
    -- pos, saleItem == menuItem, invItem == inventoryItem,
        orderItem (sold saleItem), purchaseItem (ordered invItem).
        order (saleOrder) (moneyIN), purchaseOrder (moneyOUT).
        OR, just "item" and have a column that is "isInventoryable".

install core + add-ons
    -- none
    -- build scripts for apache and php
    -- just code tgz, and scripts to do stuff (make an instance, etc.)
    -- complete build of apache and php, xpi
       -- placed into tgz, rpm, zip for each OS.
    -- need startup, shutdown, service install, crontab, etc.
    -- rpm is client oriented, single location solution
        -- has sql DDL for many databases
        -- creates tables, etc., with "install" script that is
           ran after rpm is done (must be interactive in some cases
           (e.g, more than one supported database installed)).
    -- zip is for other os that someone might add for me.

    New versions of software (delivered by rpm or tgz), includes everything:
        SI updates and code for Central and any distributed systems (remote
        servers and clients).
    To deliver software updates to remote systems and multistep process is
    required (cron?).
    A new version is installed at Central and the global version is so set.
    When all remote systems are updated, the install is complete. A
    remote system might be offline for a large period, so the remote parts
    must be stackable.
    Every version lists its pre-version prerequisite.(Or) Each update (version)
    describes what it follows, so it will not install if the prerequisite
    has not been met. This way the software version must be installed in
    the correct order. And branch versions will not work unless applied to
    the correct branch.
    It could be that v2.4 updates v2.3; but v2.4 had a problem and so a
    v2.5 is created that also updates v2.3 and a v2.5fix that updates
    v2.4 and in all cases the final version is v2.5.
    (I need a comment about a branch case here).

other software requirements:
    -- database (pg, mysql, etc.)
    -- apache httpd
    -- php build requirements
        -- database pdo
        -- xmldom
        -- cURL
        -- xmlrpc, soap


who needs it:
    -- inbeteen handlers
    -- small stores (retail, etc.)
    -- medical, dental (offices, etc.)
    -- insurance
    -- home businesses

how does it work?
    -- go to bank and setup account
    -- enter account data into software
    -- sell!

paper trail is good for small guy (backup)
allow backup of database
allow dump of log and transaction info to allow re-enter and batching
on failure.
allow for upgrading of software
no backdoors, if they need help, they can create a temporary admin user.

tip, amount, void, (pre-auth, lock, hold)

type, kind, reason, mode, manner => auth, offline, credit, reverse
    == use doc ==

device, method => card, check, export (manual)

settleGroup => organize trans for settlement

input
    swipe
        pin
    manual
        pin
    check scan
    not present
        pan and expdate, ccv, address
        check account and routing and check#
account-persistant-data
    swipe  => track1 or 2 and pin (also parsed pan and expdate)
    manual => pan, expdate, pin, ccv, address
    check  => account, routing, check#

cardType == Vendor (see doc)