
New Business Opportunities/Ideas

Ron Fish sysdes@xmission.com
June 21, 2000
Dear Pragma Dealers,
These are just ideas for you to generate new business with your clients. With
the current fad and the future of business being"e-Business" a lot of
my clients are wanting (not yet demanding but they will soon demand) internet
applications that tie into Pragma. More and more clients (and their customers)
are getting T1, ISDN or DSL lines and are connected to the internet on a
constant, direct basis. All of my multi-user clients run on SCO UNIX so these
problems and solutions are UNIX/Pragma 4 based. However, I see no reason why
someone familiar with Windows NT/Pragma 4/5 couldn't do the same things.
Online bill payment / Statements / Invoice detail / Payment history
Recently a client asked me to set up a web application that would allow his
customers to view and pay their invoices online. It works! Of course, this and
other clients already have online purchasing implemented and all but a very few
do not have at least a web presence.
How it works
In Pragma I have a single posting program for invoices and a single program that
posts payments to those invoices. Each program was modified to run an
"update" program after all the new invoices or cash receipts are
posted. In effect, this program builds a text file with all current invoice and
payment information for use on the web. Then it performs a system call to
transfer that file to the bill/payment site for my client. In UNIX with a
customer base of 4,000 customers and an open invoice file with over 6,000
invoices, the entire process, including uploading to the ISP takes 6 minutes.
For statements, I generate a plain text file (in my system, "no"
printer is selected so no printer control codes are sent) and this is a simple
link generated by the Perl program to view or print the statement.
A customer logs on (a secure site) and can view their statement, and the detail
of any invoice and/or payments. They can then click on a payment button which
will pull up their payment options. On the site where the customer log-in
information is stored is all of the client's options for payment and other
information. In my case, my client accepts MasterCard/VISA and, of course,
checks. If the customer has more than one option to pay, a list box is produced
and they can use a previously posted (by them) payment option (credit card
number, name, address, expiration date, etc., checking account information) and
pay the bill.
They can also update their profile to add/delete/change their payment options.
As in my Pragma program, this Perl program computes finance charges, late fees,
and assesses an additional fee for processing the check ($15) or credit card
(5%). It also allows for a customer comment box where they can request a
discount amount or leave other instructions. When the customer clicks on the PAY
button, an email is sent to my client where it is also transferred to a specific
sub-directory of the Pragma directory (a nice backup in case the Pragma server
is down). A program runs constantly in Pragma checking for newly posted
information. When a payment comes in, the information including all the bank's
information, is brought up on the screen. My client then uses the telephone to
process the check or credit card payment in a new cash receipts program designed
specifically for interfacing to this process and then updates the web
information again. Total turn around time depends on the efficiency of my
client's checking on and processing the posted information. It can be
done/checked constantly, many times per day or once a day.
This has increased my client's cash flow and reduced the average time for a
customer to pay. Because their customer pays for the processing fees, my client
does not lose any money for providing this service. I was surprised, actually,
how many people will pay a surcharge just because it's easier.
The next steps will be to:
A) Have Pragma run auto processing directly to banks for the checks and credit
cards. First and easiest will be via modem, then via the internet where those
banking institutions allow for it. This part of the process is currently manual.
B) Send statements and invoices generated by Pragma via e-mail. This can also be
done automatically from within Pragma.
The web program is written in Perl working on my client's ISP server and my
client running a UNIX Pragma server with the SEND MAIL option (not MMDF).
Unix network transparent printing
I have a client that uses a UNIX pragma server running terminal
Hostess/Rocketport serial communications line. They also have a DSL connection
to an ISP that is open 24 hours a day. They wanted to add networking options to
their system so that some of the stations in the system could be directly
connected to the internet via the DSL line. At the time we made these changes,
the client had over 30 modems for dialup connection to the ISP -- this was
getting very expensive.
This presented a problem with printing to the terminals' printers. Because I
have never used the UNIX print spooler system* and because I cannot use
transparent printing to a Windows printer via network connection from a UNIX
server, I had a problem in that I could not print!
I installed Facetwin** on the UNIX server and on one Windows computer (as an
administrator). This allows re-direction using the UNIX lp spooler. The spooler
requires a text file. My programs all printed directly. I created 2 new programs
-- ASF (assign spool file) and PSF (print spool file) which I placed at the
beginning and end of each print program. Because of how a user logs onto my
programs, I know what printer type (dot matrix, laser, inkjet) they use and what
printer port. The ASF/PSF programs check to see if the port they are printing to
requires a spooled file. They can also change printer types/ports after the
Pragma log in.
The system now allows for either transparent printing to any serial terminal's
printer AND spool printing to any Windows network printer. When using the
network, the user runs a TELNET program to run Pragma. My next step*** will be
to allow internet connected remote printing from outside my client's in-house
network. Currently, I have had to set up each printer with a specific IP
Address. The easiest solution for me is for the person to get a static IP
address from their ISP but this is not always an option. With a customer dialing
into their own ISP and connecting via telnet, the IP address changes everytime
they log onto their ISP (unless it's static). Once this process is completed, my
client's employee's (telecommuters) as well as their customers customers may
telnet into my client's system directly via the internet and do their work or
process orders, view the status of current orders, statements, make payments,
etc. A special UNIX login is provided for them which takes them directly to a
special menu for them, and then logs them off automatically. The UNIX screen
colors are also changed to black on black when logging into UNIX so if they
return to a UNIX prompt [if they bypass the Pragma program] they can't see
anything!
Currently employees and customers can log in via direct dial (modems set up on
the UNIX server) and do this, but not if they are connected to the internet and
still need to print. Once this wee print problem is solved, they can be
connected to the internet and perform all the functions directly. This
particular option is not recommended for all clients because of security
problems, but for employees it is very desirable.
*With the Comtrol products "transparent printing" through the same
serial connection is a snap - if the data port is ttyu01, the ASSIGNed PRINTER
port is tpru01 and no printing options or commands need to be changed.
**Facetcorp.com - sign up as a dealer and you get a free 5-user license
*** Facetwin is supposed to allow for dialup/non-static IP address printing and
I should have this finished this week
I hope this did not waste your time. At the very least, I hope that it gives you
additional ideas on how to generate more business with existing clients and help
you secure new business as well. I wrote a newsletter to all my clients and
informed them of these "new" options. I stated that, depending on the
level of customization I have done with their system, the base or starting price
is $5,000 ($5,000 to $50,000+ less than if they tried converting over or using
someone like IBM's e-Business). Most of my clients all have my same
"base" programs and there are just a few changes to my Perl programs
for each client so the setup and changes will take less than 2 days for each
client. So far, a dozen clients have responded and "ordered" it with
another dozen wanting more information. Also, once a client is onto the web,
updates to their site and other enchancements generates a decent amount of work
both for the web and for Pragma.
Be well, be happy and then be successful!
Ron Fish
00-06-22
lip_tech3.gif
t_busopp.htm
