Welcome to Merchant Order Form
version 1.4
Ver. 1.5 available soon for free too.
What do you want to order today?
- Smart looking
invoices to print, mail, or fax
- Logging and/or
emailing orders to Merchant
- Logging to
a RDB format for import to PC database
- Customer
email confirmation
- Online Checking
information input
- Flexible
configurations for discounts or handling charges
- Adaptable
shipping methods, rates, configurations
- Automatic
foreign shipping rate change
- Multi State
tax configurations with adjustable computations
- Accepts input
for Cards, Checks, custom OrderForms
- Built in
support for custom shipping configurations
- Built in
support for customizing additional field input
- Built in
switch to require "cyber permission" approval
Merchant
OrderFormv1.4 are program
scripts written in Perl 5 code for use on Unix type or
NT systems using CGI (Common Gateway Interface). The program
scripts are installed and run on the server where your
Web Site is.
You should be
able to install the OrderForm page and the program's script
files if:
- You know
how to edit a Web Page file (an HTML file) and transfer
it to your server
- You know
how to FTP (file transfer Protocol) a regular text file
to your server
The documentation
can help someone with little to no experience installing
CGI scripts; however, if you don't know the difference between
an HTML file and a CGI file, then you're probably in for
a rough ride. Begin with the Quick Start section and follow the instructions
carefully.
Merchant
OrderFormv1.4 is loaded
with settings and options, from simple to complex, that
can be adjusted and/or configured to process your OrderForm
input in many ways.
You can read
an overview of each configuration section's abilities
and limitations under the heading further on in this document:
Each of the configuration sections begins with
an overview of what that group of settings can do. If you
need to know if you can adjust things the way you need them,
then find your way to the "What can these settings do"
section for that group of configurations, and consult the
summary there.
You can also
find answers for other questions under the heading:
| Table of Contents for this Documentation |
Merchant OrderFormv1.4 |
- Appendix 1 – Name - Value pairs used
in the OrderForm input Page
- Appendix 2 – Acronyms for
using with State tax matching
- Appendix 3 – Names used for
Country Matching
- Appendix 4 - Structure of the related
RDB files
Notice:This documentation is packaged with registered copies of
Merchant OrderFormv1.4,
and should not be distributed in anyway. Resale or
Redistribution of this documentation or the Merchant
OrderFormv1.4 programs and scripts is strictly
prohibited without the author's permission. Please visit
the Merchant
OrderForm Web Site to obtain registered copies of
the program or obtain information about registering it for
your web site. Standard disclaimer applies.
Merchant
Order Formv1.4 is a smart
Online OrderForm and invoice system for small product
collections. It interacts smartly with the user, and presents
friendly feedback. It does not process credit card
or online check transactions in real-time. It provides
four ways to process orders from your Online Customers:
- Send the
order via email to the Merchant
- Log the invoice
and orders into a Master Logging file
- Log the invoice
and orders into a delimited file for RDM import
- Send the
Customer an email verification of their orders
It is convenient for small collections of products,
since you only need to add new items to the HTML OrderForm
input page. Once Merchant OrderForm is up and running on
your Web site, then you only need to change your HTML OrderForm
to update, add, or delete your line of products. It's as
simple as editing your HTML OrderForm page.
You can layout
your HTML OrderForm page using checkboxes, dropdown boxes,
listboxes, radio buttons, or hidden input, and Merchant
OrderForm will sort out your Customer's orders and present
smart looking invoices.
Merchant
Order Form v1.4 will
handle as many New Products as your server has memory;
however, this would not seem practical since the customer
doesn't want to go through hundreds of checkboxes to order
items. So, it's probably more applicable to smaller collections
of products, whereas, a database / shopping cart system
seems more user friendly for large product collections.
A database / shopping cart system also allows the shopper
to "add" products from any page on the Web Site, and collect
in a "cart." Merchant OrderForm produces invoices from
one OrderForm at a time.
You need to
do two things to get the scripts up and running in test
mode:
- FTP the scripts
to your server's Cgi-Bin exactly as they are
- Set file
permissions on each of the files so they will execute
The program files are already configured to
run without any of the features enabled in the configuration
file, for basic installation and testing. Once you have
all 3 scripts running, then you can begin to play with the
configurations and features in the configuration file, but
I recommend getting all scripts running in basic mode first
before you start to configure it for your site needs.
- First, FTP
(File Transfer Protocol) the 9 files below
straight to your Unix, Linux server's CGI-BIN. They
should transfer and run exactly as is, without even
opening them up. Eventually you will need to open the
configuration file, but you don't need to do that now.
For now, just send them over as they are when you unpacked
them.
Important: Make sure to FTP the files
in ASCII mode only, do not use the FTP Binary Mode, else
the scripts won't work on your server's end.
- Next, you
need to set correct file Permissions on the files
you just sent to your server's CGI-BIN.
Note: Many FTP programs have a way to
set Unix type permissions from their menus. If you don't
have a way to set "permissions" from your FTP, then get
one that can, it's easier than doing it by Telnet (if you
even have Telnet access on your server). You can find some
Freeware FTP Clients (programs) at the NoNags
Web Site.
Here are the
files you need to FTP and the corresponding permissions
they need to work. Transfer all 9 files, and set the 4
"cgi" files with complete "execute" permissions, then
set the 2 "dat" files and 3 "rdb" files with complete
"execute" and "write" permissions.
| Filename |
Owner Permissions |
Group Permissions |
Other Permissions |
| orderconfig.cgi |
Read,
Write, Execute |
Read,
Execute |
Read,
Execute |
| orderfinal14.cgi |
Read,
Write, Execute |
Read,
Execute |
Read,
Execute |
| orderform14.cgi |
Read,
Write, Execute |
Read,
Execute |
Read,
Execute |
| ordercount14.cgi |
Read,
Write, Execute |
Read,
Execute |
Read,
Execute |
| orderlog.dat |
Read,
Write, Execute |
Read,
Write, Execute |
Read,
Write, Execute |
| ordernumber.dat |
Read,
Write, Execute |
Read,
Write, Execute |
Read,
Write, Execute |
| ordermain.rdb |
Read,
Write, Execute |
Read,
Write, Execute |
Read,
Write, Execute |
| ordercustom.rdb |
Read,
Write, Execute |
Read,
Write, Execute |
Read,
Write, Execute |
| orderorders.rdb |
Read,
Write, Execute |
Read,
Write, Execute |
Read, Write, Execute |
- Note: If you are using a Telnet connection to set permissions
in Unix then you can use:
- directory/> chmod
755 filename.cgi for Read, Execute permissions
- directory/> chmod
777 filename.cgi for Read, Write, Execute permissions
Now you should have the basic scripts and the configuration
file set to run from your Web Browser.
Perform a test and
see if you can run each of the scripts independently from
your Web Browser. You don't need to submit anything from
the HTML orderform to run them. Simply plug in the HTTP
addresses where you placed the scripts on your server
into your Web Browser's address or location bar. Here's
an example from my site.
All three of the
main script files should run this way. If they don't and
you're sure you followed the two important rules above (1)
FTP ASCII Mode only, and (2) Setting Permissions,
then you are getting a server error for some reason. If
you are getting server errors, you should consult the section
of this documentation - A checklist for installing CGI on Unix type servers.
Of course, you'll
get error messages when you run the first script <orderform14.cgi>
saying you haven't completed the data entry fields, but
the script is running, it's doing exactly what it's supposed
to do without the information submitted by your OrderForm
Page.
You'll also
get incomplete information when you run the other two
scripts this way <ordercount14.cgi> and <orderfinal14.cgi>
because they aren't processing any relevant information,
but the scripts should still run.
The <orderfinal14.cgi>
file will not test this way if "cyber permission" is enabled.
It is disabled in the download package. Unless you turned
it on in the configuration file, then it should be disabled.
Also, all other switches are initially turned off in the
configuration file, disabling things like file locking,
file logging, and mailing, which could prevent this final
file from executing independently.
When you have
tested all three main script files and they are running
on your server, then you are ready to begin your journey
of configuring Merchant OrderForm for your site needs.
You can place your HTML input OrderForm file <orderform14.html>
anywhere you want, and point the FORM POST tag to the
first processing file <orderform14.cgi>
Here are some
examples:
- <FORM
method=POST action="../cgi-bin/orderform14.cgi">
- <FORM
method=POST action="http://www.yourdomain.com/cgi-bin/orderform14.cgi">
- <FORM
method=POST action="https://www.yourdomain.com/cgi-bin/orderform14.cgi">
This type of HTML
tag is embedded inside the HTML code of your HTML OrderForm
input Page. It identifies an address and file name of where
the contents of the FORM will be sent when someone clicks
the "Submit" button on the OrderForm. You browser then sends
the entire contents of any FORM input to the file you identified.
In the above examples, all your FORM content is sent to
the Merchant OrderForm first processing file, which takes
over from there.
There is a main
example HTML OrderForm included in the package <orderform14.html>. It includes all the input
fields that you might want to use for your OrderForm.
There are also some samples of different ways you might
want to make your OrderForm input page.
They are meant to serve as examples, and you
can create your own HTML OrderForm if you want. You can
also modify the example OrderForms any way you want for
your site needs. If you create your own OrderForm then just
make sure you use the same name / value pairs that I have
used. A detailed listing of these name / value pairs can
be found in Appendix 1 at the end of this documentation.
The scripts process information by these names only. Therefore,
your OrderForm input Page will have to use these same "input
names."
- If you want
to process only Online checking account information, then:
Omit the credit card section on the OrderForm input
page. You can place the "I'll pay by check" checkbox
as a hidden variable. Now your form appears to process
only checks.
- You can also
remove the "checking account" section altogether and
the form appears to process only credit card transactions.
- Remove the
"additional customer information" section if you don't
need this, but make sure to keep the phone number, fax
number, and email fields if you need them, the "phone
field" has a validation rule, you'll have to remove
this if you don't use the phone field.
- You can remove
everything but shipping destination, and place the "pay
by check" as a hidden variable, and the form appears
to allow processing for money
order only.
- You can set
up an OrderForm that builds a product, like a custom
made computer, by creating sections with drop down menus.
The customer selects each component by choosing it from
the list.
- You can set
up an OrderForm where a set of radio buttons, checkboxes,
or drop down boxes list options for color, size, etc
for a product.
It's okay to omit fields that you don't need.
Just leave them out of your OrderForm input Page. The scripts
don't care about what is not there to process. However,
the first processing script attempts to validate that necessary
input is present. Necessary input is considered:
- At least
one ordered item, whether user chosen or hidden input
- At least
one choice of payment type, whether user chosen or hidden
input
- The essential
shipping destination information
- The "select"
input for Country and State is best as drop down menus
- And a phone
number in case some Merchant contact is needed
If you need additional input other than the
fields I have named in the main OrderForm input Page, then
you can configure the scripts to process input names of
your own. See the documentation on Working with settings
in the configuration file - Installing Custom Fields. You can place an unlimited
number of name / value pairs in your HTML input tags, as
long as you tell the configuration file what their names
are. Make sure you don't use any of the same name / value
pairs that I've already assigned. Consult the listing
in Appendix 1.
My examples
of the HTML OrderForm input Pages also include links to
picture windows to put images of your products in. You
can take this out, and everything will work fine. The
files named <show1.html> through <show9.html> are the picture windows. If you use this
set up, you'll need to add the images into the HTML windows.
The <scripts.jpg>
file is just a logo. When you configure the three processing
files, you can use a similar image for your site logo,
or you can omit the image and just use a name.
Merchant
Order Form v1.4 scripts will process the
product items in your HTML OrderForm input Page as long
as you keep to the format I've set up.
Here are the
two rules:
- The name
must be exactly "order"
- The value
must contain four elements separated by 4 minus
signs as delimiters
Here's the exact
HTML syntax to add new checkboxes to your HTML OrderForm
input Page.
<input
type="checkbox"
name="order"
value="Item Name----Description
of the Item----11.65----1">
This tag will create a new checkbox that, when
checked by the user, will send the Item Name, Item Description,
Price, and ShipCode to the CGI processing files. The processing
files will identify only the "order" NAME for processing
product data, and the VALUE data will be extracted correctly
only if the delimiters are used correctly.
You can use
any input type you like as long as the name / value pair
follows the pattern outlined. You can use radio buttons,
drop down boxes, list boxes, check boxes. Just make sure
you always name a product "order" and give the
value the 4 elements defined. All of your product names
will be "order." This is how the scripts tell it's a product
to be sorted out separately from the other information.
Usually, HTML Form input names would not be duplicated;
however, you must duplicate them here.
You can also
format the appearance of your checkboxes, dropdown boxes,
listboxes, radio buttons anyway you want. The way they
appear on the page, the type of labeling you use has nothing
to do with the underlying input name / value tags. You
can use images, links, or anything else to list and describe
your products as long as the underlying input name / value
attributes are correct.
If you get errors
from the invoice processing you better check this portion
very carefully and make sure that the NAME and
VALUE delimiters are correct. The delimiter "----"
4 minus signs together with no spaces between text must
be correct, and you must include all 4 pieces of information
in correct sequence for the VALUE.
- NAME="order"
- VALUE="Item
Name----Item Description----Price----ShipCode"
The Price must be in 2 decimal format
"100.00" and it must be a raw number with no dollar signs
or other formatting like commas, etc. If the price is fifty
cents then you would show that as "0.50", or $1,275.35 would
be shown as "1275.35".
The ShipCode
must be free of any formatting also, and can contain only
a numerical value. For now, you can just put ones for
your ShipCode. Merchant OrderForm
v1.4 has some serious flexibility when computing shipping
charges, and in order to fully appreciate what you can
do with your ShipCodes you may have to read about shipping
computations in the next section called - Working
with settings in the configuration file.
You don't need
to understand the configuration file in detail at this
point, but you will need some forethought to how you want
to assign ShipCode values to each product. So, I will
cover some information on how to think about using the
ShipCodes.
There are two ways to think about using the
global shipping schema:
Calculate
shipping charges as percentage of price
The first way is to simply calculate shipping
charges based on the cost of products. If you use this
method then you don't need shipcodes, because you already
have product prices listed. Just assign a "1" to every
shipcode for this schema. The "1" won't be used under
this schema, but you still need the value there as a placeholder.
Shipping will be computed using the actual price of products.
Calculate
shipping charges by weight per item, or dollar amount
per item
The second way
to use global settings is to set up your shipcodes as
either a:
- Weight
per item or a
- Shipping
amount per item
Which are interchangeable.
Then use the "Global Settings" (discussed in the next section)
and compute shipping charges based on the overall weight
or overall amount of the entire invoice.
Either this
item would be 35 cents to ship, or it would weigh 0.35
pounds.
- NAME="order"
VALUE="Name----Description----12.95----0.35"
Note: If using the "Global Setting" schema use the weight
or cost values for your entire list of products. Don't try
to use weight for one and amount to ship for another. This
is really a different schema, not the "Global" method.
When using the
"Global Settings" for shipping computations, then the
entire invoice's orders are totaled with the [weight X
quantity] for each product. You will instruct the configuration
file to deal with the total weight or shipping amount
from the invoice in different ways. Here are some of the
ways the "Global" computations would work:
- Using a rate
per pound
- Using a rate
for every 2.5 pounds
- Using a one
time rate regardless of the totals
- Using a rate
for each 5 pounds up to a maximum of $ 25.00 then charges
are free
Don't even think
about using these settings unless you are ready to think
about multiple arrays in perl 5. This schema uses 12 individual
settings for each shipcode assigned, and can get complicated.
Better to start with the suggestions above, which should
cover most shipping needs.
If you want
to use this level of computations then, you would use
a system of numbering for your ShipCodes starting at 1,
and proceeding in sequence to how ever many different
individual computations you need.
It might help
to think of this schema in the same weights and amounts
way, except that we won't be assigning weights and amounts
in the HTML OrderForm input Page tags. Instead, we will
be assigning a group number to each product, and in the
configuration file we will assign the particular characteristics
(amounts / weights) for that group.
In this schema,
you create a more complex system of shipping rules, where
individual sets of shipping rules will be applied to each
ShipCode. This system must use sequential integers starting
from one. If you plan to use this method, don't assign
decimal numbers to the ShipCodes, else the script won't
recognize the ShipCode. When these settings are enabled
in the configuration file, the script looks only for ShipCodes
1, 2, 3, 4, etc.
Example:
Let's say we have four different ShipCodes from 1 to 4
exactly. You can give any number of products a ShipCode
of 1, thereby assigning it to the individual computation
rules for group 1. Likewise for group 2, 3, and 4.
Note: You don't have to use all the groups you set up,
but that would be rather silly, not to mention pointless.
If you set up a 4 number system, and only use ShipCodes
for 1, 3, and 4, in your line of products, well then,
obviously, you only need to use a 3 number system. The
script will work fine looking for any products with a
ShipCode of "2" and seeing none, will go on to checking
the other ShipCodes. In computing, the scripts will look
for all the 1's, then all the 2's, etc., keeping a cumulative
total for each ShipCode.
This built in
feature is enabled in the configuration file, and bypasses
all other shipping computations. It's a way for someone
to write their own code for processing shipping charges.
If you're going to do this, then assign ShipCodes as you
would in the "Individual Item Settings" above, in sequential
integers starting at 1. Then when you write your code
in the actual processing file, you write your own rules
for computing each ShipCode group. There are more notes
about this further on in the documentation at the section
- Other Switch Functions.
Each of the
configuration sections begins with an overview of what
that group of settings can do. If you need to know if
you can adjust things the way you need them, then find
your way to the "What can these settings do" section
for that group of configurations, and consult the summary.
Here are
the major configuration sections that govern the behavior
of the program:
Once your scripts
are running in test mode, and you have set up your OrderForm
input Page, then you are ready to configure the features
and settings you want to use. Merchant OrderForm gets its instructions on what
to do from the configuration file, so you'll be editing
this file.
Important: Use an ASCII editor only, do not use a rich
text, or fancy word processor to edit the files unless
it lets you work in ASCII mode only. It's also best to
use an ASCII editor that will store the file in Unix format,
if you are working from a Windows machine. Two of the
processing files are too large for the regular Windows
Notepad. Therefore, you may have to find a good ASCII
text editor. Check out the NoNags Web Site.
Okay, I wish
I knew of some encouragement here. The configuration file
is almost five pages long printed. If you're not used
to CGI installations or perl looking code, then I know
it looks like a mess. The good news -- you don't have
to read about the features you don't want to use. But,
if you want to turn on a feature, or adjust a setting,
then the best way to do that is to use this portion of
the documentation as a reference. If you're pretty savvy
about perl looking stuff, then jump right into the file
and start setting stuff by using the comments embedded
in the configuration file.
The file you'll
be opening is called <orderconfig.cgi> and
here's some points to know about cruising around this
file:
- Settings
are grouped together under CPITALIZED HEADINGS
- In perl,
all comments start with the # character. So,
when you see a line like this:
# this
is a comment about something
You don't need
to modify anything past the # character.
You're looking
at notes and instructions.
- When modifying
a setting, be very careful to leave all the punctuation
intact. Perl is not like HTML, and it is not forgiving
if you leave one little single quote off, or one little
semicolon. The perl interpreter won't compile the code
if a syntax error exists.
- Most settings
are simply changing a number from zero to one or visa
versa
- Other settings
are text based and must remain within quotation marks
- Some of the
more complicated settings require that you define what
is called an ARRAY in Perl language, and write within
parentheses, assigning single or associated keys-values
settings. Follow the explanations for that section carefully,
and be very careful to place all the necessary single
quotes, commas, semicolons, parentheses, etc. exactly
as the instructions indicate.
What can
these settings do?
- Turn off
all tax computations
- Turn on tax
computations for all invoices
- Turn on tax
computations for designated shipping destination only,
using one or multiple destinations with individual tax
rates for each
- Assign individual
tax rates to match one or more destinations, and assign
a default tax rate for all other destinations
- Set the tax
to compute before or after shipping and handling charges
- Designate
one or more destinations to reverse the before / after
rule
- MOF only
looks for state matching in the shipping destination
address
Configuration details
$use_tax
- This turns
on (1) or turns off (0) using the tax computations.
- It must be
enabled for any computations to occur (1)
- No tax is
computed or printed if turned off (0)
$all_tax
- This enables
(1) computing and printing tax for ALL invoices.
- Disabling
(0) this causes MOF to look only for "state matching"
for tax rates.
- If turned
on (1) MOF first looks to see if there are designated
tax rates for any defined states in the array below
called <%taxrates>. If a match is found, then
MOF computes tax from that designated tax rate. If no
match is found, or if no states are defined for matching,
then MOF uses the default tax rate assigned in <$all_tax>.
- If turned
off (0) then MOF applies a tax only if the shipping
destination state is defined or designated in the array
below called <%taxrates>. If MOF does not find
a state match, then no tax is computed.
$all_rate = 0.03;
- The default
rate explained above if <all_tax> is enabled (1)
- Use the format
0.0625 with no quotation marks, it is a numeric value
%taxrates = ('STATE',rate);
- This contains
the acronyms of states that you want to tax and rates
for each
- You can define
only one('CO',0.03) which applies 3% tax to Colorado destinations
- Or as many
STATEs,rates as you need ('CO',0.03,'TX',0.0625,'OK',0.0825)
- Which applies
a 3% tax if Colorado is the shipping destination
- or a 6.25%
tax if Texas is the Shipping destination
- or an 8.25%
tax if Oklahoma is the destination
- If you want
to use the <all_tax> default rate for all invoices
then set this to null.
- %taxrates
= ();
- This
is NOT a zero it is two closed parentheses
Note: you
must use only the acronyms in the table provided in the
documentation, Appendix 2 – Acronyms for using with
State tax matching when setting up this array. MOF can only
look for values that were submitted by the drop down box
for state shipping destination. You can add to or edit the
drop down list in your HTML OrderForm input Page for shipping
destination if you want, but you must keep the same definitions
here as you have in the input page drop down list.
$tax_before
- If turned
on (1) tax is computed and printed before the S&H
charges
- If turned
off (0) tax is computed and printed after the S&H
charges
- The default
place to compute and print tax is AFTER the S&H
- Most states
require that S&H is taxed unless exact Shipping
charges are computed
- A few states
do not require S&H to be taxed
- Before this
rule is applied MOF looks for any exceptions listed
in the next setting
@exceptions
= ('STATE');
- Defines a
state or states to be exceptions to the before / after
rule
- Use only
the acronyms listed in the Shipping destination drop
down list
- Make sure
and follow the exact format using single quotes around
STATE
- Separate
multiple states with a comma ('DE','MT','NH','NJ')
Note: MOF will first look for shipping destination states
here before it applies the tax_before rule. A state listing
here will reverse the rule however it is set. If tax_before
is turned off (0) and an exception state is matched, then
tax will be computed and printed before the S&H charges,
or visa versa.
- Set the exceptions
to null if you don't want MOF looking for anything here.
- @exceptions
= ();
- This
is NOT a zero it is two closed parentheses
What can
these settings do?
- Turn off
any discount computations
- Compute a
discount for each N number of items - volume discount
- Compute a
discount for each X number of dollars - percentage of
dollars spent
- Compute a
discount as a one-time rate by number of products or
dollars spent
- Limit the
discount to a minimum / maximum amount
Think about the discount in these two ways:
- As a percentage
of the total dollars spent
- Or as a set
rate per N number of items purchased
These settings apply simple discount rules and rates globally, they cannot
produce an arbitrary discount schema that is uneven. The
settings can apply a set rate to a set number of products,
or a set percentage or dollar amount to a set number of
dollars, or a one-time discount for a set number of products
or set dollar amount, and/or within one-time minimum or
maximum limits.
Here is an example
of an uneven discount schema, which cannot be produced
by MOF settings, but can be produced by custom code:
Discount
$ 2.00 first 3 products, and $ 1.00 every product thereafter
until 10 products are purchased, then discount every
additional purchase $ 1.50.
- The discount
is subtracted from the gross amount, off the top.
- All the remaining
computations are based on that sub total, the net
amount.
- The handling
and shipping computations are based on the amount after
discount.
- The tax is
computed on the Net Amount if before S&H
- However S&H
is always based on the sub total after discount, the
net amount.
- And tax is
computed on the [Net Amount + Handling + Shipping] if
after
Configuration details
$use_discount
- Simply turns
on (1) or turns off (0) any discount computations
- No discount
is computed or displayed if turned off (0)
- If turned
on (1) and <repeat_discount> turned off (0) then
a one-time discount is applied
$rate_discount
- This is the
dollar amount (n) to be applied to the computation rules
below
- There is
a direct relationship between this rate and these two
settings
- Number
of Products <num_discount> or
- Amount
of Purchases <amt_discount>
$repeat_discount
- When enabled
(1) this tells MOF to apply the rate assigned to <rate_discount>
at each interval set by either
- Number
of Products <num_discount> or
- Amount
of Purchases <amt_discount>
- If turned
off (0), then the rate assigned to <rate_discount>
is applied only one time when the interval is reached
defined by either
- Number
of Products <num_discount> or
- Amount
of Purchases <amt_discount>
$num_discount
- Defines the
increment (n) of total products that MOF will apply
the rate in <rate_discount>
to:
- DISCOUNT
= rate_discountX (Total products
ordered / num_discount)
- if result
> max_discount then discount = max_discount
- if result
< min_discount then discount = min_discount
$amt_discount
- Defines the
increment (n) of total dollar
amount that MOF will apply the rate in <rate_discount>
to:
- DISCOUNT
= rate_discountX(Total dollar amount of invoice /amt_discount)
- if result
> max_discount then discount = max_discount
- if result
< min_discount then discount = min_discount
Note: You can only enable (1) either
Number or Amount to be computed. If you fail to enable either
of them, or if you mistakenly enable both of them, then
no computations occur.
$min_discount
- Defing a
dollar amount (n) minimum to override computations
- If (n) is
defined, then all discount computations result in at
least (n) amount
- Disable this
setting (0) if you do not want a minimum
$max_discount
- Defing a
dollar amount (n) maximum to override computations
- If (n) is
defined, then all discount computations will no exceed
(n) amount
- Disable this
setting (0) if you do not want a maximum
Compute an
exact five percent discount on every dollar spent
$use_discount = 1 turn on the discount computations
$repeat_discount
= 1 repeat the computation rule at each increment
below
$num_discount = 0 do not use the number
of products increment
$amt_discount = 0.01 instead set the amount increment for each
penny
$rate_discount = 0.0005 set the rate to 0.0005 for each penny of
total amount
Compute a
one-time discount of $ 10 on all orders over $ 150
$use_discount = 1 turn on the discount computations
$repeat_discount
= 0 turn off repeating the computation rule ( use
one time )
$num_discount = 0 do not set a number
increment to repeat
$amt_discount = 150 instead set an amount increment to the $ 150
$rate_discount
= 10 set the rate of $ 10 to discount
- As you can
see this is a "non-repeating" discount, set to adjust
$ 10 after the first $ 150 spent.
Compute a five dollar discount for each $ 100 spent
$use_discount
= 1 turn on the discount computations
$repeat_discount = 1 repeat the computation rule at each $ 100
dollars
$num_discount = 0 do not use the number of products increment
$amt_discount = 100 instead set the amount increment for every
$ 100
$rate_discount
= 5 set the rate to $ 5 for each $ 100 of total invoice
amount
- This results
in a five dollar discount for every $ 100 spent. It
is not an exact percent on the penny like the first
example. The discount is only applied at each $ 100
amount spent. So, a purchase of $ 199 would show only
the discount applied to the first $ 100, not the remaining
$ 99. The total amount would have to reach $ 200 to
get the second five dollar discount.
Note: If
you use the minimum / maximum settings,
then these setting will test the final output from the computations,
and adjust the final amount accordingly.
If we add a
$min_discount and $max_discount to the last
example then we can create a situation where at least
a $ 5 discount is applied regardless of how much is spent,
and the discount does not go over $ 20.
Compute across
the board a $ 5 discount but not to exceed $ 20 with the
last example
$min_discount
= 5 set the minimum to compute to $ 5
$max_discount = 20 set the maximum to compute to $ 20
Compute a
$ 10 volumediscount for each 10 products purchased
$use_discount = 1 turn on the discount computations
$repeat_discount
= 1 repeat the computation rule for each 10 products
purchased
$num_discount = 10 compute the rate
each time 10 items are purchased
$amt_discount = 0 and do not use the
amount interval
$rate_discount = 10 set the rate to $ 10 for each 10 of total products
purchased
- Again, because
of the relationship between increment and rate, the
$ 10 is only credited when a full 10 items have been
purchased. Once would not receive any discount for 9
products, and one would only receive $ 10 for 19 products.
Change the increment to 1 and the rate to 2.75 and a
$ 2.75 discount would be applied for every product purchased.
What can
these settings do?
The exact same
things as the settings for discount explained in the preceding
section.
- Turn on /
off switch for computing handling charges
- Computing
a one-time handling charge
- Computing
a Percentage handling charge
- Computing
a Bulk or Volume handling charge
- Limiting
to a minimum or maximum handling charge
Configuration details
The handling
computations work exactly the same way as the discount,
except they are, of course, added to the sub total after
discount. The exact same schema is used. You can assess
volume handling charges, a one time charge, or a percentage
handling charge.
Compute a
five cent handling charge for each dollar spent
$use_handling = 1 turn on the handling computations
$repeat_handling = 1 repeat the computation rule at each defined
increment
$num_handling = 0 do not use the number of products increment
$amt_handling = 1 instead set the amount increment for each
dollar (1)
$rate_handling = 0.05 set the rate to 0.05 for each $ 1 of total
amount
The shipping
computation schemas follow rules that are very similar
to the rules we have already been studying for Discount
computations and Handling computations.
Here's a quick
list of what the shipping configurations do:
- Automatically
detect an out of Merchant Country "foreign" rate
- Allow the
Customer to select between "standard" or "express" rates
- Settings
to define what are "standard" and "express" shipping
options
- Settings
to use a default "standard" or "express" shipping rate
- Configurations
to compute shipping charge by weight, volume, amount,
minimum, maximum, foreign, domestic, standard, express
The shipping computation rules work on a dollar
amount, or a number quantity. The dollar amount rules use
the Total Amount of products after a discount, the
If no discount is being used, then the rules
use the Total Amount of products. Both shipping and handling
charges are always using one of the two totals:
- Total
Amount with no discount or
- Sub
Total After discount
- Shipping
and handling charges are always computed independent
of any tax assessed.
- Shipping
and handling charges are always computed independently
of each other
- The number
quantity is based on the ShipCodes and not on the quantity
of products.
There are two sections to understanding Shipping
Charges:
- Determining
which set of rates the computation rules will use
This is
covered in the section - Shipping
Configurations - Methods Settings
- Setting
the computation rules
This is
covered in the section - Shipping
Configurations - Global Settings
And the section
- Shipping Configurations
- Individual Item Code Settings
The Methods Settings and Computation
Settings in the Global and Individual schemas
interact together. Both Global and Individual schemas have
settings for each of the four methods that can be use.
What can
these settings do?
- Automatically
detect a foreign or domestic shipping destination
- Allow the
customer to select a standard or express shipping method
- Assign your
own custom message to define "standard" or "express"
- Assign a
default method (standard or express) and disallow customer
selection
Configuration details
Four sets of
rates can be used:Standard, Express,
Foreign Standard, Foreign Express. So, you
are able to use four different sets of rate variables
which will be applied to the computation rules. The particular
set of rate variables being applied to your computation
rules, depends on how you configure the following options:
- Auto-Detect
where a foreign rate is needed
- Chose between
a standard or express rate
If you want to
use a Foreign Rate, then you must enable the Auto-Detect Foreign Country feature. If this feature
is disabled then you will not be able to apply out of country
shipping rates, as all rates will be handled as either Standard,
or Express only, with no use of "foreign shipping charges."
Enable this
feature by:
$use_ship
- 1
$use_country = 1
$match_country = "Merchant Country"
Note: the "match_country" value must come from
the drop down list on the OrderForm. You must use one
of the exact Country names in the Select Country Names
section found in this documentation - Appendix 3. Whenever a shipping destination
uses a Country other than the Merchant Country defined
in "match_country" then a foreign rate is applied.
Two other sets
of rate variables can be applied to the computation rules--Standard
or Express shipping
rates. You can allow the Customer to choose between these
two methods by enabling the "use_rates" switch.
This will place two radio buttons on the "Select Quantities
- Verify Information" page allowing the Customer to
select an Express rate if desired. When you enable this
feature, the default rate is "standard" unless the Customer
changes it to Express. You can also place your own text
defining what is meant by "standard" and what is meant
by "Express".
The settings
to use this feature are:
$use_rates = 1 allow the customer to choose between express / standard
rates
$msg_standard = "However you define what standard is"
$msg_express = "However you define what express is"
If you don't
want the Customer to choose between "standard" or "express"
rates, then you can disable the "use_rates" feature,
but you must then set a default rate to be used in the
computation rules.
Disable Customer
choices, and enable a default "standard" rate like this:
$use_rates = 0 do not let the customer
choose between express or standard
$use_standard = 1 instead set the default
rate as standard
$use_express = 0 and don't default as express
Disable Customer
choices, and set a default "express" rate like this:
$use_rates = 0 do not let the customer
choose between express or standard
$use_standard = 0 don't use standard
as the default rate
$use_express = 1 but use express as the default rate instead
Note: you may not have both the "use_standard"
and "use_express" switches enabled. If you do this
then nothing will be triggered for defining what the default
rate is. If you have the Customer choices enabled, then
it doesn't matter what you have placed in the default
settings, it will be overridden by the "use_rates"
Customer choices.
Note: when you get to the next section "Setting the
computation rules," then you will see that there are
settings for all four Methods --
standard, express, foreign standard, express foreign.
Make sure that you have placed values in all of the sets
of rate variables that you will be using in your particular
Method configuration.
For example,
if you don't use the Customer choices feature, and you
don't use the Out of Country feature, and want to apply
a $ 0.35 per pound standard
rate set to all invoices, and you don't want a minimum
or maximum limit, then you only need to have values for
the "standard" set of
rate variables:
Only standard
set of rate variables:
$use_ship = 1 turn on shipping charges
$use_country = 0 doesn't matter if foreign
or domestic
$use_rates = 0 customer doesn't have choice for standard or express
$use_standard = 1 the standard settings are the default
$repeat_shipping = 1 for every increment in $num_shippping repeat
computation
$num_shipping = 1 apply the rate 0.35 to each 1 pound of weight
$min_standard = 0 don't use a minimum amount
$max_standard
= 0 don't use a maximum amount
$rate_standard = 0.35 apply 35 cents
per pound
For another
example, if you will be using all four possible options
-- standard, express, foreign standard, express foreign,
and you want a minimum shipping charge for any of these
options, then you will need to give all sets values. If
you leave these setting out, then the computations will
attempt to act on a zero, which will zero out your shipping
charges.
The rule
is -- make sure and place values for any of the four
shipping rate methods that your particular configuration
will be using.
What can
these settings do?
For any one
of the four methods the Global settings can:
- Compute shipping
as actual percentage of dollar amount spent
- Compute shipping
using shipcodes as weight per product by a rate
- Compute shipping
using shipcodes as shipping price per product
These settings cannot produce an uneven shipping
schema. They use set rules to produce global rates. You
have four types of methods and rates that are applied globally.
This is an example
of an uneven shipping schema:
From 1 to
3 products ordered charge $ 3.50 and then charge $ 1.00
for each item after that, up to a total of 15 products,
then the shipping charge is free.
While the actual code to compute this example
is fairly simple, and can be custom written in perl code
embedded in the special shipping section, the global rules
cannot produce an uneven computation like this.
Configuration
details
The Global shipping
computation rules work with the same strategy as the discount
or handling computations. The computations can be adjusted
to work with weight or dollar amount, and they can be
set for a one-time charge, or a repeating computation.
As already mentioned,
the simplest way to think about ShipCodes using the "Global
Settings" is to think of computing a rate per weight or
cost per item.
When using the
ship code computation rules you are computing thusly:
- shipping
charge = rate X [ ( shipcode X quantity ) / increment
]
- The number
quantity is based on the ShipCodes X Quantity of products,
and not on the quantity of products alone.
- When you
use the $num_shipping increment you are using
the actual ShipCode settings you made in your HTML OrderForm
input Page.
If you are using the dollar amount then you
are computing this way:
- shipping
charge = rate X ( sub total after discount / increment
)
- But, when
you use the $amt_shipping you are not using the
ShipCodes, you are using an option to compute shipping
charges based on total invoice dollar amount.
Understanding the computation rules:
There are four
sets of rates -- standard, express, standard foreign,
express foreign
The computation rules will be applied to the
set of rates for the selected Method
You define the
"computation rule" with the following three variables.
Then, depending on the Method selected, the "computation
rule" is applied to the appropriate set of rates.
$repeat_shipping
- When enabled
(1) this tells MOF to apply the shipping rate resulting
from one of the four shipping methods at each interval
set by either
- Total
quantity of shipcode values <num_shipping>
or
- Amount
of Purchases <amt_shipping>
- If turned
off (0), then MOF will apply only a one-time rate resulting
from one of the four shipping methods at the interval
set by either
- Total
quantity of shipcode values <num_shipping>
or
- Amount
of Purchases <amt_shipping>
$num_shipping
- Defines the
increment (n) of total shipcode
values that MOF will
apply the designated shipping
rate to:
- SHIPPING
= rateX [ ( shipcode X
quantity ) / increment
]
- if result
> method maximum then shipping = method's maximum
- if result
< method minimum then shipping = method's minimum
$amt_shipping
- Defines the
increment (n) of Total Dollar
Amount that MOF will apply the designated
shipping rate to:
- SHIPPING
= rateX ( Total Dollar Amount/increment
)
- if result
> method maximum then shipping = method's maximum
- if result
< method minimum then shipping = method's minimum
If you enable the "repeat_shipping" switch, then the computation rule repeats
for every N number of increments, or every N dollar amounts.
You set which increment to use, either a number increment
"num_shipping" or a dollar increment "amt_shipping" by assigning the increment value to which
one you want to use, and leaving the other one set to zero.
Calculate
a "standard" shipping charge of $ 0.35 per pound with
a minimum $ 3.95 shipping charge:
$repeat_shipping = 1 repeat the computation rule for every increment
$num_shipping = 1 set the number increment to 1 ( pound )
$amt_shipping
= 0 do not use the amount increment
$min_standard = 3.95 make sure there
is a minimum $ 3.95 standard shipping charge
$max_standard = 0 there is no limit
to assessing 35 cents per pound
$rate_standard = 0.35 set rate to 35 cents per each 1 ( pound )
The num_shipping increment is 1 ( whatever ), so a 0.35 rate
is applied to every 1 (whatever) units, and if minimum
rate is set, then the minimum will be assessed, until
the rate is over that value -- then anything over $ 3.95
is computed at 35 cents per 1 (whatever). The ShipCodes
in your HTM OrderForm input Page are relative and can
be anything; however, you need to have some plan for your
ShipCodes so that computations are meaningful.
Now, make sure
and set all the other rate values if you are using all
four methods. For example, if you have enabled $use_country
and $use_rates then it is possible that any one
of the four sets of rates may be selected. So, you need
to make sure you have all four sets of rates defined.
Note: the above example assumes that you used a "weight"
schema for assigning ShipCodes in your HTML OrderForm
input Page.
Note: you only get to configure one computation rule.
For example, you can't calculate an "express" shipping
charge of $10.50 for anything from 1 to 10 pounds, and
then assess a $1.25 per pound rate for anything over 10
pounds. This rule really uses two different increment
settings.
You can also
just use a configuration based on the Total dollar Amount
of products purchased, for example:
Set up rates
that would include insurance based on dollar value.
$repeat_shipping = 1 assess $ 1.35 to
every $ 10 spent
$num_shipping = 0 do not use the ShipCodes schema
$amt_shipping
= 10 instead compute $ 1.35 for each $ 10 spent
$min_express = 12.95 make sure there
is a minimum $ 12.95 express shipping charge
$max_express = 0 there is no limit for
maximum
$rate_express = 1.35 set rate to $ 1.35 for every $ 10 spent
Note: you can't use one set of computation rules for
"standard" and another set of rules for "express."
You can only create one set of computation rules which
will be applied to whichever set of rates is chosen by
the method configurations.
What can
these settings do?
- Group products
together by shipcode and
- Apply a set
of different rates to each group
The way to think
about the individual item system of shipping definitions
is to think of a shipping cost per item, rather than a cost
per pound as in the "global" ( weight ) examples. All products
with a ShipCode of 1 may cost $ 0.35 cents to ship "standard"
Method, yet cost $ 0.75 cents to ship "foreign standard"
Method. Then, all products with a ShipCode of 2 may cost
$ 1.35 to ship "standard" Method. So, you can set each Method's
rates for each different ShipCode used, then assign your
products to groups of ShipCodes, or give all products their
own unique ShipCode.
- When $use_items
has a positive integer value you have enabled this feature,
and No Global rates will apply. If $use_items
is disabled, then whatever you have set in the Global
settings will be used.
- Set the value
of $use_items to the number of ShipCodes you
want in your system of individual definitions.
- Now, you
will define the settings for each individual ShipCode
by giving values to a 12 item array for each
ShipCode in your system. In the configuratoin file packaged
with Merchant OrderForm there are 4 sets of example
definitions:
- @items1
= (3.95,5,0.25,4.95,6,0.55,4.95,6,0.65,5.95,0,1.05);
- @items2
= (4.95,6,0.35,5.95,7,0.65,5.95,7,0.75,6.95,0,1.15);
- @items3
= (5.95,7,0.45,6.95,8,0.75,6.95,8,0.85,7.95,0,1.25);
- @items4
= (6.95,8,0.55,7.95,9,0.85,7.95,9,0.95,8.95,0,1.35);
- Lastly, any
minimum / maximum settings you have for the four sets
of Global Settings, will be applied after all individual
computations are made, as an overall minimum
- maximum. So, make sure these are set to zero if you
don’t want this last test computation to occur.
With each array
@items1 you are basically creating individual definitions
as you did in the section above on "Global Settings."
The "Global Settings" has 12 values defined:
|
$min_standard
$max_standard
$rate_standard
|
These
set the values to be used in computations whenever
the "standard" rate Method has been chosen |
|
$min_express
$max_express
$rate_express
|
These
set the values to be used in computations whenever
the "express" rate Method has been chosen |
|
$min_Fstandard
$max_Fstandard
$rate_Fstandard
|
These
set the values to be used in computations whenever
the "Foreign Standard" Method has been chosen |
|
$min_Fexpress
$max_Fexpress
$rate_Fexpress
|
These
set the valued to be used in computations whenever
the "Foreign Express" Method has been chosen |
The 12 elements
in the item arrays correspond to these same settings.
Remember to be very careful in making these arrays, and
keep commas exactly between each of the 12 values as in
the examples included in the packaged configuration file.
Here's what the elements correspond to:
|
Standard
Method
|
Express
Method
|
Standard
Foreign
|
Express
Foreign
|
|
min
|
max
|
rate
|
min
|
max
|
rate
|
min
|
max
|
rate
|
min
|
max
|
rate
|
|
0
|
0
|
0.35
|
0
|
0
|
0.45
|
0
|
0
|
0.55
|
0
|
0
|
0.65
|
The above example
has set No minimum or maximum rules, but has set the following
rates to be computed for this ShipCode (let's say it's
ShipCode 1):
If the "standard"
Method was selected a $ 0.35
rate would be applied to the total quantity of products
that had a ShipCode = 1. When the script
finds a product ordered with the ShipCode = 1,
then it goes to the array @items1 and extracts
the settings for whichever Method is active.
Important: you must at least enter a zero for each element,
and you must separate each element with a comma.
When you set
@items2 with a completely different set of definitions,
then you can create extremely individual rates. The "standard"
rates for all products with a ShipCode = 2 could
be very different than the rates for ShipCode = 1.
If you wanted
to give all orders with the ShipCode = 1 a minimum
of $ 12.50 for the Express Foreign method no matter how
many number 1 items were ordered, and anything after $
12.50 would adjust an additional $ 0.50 per each number 1 item ordered, then:
$use_ship
= 1
$use_items
= N where "N" is the number of unique item arrays
you will be using
@items1 = (0,0,0,0,0,0,0,0,0,12.5,0,0.5)
If you wanted
to make sure that a minimum of $ 12.50
shipping charge was applied to any set of orders
where someone chooses the Express Foreign method
of shipping, then just add the global setting:
$min_Fexpress
= 12.5
The $use_items
schema only uses a number counting and not an amount.
An amount is not needed because this coding schema is
a distinguishing characteristic in and of itself -- all
ShipCodes of 1 are of a particular type item, with a particular
shipping requirement for a given Method. The script totals
the quantity of products with the ShipCode = 1, computing
the rate for the active Method, looks for any minimum
or maximum rules to apply, and keeps a summary of the
computed shipping charges for that ShipCode's quantity
of products. Then the script does the same for the next
ShipCode in the system, ShipCode = 2, and so on.
Also, a repeating
or one-time setting is not needed because a minimum /
maximum setting for each @items definitions is
able to set a one-time charge for that ShipCode. These
values will limit that ShipCodes summary total to a high
/ low value. For example:
For the quantity
of products with ShipCode =1
A one-time
$ 4.50 charge for "Foreign Express" Method of
shipping is set this way:
@items1 = (0,0,0,0,0,0,0,0,0,4.5,4.5,0)
As you can see,
the one-time shipping charge of $ 4.50 is applied as the
summary of ShipCode 1's total.
Important: the $ 4.50
is applied to the summary computations for ShipCode
=1 only. If someone orders only one item with a ShipCode
= 1, then $ 4.50 will be the total shipping charge. However,
if products with other ShipCodes are ordered on the same
invoice, then, while all ShipCode = 1 products will total
to $ 4.50 only, the actual final shipping amount on the
invoice will be a compilation of ALL the summary
totals for each ShipCode set of rules in your system where
someone has ordered a quantity of products for any given
ShipCode.
Also, if you
use the Minimum - Maximum settings in the global
functions for Standard - Express - Standard Foreign -
Express Foreign, then you can create an "overall"
Minimum - Maximum shipping charge for the method used.
This means that after all individual computations are
compiled and summarized for each ShipCode, then a final
total can be tested against a global "Minimum" or "Maximum"
for the shipping total. To make use of this feature just
give the global settings your limit values for any of
the shipping methods you want to apply this to. For example:
You can set
an overall Minimum shipping charge of $
18.95 for any out of the country express
orders, by setting:
$min_Fexpress = 18.95 in the "Global Settings."
If you don't
want any overall Minimum - Maximum to apply for a particular
method, just leave it set to zero. If these global settings
are all set to zero while using the individual item ship
code system, then there will be no "global" adjustments
to the overall shipping charges. The only Minimum - Maximum
adjustments that will be applied are those you set in
the item arrays
Note: you cannot use a ShipCode in your HTML definitions
that has not been defined in your system of shipping codes
in the configuration file, and when defining your system
you must use only sequential numbers starting from one.
Example:
if you need to have 4 different ShipCodes, then you can
only use the numbers 1, 2, 3, and 4 when putting a ShipCode
value in your HTML OrderForm input page. You can't use
a system of 4 ShipCodes and put a 5 as a ShipCode value
in your HTML OrderForm definitions, because the script
won't look for a "5" when computing each item's ShipCode.
The script will only look for the values 1, 2, 3, and
4 in a system of 4 ShipCodes. Likewise, you can't define
a system of 4 ShipCodes in the configurations, and try
to use values in your HTML definitions starting with 5,
6, 7, and 8. I guess I really didn't need to say all this
paragraph above, but you never know what some energetic
soul might hope to do.
What can
these settings do?
- These settings
allow you to install an unlimited number of custom fields
on your OrderForm input Page that can be processed by
MOF and included in Logs, Mail, and the Select Quantities
verify information page.
Configuration details
$use_fields
- This tells
the scripts that you will be using custom fields
on your HTML OrderForm input Page. And tells MOF to
look for your field names as assigned, and pass them
throughout the program to include in mail or logs.
$title_fields = "Other Information About Hobbies and Interests"
- This is where
you define what the group of fields will be called whenever
their contents is displayed on the Information Verification
Page, or in the main log file, or in the Merchant or
Customer email.
For example you may create several new fields about hobbies and interests.
Whenever any data is entered into those fields, then it
will be displayed in the Merchant email like this:
Other
Information About Hobbies and Interests
- Type of
Hobby: I like computing
- Area of
Interest: I like watching good movies
Okay, now we need to do the array thing again.
There are three
arrays that define:
- What "name"
you are using in the HTML OrderForm input Page
for each new field
- What title
you would like to print out next to the contents for
each new field
- Whether to
include or exclude each new field in the Customer email
notification
@custom_names = ( 'hobby','interest' )
- In the example
above, this tells the scripts that two new field names
exist in the OrderForm. These are the names you give
to each field in your FORM input tags. The sample OrderForm
called <ordersample14.html>
shows an example of this, and the names correspond to
the six new fields defined in the example <orderconfig.cgi>
in this package.
Continuing with
our example above, you would create the following input
tags in your HTML OrderForm input Page:
- <input
type="text" name="hobby"
size=30>
- <input
type="text" name="interest"
size=30>
The scripts now
know what to look for when parsing and printing information
in your new fields. And you can add as many names as you
need to as long as you keep with the exact format for listing
elements in the array-- using single quotes to enclose each
name, with a comma inserted between each name, enclosed
in parenthesis.
@custom_titles
= ( 'Type of Hobby','Area of Interest' )
- The elements
in this array correspond to the @custom_names array.
Put the title that will be listed and printed for each
corresponding name. Make sure the order is exactly the
same. This example will result in printing the titles
like we have been working on:
- Type
of Hobby: I like computing
- Area
of Interest: I like watching good movies
@customer_fields
= ( 1,1 )
- This array
corresponds element for element with the @custom_names
array above. It acts as switches to turn on (1) or turn
off (0) the data display for a corresponding "name"
contents. It switches whether that corresponding "names"
data is displayed in the Customer Email notice. This
feature only effects the Customer Email notice. There
are no switches to turn on or off whether your new fields
display in the log files or the Merchant Email -- all
custom fields will be displayed in those areas.
The above example allows for both the <name="hobby">
and the <name="interest"> contents to be displayed
in the Customer Email. If you wanted to allow only the <name="hobby"> contents to be shown in the Customer Email
notice, and not the <name="interest">
then:
- @customer_fields
= ( 1,0
)
Important: The three arrays correspond identically to
each other, so all three must have the exact same number
of elements.
What can
these settings do?
- Override
all shipping configurations except your own custom code
- Turn on or
off validation rules for Online Checking input fields
- Show and
process Checking input fields completed without validation
- Turn on or
off the routines to force checkbox for final "cyber
approval"
- The customer
will have to check the correct box to complete transaction
- If customer
aborts the "cyber approval" form you can redirect them
anywhere
- Turn on or
off the file locking switches
- Turn on or
off the LOG files
- Turn on or
off the LOG DataBase files
- Turn on or
off sensitive information displaying in the Mail
Configuration details
$special_ship
- Enabling
this (1) triggers an override of all shipping computations
- Diverting
MOF to look for custom shipping code
- In the file
<ordercount14.cgi> around LINE 460 is space to
write your own code
- There are
notes there on variables you can use and resulting variables
required
- If you enable
this without writing some code then shipping will be
zero everytime
- Whatever
code you use must produce two unformatted numeric variables
$check_validate
- This simply
turns on (1) the scripts input validation rules to check
and see if all the fields for "checking" information
are filled out. Turn it off (0) if you don't want to
validate these input fields. Also, make sure and turn
it off, if your OrderForm input page does not include
these fields, because the script will attempt to validate
the input.
$show_check
- Turning this
on (1) allows any completed input from the Checking
information section on your OrderForm to be passed and
processed and printed in logs, or mailings even if it
has not been validated. This is for those who aren't
using Online Checking, and don't care if all the fields
are completed or not, but would like whatever is completed
to print and pass through. If you use check_validate
this setting is redundant.
$cyber_check
- Turn on (1)
or turn off (0) displaying the "cyber permission" routines
- If enabled
(1) then the customer is forced to check a box for final
approval for the Merchant to draft their Online Checking
or Credit Card accounts. If the customer fails to provide
the correct response, then they are redirected to a
URL that is set in the next setting.
Note: if this is turned on (1), and
you attempt to execute the final processing file <orderfinal14.cgi>
as a direct call rather than submitting from the previous
process, then the final script will hang. This sort of thing
should only be done for testing purposes anyway. But it
won't test unless you disable (0) the <cyber_check>
setting. This is because the final script is attempting
to verify whether "cyber permission" was sent or not, and
of course it wasn't--nothing was sent and MOF wants to check
for permission.
$redirect_url
= "../index.html";
- If "cyber
permission" fails on the second try, then the browser
is redirected to a location that you define in this
setting. It can be a relative URL or a full URL somewhere
off in the Cyber Universe.
$redirect_name = "Your Redirect Page Name";
- This is the
name that will appear on the final "cyber permission"
page saying that they will be redirected to this page
here. Then name of the page.
$lock
- This enables
(1) or disables (0) the file locking for all the files
that the script will be writing to. It's VERY
IMPORTANT that you turn this on if you
plan to keep the log files. Unless you get some furious
activity all happening at the same time on your server
(which I hope will happen to all who use Merchant OrderForm),
then the files are mostly okay. However, without file
locking turned on, all it takes is for two hits on the
same log file at exactly the same time and all your
data could be wiped out ! Of course, exactly the
same time in computer terms means exactly the same nano-second,
which can happen.
I ran versions 1.1 on my server for 6 months without file locking and
there were never two hits on the write files at exactly
the same time, but you don't want to take a chance. Turn
it on especially if you're using Unix, Linux type machines,
since it's tested to work on those type servers.
$log_file
- Turn on file
logging (1) or turn off (0) file logging
- This enables
(1) the script to write all invoices into a master logging
file. The log file can be named anything, as long as
you configure the name in the File Locations section of this configuration file.
The file called <orderlog.dat> in the package
is the master logging file. Also, you'll want to read
the section An important note about Security to make
sure this file is not accessible from the entire whole
world. Once you turn this on, you don't want Web surfers
reading your orders that have been logged.
$rdb_file
- Turn on (1)
or turn off (0) logging to the ASCII delimited DB files
- This turns
on another logging feature where the final processing
script writes to three ASCII flatfile database format
files. Again, you can name these files anything you
want as long as you change the names in the File
Locations section of this configuration file. In
the package these three files are called:
- ordermain.rdb
- orderorders.rdb
- ordercustom.rdb
As with the other log file, you'll want to
read the section An
important note about Security to make sure these
files are not accessible from the entire whole world. Once
you turn this on, you don't want Web surfers reading your
orders logged.
The three RDB
files provide a way to import all invoice information
into any PC Database program that will import from ASCII
flatfile delimited text files, like Access 97. The three
files also provide your invoices sorted to separate files
so that when you import the information you can build
a relational design. You can see how the three files are
printed and related in Appendix
4 - Structure of the related RDB files.
$mail_info
- This enables
(1) or disables (0) whether you include sensitive information
(credit card numbers and checking account information)
in the email that is sent to the Merchant.
No sensitive information is ever sent to the Customer.
Of course, the Merchant mail will have to be turned
on for this to work.
What can
these settings do?
- Define your
Web Site name to be listed throughout the MOF processing
screens
- Define the
link to your Main Web Site as a link back from the processing
screens
These settings just set up your logo, or site
name to appear on the invoices, and configure the site page
or location that will be linked to the site name or logo.
So, when the site name or logo is clicked, you will return
to the identified home page or site.
Configuration
details
$site_name
= "Your Site Name Here"
- This is the
Web site name that appear at the top left of all the
screens, and throughout the ordering process. It also
appears at the bottom of each page as a credit line.
You can just use a text name as in the example above,
or you can put in HTML tags for font, color attributes,
or even an image logo.
The example configuration file included in
the package shows how an image is used in place of the site
name. This way the logo displays at those places wherever
the $site_name variable appears in the scripts.
Here's an
example of using a logo
$site_name = "<img src=\"../images/scripts.jpg\"
border=0 width=91 height=26 alt=\"Your
Site Name\">";
Important: If you use double quotes to enclose this HTML
tag, then you'll have to use the perl escape character
"\" preceding quotation marks or other sensitive characters
like @$, etc. Study the example above to see that where
a double quote appears in HTML tags, it is preceded by
the left backslash. This tells the perl interpreter that
the next character is a literal character, since double
quotes is a special character in perl. You can simply
enclose the whole thing in single quotation marks, which
tells perl that it's all literal characters.
Here's an
example of using font attributes to highlight a plain
text site name
$site_name = '<font color=navy><strong>My
Site Name</strong><font color=black>';
$plain_name
= "Your site name in plain text";
- This is simply
plain text to be used at different places where HTML
is not allowed, like in the log file, and in the email
notices. Make sure it's plain text only.
$base_url =
"../";
- This is the
root directory for your Web site. You can use a relative
location as in the example above, or you can use the
entire HTTP url. Just make sure the address ends with
a backslash. Another example is "http://www.yourdomain.com/"
$main_filename
= "index.html";
- This will
be appended to the $base_url to identify the
complete address of the page you want someone to return
to when they click your logo or site name.
What can
these settings do?
- This creates
the Merchant address, city, state, zip, phone, fax.
The on / off attributes allow you to assign beginning
and ending HTML attributes surrounding the Merchant
information on the invoice. It's pretty straight forward.
Configuration
details
$on_attributes
= "<strong>";
$off_attributes = "</strong>";
- Assign the
beginning HTML tags to how you want your Merchant information
displayed, and then assign the "off" HTML tags for enclosing
your information. You can simply leave these blank and
your Merchant information will be displayed as formatted
in the script. Leave them blank this way, and don't
even leave a blank space in them.
- $on_attributes
= "";
- $off_attributes
= "";
The following variables identify Merchant address, phone, etc.
Make sure and enclose
your information in double or single quotes:
$site_address
= "111 Merchant Ave.";
$site_city
= "Austin";
$site_state = "Texas";
$site_zip = "77777";
$site_phone
= "444.444.4444";
$site_fax = "555.555.4444";
What can
these settings do?
- Tell the
scripts where all the files are it needs to work with
- Defines the
delimiter if using RDB file logging
Configuration details
This section
of configurations identify the file names and locations
of all the files used by the scripts. The first processing
file is not listed here, because it is started by your
HTML OrderForm input Page, when you do the FORM POST Action.
All other files that the scripts will need to work with
are identified by name and/or location here.
Remember: These files can be used by the processing scripts
only if permissions are set correctly. Even though the
file is listed in your CGI-BIN, if it doesn't have complete
write permissions, then the script won't be able to write
it. The script has built in error messages to tell you
if a needed file can't be opened by the script.
orderconfig.cgi
- This file
is identified in the opening lines of each of the three
processing files. There is a line that has the comment:
- #
Make sure you have the correct name for the CONFIG
file here.
- require
'orderconfig.cgi';
If you change the name of the configuration
file, then you will need to change its name within each
of the three processing files, as in the example above.
One of the most common reasons one might need to change
this name is to comply with a server set up that designates
the PL extension to run perl scripts. This file is required
and must have complete read, execute permissions.
orderform14.cgi
ordercount14.cgi
orderfinal14.cgi
- These are
the second and third processing files, respectively.
They process the orders from computations to final invoice
and printing of the logs and email notices. Both of
these files are required, and must have complete read,
execute permissions to run.
ordernumber.dat
- This file
is where the final processing script retrieves the next
increment for the invoice number to be used. The example
starts the numbering at 1000, but you can put in any
number you want. Put in 235145657, and folks will think
you're selling at the rate of Amazon.Com, or Microsoft
J This is a required file, and must have complete read,
write, and execute permissions to run.
orderlog.dat
- This is the
main log file. You don't need to have it in your CGI-BIN
if you don't enable the $log_file switch to use
it; however, if you enable the $log_file switch
then the final processing script will go looking for
it. It will need to have complete read, write, and execute
permissions to work.
Warning: This file contains sensitive information,
and you want to make sure it cannot be accessed by just
anyone with a Web browser. Read the section An
Important note about Security to understand how to work
with this issue.
ordermain.rdb
orderorders.rdb
ordercustom.rdb
- These three
files are the PC Database import files. They are only
required if you enable the $rdb_file switch to
use this feature. If you enable the $rdb_file
switch the final processing script will go looking for
all three of the files to write stuff to.
Warning: These files contain sensitive information,
and you want to make sure they cannot be accessed by just
anyone with a Web browser. Read the section An
Important note about Security to understand how to work
with this issue.
The simplest
way to make everything work is to just dump all these
files in your CGI-BIN, then you only have to use the filename.cgi,
and you don't have to mess with using absolute addressing
to identify location. This is what we did in the Quick Start section. The script looks for the
files in the local directory first, unless directed to
look elsewhere.
If you need
to mess with absolute addressing, then this would be the
entire pathway as if you were identifying a place on your
hard drive, except you are identifying an actual location
on your server's hard drive. It is not the HTTP
address used in Browsing the Web. The HTTP address is
a virtual address, and is not an actual pathway on your
server's hard drive. It is a virtual pathway, known by
the server's HTTP software, but the scripts can't write
or read files via the Web HTTP address or location. The
scripts must have the actual hard drive location of files
it will be writing to or reading from.
An absolute
pathway would look something like this on my local computer:
$logfile_path = "c:/HTTPd/Documents/orderform/orderlog.dat";
This example
places the main log file in a completely different directory
than the CGI-BIN, and gives the absolute (actual) "pathway/filename.dat"
so the script knows exactly where on the hard drive to
write something. The script can't write through a virtual
pathway like a Web address. It can only write to a hard
drive.
An absolute
pathway might look something like this on a server's hard
drive.
$logfile_path = "/usr/u/n/name/public-web/orderform/orderlog.dat";
This example
writes to the main log file located in a sub directory
on my public-web directories, providing the file has the
correct permissions. It allows you to write the file in
a location other than the CGI-BIN where the scripts reside.
Again, this cannot be an HTTP address like you use in
your Web browser, since a Web page is only a virtual location
designated by the servers HTTP software.
Now, just make
sure that you identify the filename (and locations if
need) for all the following processes. You can change
the filenames if you want, but then make sure you identify
the correct file name in the file location settings below:
- $cgi_count
= "ordercount14.cgi";
- $cgi_final
= "orderfinal14.cgi";
- $number_path
= "ordernumber.dat";
- $logfile_path
= "orderlog.dat";
- $rdb_main
= "ordermain.rdb";
- $rdb_orders
= "orderorders.rdb";
- $rdb_custom
= "ordercustom.rdb";
The above listing of file settings show that all the necessary files are
located in the same directory as the original script and
configuration file, usually the CGI-BIN.
There is one
lone setting in this section which is used to define a
delimiter for the RDB file logging. If you use the RDB
logging, then you'll need to define a delimiter. This
is a good one to use.
$delimit
= "~";
- In this example,
the tilde character is used as a delimiter for all the
data storage in the three RDB files. You can use any
character you want, but you don't want to use a common
character that will confuse how you import the files.
The delimiter character
acts as a separator between fields in the ASCII flatfile
database log files. When a program reads these files, it
starts a new field every time it encounters the delimiter.
If there is no data in a particular field, then a null is
placed in the place of the data. In the ASCII flatfile delimited
database, each line is a record, and each field is separated
by the delimiter.
Here's an
example of how the delimiter works in the RDB files.
1004~1004-512-444-7777~8/12/98~11:30:02~Master Card~Customer
The above example
has logged one record and six fields. There is more information
on the exact structure of the ASCII flat file delimited
database files in Appendix 4 - Structure of the related RDB
files.
What can
these settings do?
- Turn on or
off sending order invoices by email to the Merchant
- Turn on or
off sending order confirmations by email to the Customer
- Identify
your server's mail program location
- Identify
the email account to send Merchant invoices
- Identify
a URL for the Merchant to include in Customer mail notices
Configuration details
This is the
one set up part that people have the most trouble with.
That's because server mail program locations and set ups
vary more than other things. The trick to getting the
mail working on Merchant OrderForm is to get the correct
mail program location identified, and of course to have
the correct send to address.
Once your mail
program location is identified, then you can send mail:
- To the Merchant
- To the Customer
Getting the location
of the server's mail program set
$mailprog
= '/usr/sbin/sendmail';
- This setting
is the location of your server's mail program. "Sendmail"
is a common Unix type mail program, and the above is
a typical location. You may need to ask your server
admin what kind of mail server you have and where it
is located. Perhaps, go to some scripts that you have
working on your site, like maybe the ever popular formail.cgi
to see how it defines the location of your server's
mail program, and then use that exact definition for
$mailprog here.
Any installation
of Merchant OrderForm will have to be linked to a mail program
that simulates "Sendmail." Here's an example where Qmail
is being used as the server's mail program.
$mailprog
= '/var/qmail/bin/qmail-inject';
- If you are
using "Qmail" then this might be a typical location
for a server's "Qmail" program.
As far as setting
up the email on an NT platform, people have to obtain a
windows version of sendmail or blat in order
to accomplish the same thing sendmail offers unix users.
I have heard suggestions about running an NT mailer called
Imail from Ipswitch, which has a client program that simulates
sendmail. Just put the path in for the client program and
point it to the .exe file. I think Imail may be a
little pricy.
The program
Sendmail for Windows has also
been recommended for NT applications, and is more affordable.
A possible configuration is to install it on the NT Web
Server Drive under D:|mail and then add it to the
NT Environment. Then identify the address for Merchant
OrderForm as:
$mailprog
= "/mail/sendmail";
Where you
send the mail to:
$myemail
= 'yourname@domain.com';
- You also
need to tell the mail program where to mail the Merchant
invoices. Simply put in your email address here.
Warning: See the notes in the
section called An important
note about security about where you are sending mail
to when you send Merchant invoices via email.
Most problems
with the mail portion are as mentioned above, the sendmail
or sendmail simulated program is not identified correctly.
Once this part is working, just turn on the switches to
send the mail.
$merchantmail
- By turning
this switch on (1) you are sending a copy of each invoice
to the Merchant at the email address defined in $myemail.
Remember,
you can include or exclude sensitive information like credit
card numbers and checking account information by setting
the switch $mail_info in the Other Switch Section of the configuration file.
It is best to send mail only within the same server so that
it does not go out over the internet. If you must send the
Merchant order out over the internet, then disable the $mail_info
switch, so that sensitive information is not mailed over
the internet, or find a way to send the sensitive information
via some kind of PGP encryption protocol, (Pretty
Good Privacy) encryption software.
Warning: See the notes in the section called An important note about security about where you
are sending mail to when you send Merchant invoices via
email.
$customermail
- By turning
this on (1) you are sending the Customer an email receipt,
provided that they enter a valid email address on the
OrderForm. If this switch is turned on and no email
address is entered, then no Customer email notification
will be attempted by the script; however, if a bogus
email address is entered, then the final processing
script will send a notice through the mail program identified.
In turn, the server's mail program will notify you or
the server admin that it was an undeliverable mail message.
Not A Warning: This setting enables or disables mailing a
Customer Order Verification. It does not need any encryption,
since it does not contain the credit card numbers, only
an invoice verification, and thank you note.
One last
mail setting:
$site_location
= "http://www.yourdomain.com/";
- This setting
is simply the location of the Merchant's Web Site. It
is used only in the Customer email receipt as a signature
line, and way to reference the Merchant's Web Site in
the Customer email notification.
Here are some
important recommendations about security with your Merchant
OrderForm set up.
Use SSL on
a virtual domain when available
I recommend
that you use a secure web server SSL (the https:
protocol) for transport of the FORM data to your web site,
and that you keep the log file of invoices secure while
on your server .. Make sure the log file doesn't live
in a Public Web access area. A virtual domain would be
secure, but not a simple user Public Web area. The Log
file would be unsecured with a simple user Public Web
area, and you wouldn't want to store credit card numbers
like this. Make sure it's on a secure virtual domain web
site.
SSL is
a function of your server's software, so you'll need to
contact your server admin on how to send your CGI scripts
through their HTTPS protocol and their site certificate.
Once you have the HTTPS address to use, then you will
call up FIRST your HTML
OrderForm input Page through this secure HTTPS
protocol.
The link
to your OrderForm input Page from wherever will be through
the HTTPS protocol.
<a href="https://yoursecuredomain.com/orderfor.html">Place
your order here</a>
Now, any information
between the browser and the script processes is encrypted
via the HTTPS protocol, until you exit the last CGI process,
or make a browser call to a non HTTPS location. When you
exit the last CGI processing file, then you will be leaving
the secure area.
If you don't
have a virtual domain with strict permissions, and you
put the DAT file and the RDB files that log the invoices
on a Public-Web set up, then at least give the DAT file
and RDB files some very confusing name like <BFGIZ23432datafile.dat>
and prevent a Web browser from reading a listing of your
cgi-bin directory. Place an <index.html> file that
reads "NO Access to this area" or something like that
in your CGI-BIN, then whenever a browser tries to get
a listing of the CGI-BIN directory, it defaults to the
index.html file which has a message "No Access to this
area."
A virtual domain
is set up with stricter permissions, and usually forbids
access from Public Web inquiries trying to access a file
on the CGI-BIN via the Web.
If you enable
the email options to have the Merchant receive a copy
of the invoice via email, then use some form of encryption,
like PGP. If you are mailing to an account on the same
server as your OrderForm then it will be processed locally
and should not go out over the internet. If mail account
and OrderForm processing files are on the same server,
the mail would be processed internally by the server,
and not open to the Internet mail exchange. Make sure
it's on the same server, or use encryption.
PGP encryption
is a utility program that is installed to process your
mail. I don't know much about setting these up. But PGP
would be set up as a program that you sendmail to, instead
of the regular sendmail program. If you want to email
me some more information of using PGP with Merchant OrderForm,
then I'll put you on the permanent list of registered
users with a lifetime membership.
It is considered
professional to state on the opening order FORM whether
your process is secure or not ..
Here are some
brief things you can check to make sure you have installed
the scripts correctly on your Unix based server.
- Check
the location of the perl interpreter. The opening
line in all perl scripts must contain
the server's location of the Perl interpreter. Make
sure this line correctly points to your perl interpreter.
Here's a typical location of the perl interpreter.
If you think
this line is not correct, then ask your admin where perl
is. Then you'll need to change this first line in all
the four CGI files in the package. If you have Telnet
access you can go to the unix prompt and type in..
>whereis
perl
This will tell
you the location of the perl interpreter.
Here are some other locations:
- #!/usr/bin/perl
- #!/usr/local/bin/perl5
- Make sure
that your are pointing the top line to "perl 5." Some
servers have perl 4 as a default installation, and the
Merchant Order Form needs perl 5 to run.
If you have
Telnet Access or using NT, you can type from the prompt
or unix shell
>perl
-v
Which will give
you the version of perl that you are running.
- Make sure
and FTP the ASCII files and script files in "ASCII
transfer protocol." Do Not transfer
the files binary. You can transfer the image files binary,
but not the other files.
- Make sure
you have made the three processing files and one configuration
file to have complete executable permissions, which
is a CHMOD <filename>
755 on Unix servers.
- Make sure
that both DAT files and all three RDB files have full
write permissions, which is a CHMOD <filename> 777 on Unix type servers.
- Make sure
your CGI-BIN has executable permissions as well.
- Make sure
you have the correct file name extension for your server.
Many servers identify CGI calls with the <filename.cgi>
extension, but some servers use the <filename.pl>
extension to signify CGI executable files. If your server
used the PL extension, then you'll have to rename the
four CGI files to <filename.pl> and you'll
also have to go into each of the three processing files
and change the line
"require
filename.cgi" to "require filename.pl"
- If your server
uses the <finename.PL> extension for cgi calls,
then make sure you have changed the two settings in
the configuration file that identify the name of the
last two processing files.
- $cgi_count
= "ordercount.pl"
- $cgi_final
= "orderfinal.pl"
- Use only
an ASCII text editor to modify the files, and
store them in Unix format if you can. Don't edit the
files with an editor that places unknown or hidden formatting
into the file. All files should be strictly ASCII format.
- Since you
are placing the scripts and archives within the same
directory you don't have to worry about relative or
absolute pathways. There are no pathway adjustments,
except identifying the location of image files.
I have included
some of the common questions and installation problems
that people are having with Merchant OrderForm.
Here is a
list of the FAQ stuff:
Try not to embrace
the RONCO method for your shipping schema--if you buy
this I'll throw in this, and this, and yes, even this.
This is an uneven configuration and the existing rules
have no way of knowing how everyone around the World might
dream up that very special shipping deal guaranteed to
promote entrepreneurial fame.
It's probably
best that you get the basic idea of how MOF uses shipping
rules first, and then see if you can fit your needs into
that schema, rather than the other way around.
Think about
the shipping computations in one of three ways:
- Compute shipping
based on weight per item
- Compute shipping
based on a set amount for each item
- Compute shipping
based on total dollar amount
MOF uses precise global rules, or precise group rules, which can vary
by four different methods, with some ability to limit minimum
and/or maximum shipping charges. It is set up to create
unlimited ways to apply global rules to an entire invoice,
or ways to apply group rules to groups of products. MOF
uses rules rather than complicated shipping tables.
Basically, you
can't do anything that is arbitrary or uneven with the
existing configuration rules. You can however, do anything
imagined by either writing your own perl code in the custom
shipping section, or having someone (like myself) write
the code for your custom shipping needs, even to the point
of using a complicated table of shipping charges.
This is an example
of an uneven shipping schema:
Shipping is
$ 3.50 for 1 to 3 items, and then $ 1.00 per each additional
item, up to 15 total items, where the shipping is free,
unless it's express, then shipping continues at $ 1.00
per additional item up to a total of 25 items, when if
becomes free.
This can be written
in about 8 or 10 short perl code lines, but can't be accomplished
from the MOF settings.
I'm looking
at the actual 1999 UPS shipping tables, and hope to be
working on a few "plug-ins" that will give MOF the ability
to consult free standing shipping tables in different
ways. One could use the actual UPS tables, or build their
own tables. I just need the time to get to this.
Yes, but it
can't consolidate them into one invoice.
The MOF scripts
will try to process anything you throw at them from anywhere
in the World from an HTML FORM submission. However, MOF
set up any cookies or reference that a particular OrderForm
was submitted from the same person who wants a consolidated
invoice.
You can have
hundreds of OrderForms which submit to only one location
of the scripts for processing, and MOF will throw invoices
back to the correct person, as fast as your computer will
run, but MOF processes only one OrderForm at a time.
Note: If you
use one location of MOF to process OrderForms from several
different sites, or several different locations within
the same site, then all LOGGING will be stored in the
same log file, because MOF uses the same set of configurations.
- You can create
multiple installations of MOF, each with their own separate
configuration file, and thereby, create separate LOG
and MAIL functions for different OrderForms.
- Or you can
set up a custom hidden field identifying where a particular
OrderForm originated. The reference will get stored
in your LOG files and/or MAILed to identify its originating
location.
- Also, with
some pretty simple programming, you could even create
code in MOF to recognize an OrderForm's hidden field
identifier from different locations and use respective
LOG files or MAIL configurations.
I'm researching
a few of these services, which seem to have interface
techniques that are easy to install. However, the Merchant
OrderForm v1.4 package you have doesn't have any built
in settings or configurations to just turn this on or
off.
Please contact
me RGA@IO.COM with the name of the authorization service
that you want to use, and I'll look into it. In many cases,
it's a simple matter of submitting the final invoice amounts
and other limited information via hidden variables, or
the Environment QUERY_STRING variables. MOF simply submits
some of its output to the appropriate service, and the
service takes over from there.
Some perl knowledgeable
folks have linked Merchant OrderForm's output to an authorization
service. If you are doing this, then I would be interested
in collaborating with you on this, and can offer you a
FREE lifetime membership for the Merchant OrderForm scripts
in exchange for documenting your work. Or if you are working
on doing it yourself, then I would be interested in assisting
so that we could get it working smoothly.
Who cares ?
Well, Big Bill
probably cares, and I don't mean Mr. Clinton.
I know, Big
Bill doesn't even know about Merchant OrderForm, but he
knows about MS Front Page 9x, and might care if you use
his company's software.
Big Bill's help
system for MS FrontPage 9x probably doesn't explain that
CGI scripts can be installed from HUNDREDS of programs
all the way from FTP programs to HTML editors. Now, just
exactly how you might do that with MS FrontPage 9x, or
even if it will do that, I must confess, I don't have
a clue, mainly because MS FrontPage 9x is one of the FEW
pieces of Microsoft software that hasn't found its way
onto my computer, or into my pocketbook. I've never used
it.
The important
questions are do you know how to -OR- can MS FrontPage
9x:
- Edit an HTML
file and transfer it to your server ?
- Edit a plain
ASCII text file ?
- FTP the text
files to your server and set permissions ?
It doesn't matter what software you use to do these three things, as long
as they get done. I use a freeware ASCII text editor to
write and edit HTML, as well as the perl code in the scripts.
Then I use a freeware FTP program (File Transfer Protocol)
to transfer all the files from my computer to the server
where my Web Site is located.
My guess is
that MS FrontPage 9x will do all of those three things,
you'll just have to learn how to work it. Your Web pages
or any CGI scripts don't actually integrate with MS FrontPage
or any other Web publishing software. Web publishing software
is just an agent to make and transfer HTML files to your
sever, or to FTP other files to your server like JPG,
GIF, or even CGI files.
Web Sites and
CGI programs actually LIVE on your ISP server. Once you
have constructed and transferred the files, then your
Web Publishing software has nothing to do with how the
HTML or CGI files work on the internet.
These questions
are more relevant than the MS FrontPage 9x compatibility
one:
- Is Merchant
OrderForm compatible with Perl 4, NO.
- Is Merchant
OrderForm compatible with Perl 5, YES
- Is Merchant
OrderForm compatible with NT, YES
- Is Merchant
OrderForm compatible with Unix, Linux, YES.
- Does my ISP
even allow the use of CGI on my Web Site ?
- Do I need
Telnet or Unix shell access to install the scripts,
NO.
This has been an educational moment sponsored
by the Merchant OrderForm staff J
When the three
processing files and one configuration file are installed
correctly, you will be able to initiate a direct call
from your Web browser to the http address where each script
is located. You can initiate each script stand alone,
by calling it up with your browser as in the example at
my site.
A direct browser
call to the first processing file:
http://www.io.com/~rga/cgi-bin/orderform14.cgi
Although, a
direct call to the first file like this gives you the
incomplete input message, you know the file is running,
else you would not get this message. The message is a
result of the script processing without any input.
You can make
a direct call to the other two processing files in the
same way to isolate which script is not running.
If you get an
"Error 500 Internal Server Error" then the script
is not installed correctly, or it could be contaminated.
Contamination could occur if not transferred correctly,
not stored in Unix format for Unix type servers, etc.
If you have
access to the perl interpretor then run a perl -c ( for
code check ) on the files.
>
perl -c filename.cgi
This runs a check
on the code and will tell you if there are code problems,
things like containers left out, syntax problems, perhaps
from editing. The package you downloaded is fine on my
server. It's been downloaded by hundreds of folks. You
may need to download it again if you get some code errors.
If you are not
accessing perl 5 on your server, you will get an error
checking the code on these scripts. Perl 4 will give you
an error with the <sprintf> function.
>
perl -v
This will give
you the version your are running.
If you get "Error
500 Internal Server Errors" keep reviewing the "CGI
Installation Notes" until you get it right. You missed
some subtle installation necessity.
Of course "File
Not Found" errors mean you don't have all the files
linked correctly. But, running each script stand alone,
for testing, will eliminate "File Not Found" errors.
If one of the
scripts returns a "Document Contains No Data" error
then the script is running, meaning it has all the correct
permissions, pathways, and is being processed by the perl
interpreter, yet the perl interpreter has found a syntax
error in the script. This invariably happens as someone
goes to modify the script in some way, and misses the
very strict syntax rules for balancing containers, quotation
marks, not using the escape character for perl's designated
characters, etc. Again, if you run a perl code check it
will tell you where the error in the syntax is.
>perl
-c filename.cgi
This is an internal
message embedded in the last processing script. The final
script sends it if it can't find the DAT files or the
RDB files.
- Make sure
the name is set correctly in configurations
- Make sure
you have full write permission on both DAT files, and
all three RDB files
- Make sure
you are using an "absolute" pathway correctly, if used
or needed.
- Don't ever
use a URL address like HTTP or HTTPS for these file
locations
The easiest way to make the scripts work is
to follow the Quick Start
instructions
Name - Value pairs used in the OrderForm input
Page
This is a list
of the names that are already being used in the script
processing or in the HTML OrderForm input Page NAME -
VALUE pairs. Do not uses these same names if you
make new fields in your OrderForm input Page or it will
cause some conflict in the scripts processing information.
- approvetype
- approvename
- approvebank
- noapprove
- redirect
- unit_tax
- sales_tax
- reversetax
- show_before
- show_after
- sub_after
- show_check
- sendcheck
- includetax
- includecountry
- shiptype
- discount
- show_discount
- sub_discount
- handling
- show_handling
- shipping
- show_shipping
- method
- grand_total
- checkname
- checkbank
- checknumber
- checkroute
- checkaccount
- cardtype
- cardnumber
- cardyear
- cardmonth
- cardholder
- realname
- address
- city
- zip
- state
- country
- custname
- custaddress
- custcity
- custzip
- custstate
- custcountry
- mailname
- phone
- fax
- comments
Acronyms for using with State tax matching
These are the
NAME - VALUE pairs that are listed in the drop down box
for identifying the shipping destination state. If you
are going to enable the Tax these states option,
then you need to use the two letter acronyms below to
identify which state(s) will be matched for tax to be
included, and which states will be matched for before
- after exceptions. You can build your own drop down box
if you want, but the rule is:
- Whatever
is in the State Matching arrays must also be in your
drop down box
In the Tax Variables and Configurations section of the configuration
file you will build these two arrays from the acronyms in
your drop down box as defined below.
- Exmaple arrays
for Tax Variables:
- %taxrates
= ('AL',0.045,'AZ',0.0333,'CO',0.03,'TX',0.0625);
- @exceptions
= ('CA','CO','CT');
- <select
name="state">
- <option
value=NA>Not Applicable
- <option
value=AL>Alabama
- <option
value=AK>Alaska
- <option
value=AZ>Arizona
- <option
value=AR>Arkansas
- <option
value=CA>California
- <option
value=CO>Colorado
- <option
value=CT>Connecticut
- <option
value=DE>Delaware
- <option
value=DC>District of Columbia
- <option
value=FL>Florida
- <option
value=GA>Georgia
- <option
value=HI>Hawaii
- <option
value=ID>Idaho
- <option
value=IL>Illinois
- <option
value=IN>Indiana
- <option
value=IA>Iowa
- <option
value=KS>Kansas
- <option
value=KY>Kentucky
- <option
value=LA>Louisiana
- <option
value=ME>Maine
- <option
value=MD>Maryland
- <option
value=MA>Massachusetts
- <option
value=MI>Michigan
- <option
value=MN>Minnesota
- <option
value=MS>Mississippi
- <option
value=MO>Missouri
- <option
value=MT>Montana
- <option
value=NE>Nebraska
- <option
value=NV>Nevada
- <option
value=NH>New Hampshire
- <option
value=NJ>New Jersey
- <option
value=NM>New Mexico
- <option
value=NY>New York
- <option
value=NC>North Carolina
- <option
value=ND>North Dakota
- <option
value=OH>Ohio
- <option
value=OK>Oklahoma
- <option
value=OR>Oregon
- <option
value=PA>Pennsylvania
- <option
value=RI>Rhode Island
- <option
value=SC>South Carolina
- <option
value=SD>South Dakota
- <option
value=TN>Tennessee
- <option
value=TX>Texas
- <option
value=UT>Utah
- <option
value=VT>Vermont
- <option
value=VA>Virginia
- <option
value=WA>Washington
- <option
value=WV>West Virginia
- <option
value=WI>Wisconsin
- <option
value=WY>Wyoming
- <option
value=AB>Alberta
- <option
value=BC>British Columbia
- <option
value=MB>Manitoba
- <option
value=NB>New Brunswick
- <option
value=NF>Newfoundland
- <option
value=NT>NWT
- <option
value=NS>Nova Scotia
- <option
value=ON>Ontario
- <option
value=PE>P.E.I.
- <option
value=PQ>Quebec
- <option
value=SK>Saskatchewan
- <option
value=YT>Yukon
Names used for Country Drop Down Box
These are the
country values used in the drop down box for shipping
country. If you enable the $use_country feature, to automatically change
the shipping rate for foreign shipping destinations, then
you need to use the exact country as defined in the drop
down box for the $match_country setting to identify what the
domestic country is.
- <option>Albania
- <option>Algeria
- <option>American
Samoa
- <option>Andorra
- <option>Angola
- <option>Anguilla
- <option>Antigua
& Barbuda
- <option>Argentina
- <option>Aruba
- <option>Australia
- <option>Austria
- <option>Azores
- <option>Bahamas
- <option>Bahrain
- <option>Bangladesh
- <option>Barbados
- <option>Belarus
- <option>Belgium
- <option>Belize
- <option>Benin
- <option>Bermuda
- <option>Bolivia
- <option>Bonaire
- <option>Botswana
- <option>Brazil
- <option>British
Virgin Islands
- <option>Brunei
- <option>Bulgaria
- <option>Burkina
Faso
- <option>Burundi
- <option>Cambodia
- <option>Cameroon
- <option>Canary
Islands
- <option>Canada
- <option>Cape
Verde
- <option>Cayman
Islands
- <option>Central
African Republic
- <option>Chad
- <option>Channel
Islands
- <option>Chile
- <option>Colombia
- <option>Congo
- <option>Cook
Islands
- <option>Costa
Rica
- <option>Croatia
- <option>Cuba
- <option>Curacao
- <option>Cyprus
- <option>Czech
Republic
- <option>Denmark
- <option>Djibouti
- <option>Dominica
- <option>Dominican
Republic
- <option>Ecuador
- <option>Egypt
- <option>El
Salvador
- <option>England
- <option>Equatorial
Guinea
- <option>Eritrea
- <option>Estonia
- <option>Ethiopia
- <option>Faeroe
Islands
- <option>Federated
States of Micronesia
- <option>Fiji
- <option>Finland
- <option>France
- <option>French
Guiana
- <option>French
Polynesia
- <option>Gabon
- <option>Gambia
- <option>Georgia
- <option>Germany
- <option>Ghana
- <option>Gibraltar
- <option>Greece
- <option>Greenland
- <option>Grenada
- <option>Guadeloupe
- <option>Guam
- <option>Guatemala
- <option>Guinea
- <option>Guinea-Bissau
- <option>Guyana
- <option>Haiti
- <option>Holland
- <option>Honduras
- <option>Hong
Kong
- <option>Hungary
- <option>Iceland
- <option>India
- <option>Indonesia
- <option>Israel
- <option>Italy
- <option>Ivory
Coast
- <option>Jamaica
- <option>Japan
- <option>Jordan
- <option>Kazakhstan
- <option>Kenya
- <option>Kiribati
- <option>Kosrae
- <option>Kuwait
- <option>Kyrgyzstan
- <option>Laos
- <option>Latvia
- <option>Lebanon
- <option>Lesotho
- <option>Liberia
- <option>Liechtenstein
- <option>Lithuania
- <option>Luxembourg
- <option>Macau
- <option>Macedonia
- <option>Madagascar
- <option>Madeira
- <option>Malawi
- <option>Malaysia
- <option>Maldives
- <option>Mali
- <option>Malta
- <option>Marshall
Islands
- <option>Martinique
- <option>Mauritania
- <option>Mauritius
- <option>Mexico
- <option>Moldova
- <option>Monaco
- <option>Montserrat
- <option>Morocco
- <option>Mozambique
- <option>Myanmar
- <option>Namibia
- <option>Nepal
- <option>Netherlands
- <option>Netherlands
Antilles
- <option>New
Caledonia
- <option>New
Zealand
- <option>Nicaragua
- <option>Niger
- <option>Nigeria
- <option>Norfolk
Island
- <option>Northern
Ireland
- <option>Northern
Mariana Islands
- <option>Norway
- <option>Oman
- <option>Pakistan
- <option>Palau
- <option>Panama
- <option>Papua
New Guinea
- <option>Paraguay
- <option>Peoples
Republic of China
- <option>Peru
- <option>Philippines
- <option>Poland
- <option>Ponape
- <option>Portugal
- <option>Qatar
- <option>Republic
of Ireland
- <option>Republic
of Yemen
- <option>Reunion
- <option>Romania
- <option>Rota
- <option>Russia
- <option>Rwanda
- <option>Saba
- <option>Saipan
- <option>Saudi
Arabia
- <option>Scotland
- <option>Senegal
- <option>Seychelles
- <option>Sierra
Leone
- <option>Singapore
- <option>Slovakia
- <option>Slovenia
- <option>Solomon
Islands
- <option>South
Africa
- <option>South
Korea
- <option>Spain
- <option>Sri
Lanka
- <option>St.
Barthelemy
- <option>St.
Christopher
- <option>St.
Croix
- <option>St.
Eustatius
- <option>St.
John
- <option>St.
Kitts & Nevis
- <option>St.
Lucia
- <option>St.
Maarten
- <option>St.
Martin
- <option>St.
Thomas
- <option>St.
Vincent and the Grenadines
- <option>Sudan
- <option>Suriname
- <option>Swaziland
- <option>Sweden
- <option>Switzerland
- <option>Syria
- <option>Tahiti
- <option>Taiwan
- <option>Tajikistan
- <option>Tanzania
- <option>Thailand
- <option>Tinian
- <option>Togo
- <option>Tonga
- <option>Tortola
- <option>Trinidad
&Tobago
- <option>Truk
- <option>Tunisia
- <option>Turkey
- <option>Turks
& Caicos Islands
- <option>Tuvalu
- <option>Uganda
- <option>Ukraine
- <option>Union
Island
- <option>United
Arab Emirates
- <option>United
Kingdom
- <option>Uruguay
- <option
selected>USA
- <option>US
Virgin Islands
- <option>Uzbekistan
- <option>Vanuatu
- <option>Venezuela
- <option>Vietnam
- <option>Virgin
Gorda
- <option>Wake
Island
- <option>Wales
- <option>Wallis
& Futuna Islands
- <option>Western
Samoa
- <option>Yap
- <option>Zaire
- <option>Zambia
- <option>Zimbabwe
Structure of the related RDB files
This is the
order of the fields that get printed to the main RDB file
ordermain.rdb. If there is no data entered for
a particular field, then a null is stored to that place,
with the delimiter intact. There are 37 Fields printed
in the ordermain.rdb file in the following order.
If you import this file to a PC Database, then you'll
want to set up this sort of structure to import directly
into. All formatting is stripped from the dollar numbers,
so the computations are stored in this file as non-formatted
2 decimal numbers
- Invoice
Number (related field)
- Unique
ID Number (related field)
- Date ( MM/DD/YY
)
- Time ( HH/MM/SS
)
- Payment Type
(check, card type)
- Account Name
- Bank Name
- Check Number
- Bank Routing
Number
- Account Number
- Card Name
- Card Number
- Expiration
Date ( MM/YY )
- Number of
Products for this Invoice
- Total Amount
of Products
- Discount
- Sub Total
( After Discount )
- Sales Tax
- Handling
Charge
- Shipping
Charge
- Total Invoice
Amount (sub total + sales tax + handling + shipping
)
- Shipping
Method ( standard, express, foreign standard, foreign
express )
- Ship to Name
- Ship to Address
- Ship to City
- Ship to State
- Ship to Zip
- Ship to Country
- Customer
Name
- Customer
Address
- Customer
City
- Customer
State
- Customer
Zip
- Customer
Country
- Email Address
- Fax Number
- Phone Number
This is the order
of the fields that get printed to the RDB file orderorders.rdb.
If there is no data entered for a particular field,
then a null is stored to that place, with the delimiter
intact. There are 7 Fields printed in the orderorders.rdb
file in the following order. If you import this file to
a PC Database, then you'll want to set up this sort of structure
to import directly into. All formatting is stripped from
the dollar numbers, so the computations are stored in this
file as non-formatted 2 decimal numbers
This file is
set up to provide "relational database" design, so it
will print as many records (lines) as products ordered.
You can then relate either one of the first two fields
to the main RDB file ordermain.rdb.
- Invoice
Number (related field)
- Unique
ID Number (related field)
- Quantity
of this Product ordered
- Item Name
- Item Description
- Item Price
- Item ShipCode
This is the order
of the fields that get printed to the RDB file ordercustom.rdb.
This file is only printed if $use_fields is turned
on.
This file is
set up to provide "relational database" design. The ordercustom.rdb
file prints only one record per invoice related to the
main invoice file ordermain.rdb. It is related
by either one of the first two fields. It will print at
least the first two fields:
- Invoice
Number (related field)
- Unique
ID Number (related field)
And then it will print as many fields as you
have set up in your custom fields configuration. It will
print null fields if you have fields set up but no data
is entered into a particular field. The delimiters will
print to hold the null spaces.
Okay, as mentioned
at the opening of this file, and at the top of each of
the scripts - By opening and configuring these scripts
for your server and application you thereby assume any
and all responsibility for the use and outcomes of this
program. There are absolutely no warrantees or guarantees
that come with these scripts. When you download the scripts
you assume all responsibility for anything resulting from
their use.
