You've seen point-of-sale (POS) applications in many retail businesses. POS cash registers record transactions - as they occur - directly into an organization's computerized accounting system. At Ricks College, rather than buy an off-the-shelf package, we chose to develop a do-it-yourself POS system combining readily available hardware with software we wrote ourselves. We didn't write it entirely from scratch, but cannibalized pieces from our old canned system as a starting point. We used emulated 5250 terminal and printer sessions on low-cost PCs integrated with our host-based custom POS software (no code runs locally on the PCs).
Many third-party vendors provide hardware and software for AS/400-connected POS applications. But it's expensive - when we first looked at canned solutions, we found four that might have worked, but we didn't like the $10,000-$20,000 per workstation cost, and none of the solutions was tailored to suit our needs. And even if we'd found a suitable one, we'd still have had to integrate the package into our environment.
Although writing your own software is cheaper and more flexible than buying a package, it has its own costs. Doing it yourself takes more time than buying a canned package and requires the know-how to develop the necessary software in-house. You also have to do much of your own troubleshooting. As with any system you cobble together yourself, when something goes wrong, you can't call a single vendor to fix it. If a printer stops working, the cause could be in the printer, in the workstation, or in the code - and you get to figure out which one.
Ricks College, a two-year Mormon college in southern Idaho, has accounts receivable, accounts payable, general ledger, payroll, financial aid, registration, admissions, physical plant, and administration information all stored on an AS/400. Auxiliary institutions (such as the health center, bookstore, housing office, and campus police) also keep their information on the AS/400.
The main purpose of the proposed POS system would be to manage student financial data. We wanted payments of everything from tuition to library fines to be recorded interactively at the cash register, and we wanted to be able to make disbursements to students (usually financial aid) right from the cash register as well. We wanted a student's financial history displayed on the screen with every transaction. But student financial data would be only part of the system, albeit the largest part. The POS system would also service accounts for employees, clubs, churches, government agencies, and other off-campus units.
We had installed a packaged POS application seven years ago: We bought a PC-based NCR cash register system and appropriate software and set up an interface to our S/38 through a communications line and a protocol converter. (We later installed this protocol converter on our AS/400.) But the software company had discontinued maintenance on the NCR cash register-based version of their product a year after we bought the software package. Last summer, a power spike fried the protocol converter - and the application had been customized to interface with this one make and model of protocol converter. Fortunately, we had a spare. Meanwhile, the manufacturer had gone out of business - which meant that we were faced with potential unrecoverable failure on a critical application. So it was time to start working on a new system.
Choosing Hardware Components
POS hardware consists of three basic components: A terminal or PC, a cash drawer, and a receipt printer. In addition, some systems also require a bar code and/or magnetic stripe reader. If you accept credit card payments, you'll also need a POS modem for verification.
Terminal vs. PC. We first looked at Ultimate Technology Corporation's fully integrated twinaxial POS terminal, which includes a cash drawer, receipt printer, and magnetic stripe reader. You can optionally attach bar code scanners and other devices. The unit costs $3,495 (not including the optional devices), with volume discounts. An alternative, if you have an ASCII workstation controller or a protocol converter, is to use a cheaper ASCII POS workstation with ports for scanners and for a printer (cash drawers attach to the printer, not to the workstation). We chose not to buy either of these primarily because if one component of an integrated POS workstation fails, you have to return the whole unit for repairs.
We went with PCs instead. With PCs, we could purchase the components separately, and PCs offer our users more flexibility and computing power. POS terminals are really modified 5250 terminals. Most have small green or amber screens coupled with a cash drawer and a printer port. Our cashiers had complained about the small screen size on our previous cash register system, so providing them with 15-inch PC screens was another reason we chose PCs over terminals.
In addition, PCs provide many options for communications with the AS/400. Until May, we had both twinax lines and an Ethernet LAN on our campus, but we phased out the twinax terminals in favor of LAN PCs. If we had chosen 3277-like terminals (the only IBM terminal with printer ports) instead of PCs, the hardware cost would have been $1,400 less per workstation, but with terminals we could connect only via twinax or serial ASCII lines - not via the LAN.
Finally, we couldn't find any wedge bar code scanners at all and couldn't find any inexpensive magnetic stripe scanners that would work with a terminal, whereas several are available for PCs at a reasonable price.
The PCs we bought are pretty basic because the AS/400 does most of the work. We ordered six 486s, each with a 300 MB hard drive and 4 MB of RAM, but we could have gotten by with 286s with 1 MB of RAM. At the time, we paid $2,380 for each PC, but prices are falling, and you can get similar 486s for less than half that now.
Cash drawer. The next step was choosing a cash drawer. Most PC retail stores and catalogs stock several varieties, but we wanted the cash drawer to open automatically, so we looked for one with some sort of hardware interface to a serial port or to a printer. We purchased APG Corporation's model M320, which has an RJ-45 jack (similar to a telephone jack), but other cash drawers are competitively priced.
Receipt printer. We wanted our receipt printers to control our cash drawers, so we looked for a printer with a cash drawer interface. We bought DH Print's model DH4700, which has an RJ-45 connection for a cash drawer. The printer does slip printing, such as endorsing the back of a check (you can expect to pay extra for this feature). It also has graphics capabilities, which can be used, for example, to print simple logos. The printer has several font sizes and can print upside down (upside-down printing is used for check endorsements).
We configured each PC to run a Client Access for extended DOS display session and printer session. The printer connected to the PC is also connected to the cash drawer, all of which are controlled by a traditional green-screen AS/400 program. When you want to print a transaction, the host program simply prints to the appropriate printer. Based on the transaction type, the RPG program determines whether the cash drawer should be opened. If it should be, the program sends the appropriate escape sequence to the printer, which provides the signal that opens the cash drawer (of course, you can also open it with a command key). To send the escape sequences, you just specify the appropriate hexadecimal codes in your RPG program's O-specs. The escape sequences vary from printer to printer; our printers required some hex codes RPG couldn't send directly (because OS/400 can't transmit characters below hex 20). However, a little work using Client Access's PFTSETUP program to customize printer translation tables solved the problem.
Reader. Many POS applications require a bar code and/or magnetic stripe reader. Ours required a magnetic stripe reader to scan student ID cards and credit cards. Some keyboards on the market include magnetic stripe readers, but they cost more than $250 each, and if the reader fails, you must either repair the whole unit or buy a new one. Thus, we decided to buy a separate reader. A keyboard wedge device sends scanned data from the reader to the PC as if the data had been entered at the keyboard.
We bought the Welch Allyn ScanTeam 6920 magnetic stripe reader, which cost just over $170 at a local PC store. This reader is small enough to attach to the top of the keyboard.
A cashier can key in a student's ID number or can scan the student's ID card. We soon discovered that the ID card sent a string that encapsulated the ID number with extraneous bytes; we had to parse this data to remove the extra bytes. It also sent a <BR>, or Enter, command, which we weren't expecting, but we turned this to our advantage: We changed our program logic so the cashier has to press the Enter key one less time. Many offices and programs use the ID cards and scanners, so we coded a single program to decode the ID card data.
We also use the magnetic stripe reader to take credit card payments. We use a nondisplay field on the screen to receive the scanned data from the credit card. The "track 1" credit card data can be processed many ways. Christopher & Associates' POS Port software (discussed below) accepts track 1 data, but I didn't discover this until after I had already written some string manipulation routines to extract the data myself. Determining what data would be sent by each credit card required experimentation. I attached a magnetic stripe reader to my own PC, scanned a credit card, and just watched to see what data would show up in my text editor. I then parsed the data into the fields I needed.
POS Port.Instead of having a credit card modem at each workstation, we asked our bank to furnish us a POS Port modem, which is a credit card processing system attached directly to an AS/400 communications port. We also bought a software package from Christopher & Associates to serve as the interface between our AS/400 application programs and the POS Port device.
Each AS/400 program that handles credit card requests (such as credit card verification, charges, and credits) sends the requests to a data queue. When a data queue entry is received by an AS/400 program, the program then passes the authorization request on to the POS Port. The POS Port sends various verification codes back to the data queue, which is read by the AS/400 programs. If an AS/400 program accepts a transaction, the program can then create the transaction records for the accounting system.
This system reduces costs because you only need one POS Port device connected to one telephone line, instead of paying for a separate modem and line for each cashier, as many retail outlets do.
So far, we haven't had any response-time problems with the POS Port system. When a credit card request is made, the POS Port line stays open a number of seconds waiting for another request, so if another request occurs during that wait time, the connect delay is eliminated for the second request. Once connected, card verification takes less than five seconds (a complete transaction typically takes anywhere from 20 seconds to 5 minutes). Once a card is verified, the program writes a record to a settlement file; the actual money transfer is done at midnight through a batch settlement process.
Our Software Solution
When we wrote the AS/400 software, we started with existing modules from our accounts receivable and old cashier systems. Although the new system incorporates many features of the old, it also has new features, such as student ID and credit card processing. Running on V3R1 also let us add a few bells and whistles supported by DDS, such as color and pop- up windows.
The POS software took two programmers about two months to write. Creating the cashier display and input program took the most time and effort. Our main RPG program required over 2,000 lines of code; we also wrote some ancillary CL drivers.
We wanted the system to be as maintenance free as possible, so we put all variables (such as account numbers and cashier-specific data) into user-controlled tables. This reduces maintenance because when account numbers, prices, or other codes change, the user can simply update the tables instead of a programmer having to update the programs.
We designed the software around the business idea that any cashier's office in any part of the college system should have access to all student financial data. In a typical transaction - for example, when a student pays fees - the cashier scans the student's ID card, and the system displays a summary of the student's financial status: money owed by the student (including tuition, registration fees, health center charges, bookstore charges, traffic fines, library fines) and financial aid due the student (such as grants; scholarships; federal, state, and private aid; and loans). The student can pay via cash, check, or credit card. Whether the student is paying tuition or a library fine, the transaction is processed by the same POS program. If the payment is by check, the AS/400 sends special codes to the printer telling it to print an endorsement on the back of the check. The printer then prints a receipt. The system posts a completed transaction to the accounts receivable system.
Students can also receive cash: When scholarships or other financial aid exceeds tuition and fees, the cashier pays the excess amount directly to the student.
Besides that central transaction processing program, we wrote other programs to display screens and print reports for reconciliation of cash and checks.
Although our AS/400 DASD is protected by Redundant Arrays of Inexpensive Disks, our AS/400 is up "only" 99.97 percent of the time - so the college accountants still wanted a paper record of each transaction. We could have purchased printers that print on two-part paper with a take-up roll for the second copy. But instead we put a database trigger on our cashier transaction file. In our case, the trigger is invoked only when a record is added. When a change is made to the database file, it invokes the trigger program, which then prints each transaction written to the file on a small serial printer attached to another PC in the cashier's office.
Worth the Effort
When we initially evaluated canned POS packages, we estimated it would take almost as much programming effort to write a software interface connecting the prefab solution to the college's AS/400 as it would to write the POS programs ourselves. This estimate factored in the time and money we could save by salvaging parts of our old POS system to serve as the foundation for the new. By creating our own system, we met not only our minimum requirements but also achieved much richer functionality and flexibility than a canned package could have provided, for less cost.
A week after we implemented the new system, a cashier told me how much she likes it. She appreciates the larger screen size and the amount of information now available to her and said she can now help students faster, so lines are shorter or nonexistent. In addition, students don't have to go from office to office to collect information about their financial situation.
In designing our system, we tried to make it generic enough that other departments on campus could use a similar system in the future. For example, we plan to provide a similar cashier system for our Division of Continuing Education when possible.
If you have limited programmer resources or experience, a canned POS package offers a straightforward solution. If you can find a package that matches your requirements, implementing it may be the cost-effective choice. But our complex and atypical situation convinced us to develop a homegrown system, even though producing it put us behind temporarily on other projects. We think the result was well worth the effort.
Terry Silva is a systems programmer at Ricks College, a two-year college owned by the Church of Jesus Christ of Latter-day Saints. He has worked with midrange computers for 20 years.
Sidebar: POS System Components
486 PC (with 300 MB hard drive and 4 MB RAM)
Model M320 cash drawer
5250 Industrial Boulevard NE
Minneapolis, MN 55421
(612) 571-5000; fax (612) 571-5771
Model DH4700 receipt printer
860 Collegeview Drive
Riverton, WY 82051
(307) 856-4821; fax (307) 856-0412
Model ScanTeam 6920 magnetic stripe reader
6981 South Brookhill Drive
Salt Lake City, UT 84121
(801) 943-3009; fax (801) 943-4322
VisaNet POS Port
Provided by your local bank at no charge
AS/400 Support for POS Port
Christopher & Associates
P.O. Box 3573
Oak Brook, IL 60522
(708) 655-0038; fax (708) 655-2098
Price: $3,900 (includes software, technical phone support, and one year of maintenance)