The back end office software requires a PC. Linux is recommended although certainly not required. It's the most common platform for PHP+Apache+MySQL so it tends to be well documented and easy to install/maintain. Overall performance is tied to database performance, which is bottlenecked principally by RAM. Disk space is a slightly greater concern here than on the lanes because transaction history grows continuously and you'll likely want local and external backups. For reference, WFC runs ~40,000 transactions a day and has a transaction history dating back to late 2004 a full database back up is ~14GB. That's not perfectly indicative of growth rate; our transactions per day have increased over the same time period, but in a world where disks are measured in hundreds of GBs (if not in TBs) running out of space isn't a big issue. Now, options:
- If you're going to use one server:
- Get a multi-core, 64-bit processor. 64 bit software is mature enough that the extra RAM ceiling is worth having, even if you start out with 4GB or less.
- Get a bunch of RAM. 4GB with slots open for expanion is probably a good starting point. If you can afford more, more is always better.
- Get a bunch of disk space. 250GB is probably sufficient for a long time. Fast disks will help database performance. An SSD plus a normal disk for backups might be the best option these days (as opposed to SAS/SCSI RAID array), both in price/performance ratio and ease of set up management. This would be strictly a performance bonsus; CORE will run fine on a 7200RPM SATA disk. Two physicals disks total is a good idea to protect local backups from a single drive failure.
- Gigabit ethernet would be nice if your infrastructure supports it throughout
- Dual NICs could be handy if you want POS separated from the rest of your network.
- If you're going to use two servers:
- Get a heavier duty machine exactly as above. Put MySQL on this machine.
- Get a lighter weight machine and put Apache and CORE's Office software on that. This is a much lower workload. Basically anything you can lay hands on will be sufficient.
- Advantages of this set up include:
- DB Server can dedicate all resources to the most intensive task.
- Dual servers provide convenient backup locations for each other. You still want off sites of course, but this protects you in the event of a dead disk controller, exploding power supply, or other "entire machine" failure
- If the Apache machine has dual NICs, the demarcation between POS and non-POS networks is cleaner. Firewall rules that simply don't allow any traffic across that point are simpler than rules permitting certain ports.
- If one machine fails, you can roll-over to a single server model (quickly and easily if they have mutual backups) while waiting for replacement parts or a replacement server. If the stronger machine goes down, interim performance won't be ideal, but it will at least be functional.
A typical CORE lane set up includes a fairly standard PC and a few peripherals.
PC Requirements: pretty lightweight. It's probably not possible to buy a new PC that isn't capable of running Lane with acceptable performance. RAM is usually the biggest bottleneck, but even then many stores are operating registers with less than the 2-4GB that's practically standard these days. Multi-core likely helps with the database+webserver workload, but again that's pretty common now. Disk space is dirt cheap; just get something in the 250GB range and never worry about it again. Gigabit ethernet would be a nice boost if you have infrastructure for it through out, but certainly isn't a requirement. Be aware that many POS peripherals rely on PC ports - serial, parallel, and ps/2 - that are rapidly disappearing on newer PCs, especially if you get something in a small form factor. USB adapters are usually a workable solution for serial ports but somewhat less so for parallel ports. Some hardware peripherals work better on Windows but Linux works too.
Scanner-Scale: all existing code is targeted for and tested on DataLogic Magellan 8xxx series scales. Go with one of these.
Receipt Printer: again, the easiest solution is to recommend what's already in use: Epson TM-H6000 series. Other Epson POS printers may speak a similar enough dialect to be useable. USB and parallel printers have both been used successfully.
Cash Drawer: anything that's compatible with your printer (POS cash drawers typically connect to receipt printers). The TM-H6000 uses MMF style cash drawers.
Keyboard: CORE Lane is best operated using a programmable keyboard. The QWERTY keys are used when looking up members or products by name; exactly how many programmable keys you need will vary by how many tenders you accept, departments/products you need shortcuts for, etc. Aim high. It's far better to have extra keys than to run out. A double-zero button on the number pad and an over-sized enter button are both handy features that are reasonably common on POS-keyboards. The PrehKeyTec MCI 128 in a rows and columns layout (i.e., no pre-labeled QWERTY section at all) is the most common choice.
Mouse: strictly speaking, you don't need one, but it's nice for OS-related stuff like shutting down or restarting a machine (especially when a programmed keyboard lacks some normal characters & navigation keys). A trackball is a nice solution for tighter spaces.
Monitor(s): it's far easier to operate with one. The Lane UI works fine in 1024x768 or even 800x600. Finding an incompatible display ought to be nearly impossible. For separate customer and cashier displays, just put in a simple VGA splitter to send the same output to both monitors.
Touchscreen: there are some touchable elements but CORE Lane is not designed to operate solely with a touch screen. Any touchscreen where a tap is interpreted as a mouse click should work. Clicking around with a mouse should give some sense what is and is not accessible via touch.
Payment Terminals: CORE supports end-to-end encryption using ID Tech IDFA-3153 payment terminals. This currently only works with Mercury as a card processor. Reliability is better in Windows.
CORE supports sending data directly to Hobart Quantum TCP scales and there's some basic support for it in Office. If it's something you're interested in, going with that model is probably easiest; if you have a different model, try to find out if it supports Hobart's Data GateWeigh utility. This utility is Windows-based, so you may need a dedicated [ultra low resource] box just to run it (depending on other infrastructure, spare machines, etc). Of note: when Quantum TCPs go into powersave/sleep mode, they seem to forget about wireless settings. Just waking it up isn't sufficient to fix this; it takes a full powercycling. Unless the scale is in fairly constant use through the day, this isn't the most useful feature.