• 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

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:

• Working with settings in the configuration file

You can also find answers for other questions under the heading:

• A collected FAQ about the Merchant Order Form v1.4

• What is Merchant OrderForm?

• Quick Start Instructions
  • How to get the program running in test mode

• Setting up your OrderForm input page
  • Ways to customize your OrderForm input page
  • What are those other files in the package?
  • Adding products to the HTML OrderForm input Page.
  • How to think about using the ShipCodes
    • Using the Global Settings
    • Using the Individual Item Settings
    • Writing your own code for shipping

• Working with settings in the configuration file
  • Basics about editing the configuration file
  • Tax Variables and Configs
  • Discount Variables and Configs
  • Handling Variables and Configs
  • Shipping Configurations - Introduction
  • Shipping Configurations - Methods Settings
  • Shipping Configurations - Global Settings
  • Shipping Configurations - Individual Item Code Settings
    • An overview of how it works
    • How to set up the array elements
    • Some more examples
    • Some things that go without saying
  • Installing Custom fields
  • Other Switch functions
  • Return Link Settings
  • Merchant Information
  • File Locations
    • These are the files needed by the scripts
    • A quick note about absolute addressing
    • Setting file locations
    • Setting the delimiter used with the RDB log files
  • Merchant and Customer Mail Options
    • Where you send the mail to
    • Now, you're ready to send some mail

• An important note about security.
  • Use SSL on a virtual domain when available
  • Keep the mail off the internet or use PGP

• A checklist for installing CGI on Unix type servers.

• A collected FAQ about the Merchant Order Form v1.4
  • Can I do this with the shipping configurations ?
  • Can MOF accept input from multiple OrderForms ?
  • Can MOF submit totals to my Online Authorization Service ?
  • Is MOF compatible with MS FrontPage 9x ?
  • Basic trouble shooting tips.
  • Error opening DAT files or RDB files.

• 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

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

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.
 
 

Quick Start Instructions

>>> GO TO TABLE OF CONTENTS

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

• 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.

• Next, you need to set correct file Permissions on the files you just sent to your server's CGI-BIN.

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.
 

• 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

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.

• http://www.io.com/~rga/cgi-bin/orderform14.cgi
• http://www.io.com/~rga/cgi-bin/ordercount14.cgi
• http://www.io.com/~rga/cgi-bin/orderfinal14.cgi

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">

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.

• ordersample14.html
• ordersample24.html

• 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.

• 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

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.
 

Adding products to the HTML OrderForm input Page.

>>> GO TO TABLE OF CONTENTS

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

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 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.
 

How to think about using the ShipCodes:

>>> GO TO TABLE OF CONTENTS

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.
 

Using the Global Settings

>>> GO TO TABLE OF CONTENTS

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

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"

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.
 

Writing your own code to process ShipCodes

>>> GO TO TABLE OF CONTENTS

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.
 
 

Working with settings in the configuration file

>>> GO TO TABLE OF CONTENTS

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:

• Tax variables and configurations
• Discount variables and configurations
  • Examples between Rates and Inrements
• Handling Charges variables and configurations
• Shipping Configurations Introduction
• Shipping Methods configurations
• Shipping configurations - Global Settings
  • Examples of Global Shipping Configurations
• Shipping configurations - Individual item code settings
  • An Overview of how it Works
  • How to set up the array elements
  • Exmaples of Item Code settings
• Enabling Custom fields
• Other switch functions
• Return Link Settings
• Merchant Information
• File locations
• Merchant and Customer mail settings

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:

• 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
  • Zero is Off
  • One is On

• 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

$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)

• 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.

• 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

• 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

$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

• 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')

• 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

• As a percentage of the total dollars spent
• Or as a set rate per N number of items purchased

Here is an example of an uneven discount schema, which cannot be produced by MOF settings, but can be produced by custom code:

• 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

$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

• 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>

• 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>

• 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

• 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

$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

• 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.

• 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.

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

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
 
 

Shipping Configurations - Introduction

>>> GO TO TABLE OF CONTENTS

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

• Sub Total After Discount

• 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.

• Determining which set of rates the computation rules will use

• Setting the computation rules

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

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

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.
 
 

5.  Shipping Configurations - Global Settings

>>> GO TO TABLE OF CONTENTS

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

This is an example of an uneven shipping schema:

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.

• 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.

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>

• 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

• 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

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.
 
 

6.  Shipping Configurations - Individual Item Code Settings

>>> GO TO TABLE OF CONTENTS

What can these settings do?

• Group products together by shipcode and
• Apply a set of different rates to each group

• 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:
 

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:
 

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.
 

Examples of Item Code Shipping settings

>>> GO TO TABLE OF CONTENTS

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
 

Some things that go without saying

>>> GO TO TABLE OF CONTENTS

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.
 
 

7.  Enabling Custom Fields

>>> GO TO TABLE OF CONTENTS

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.

$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.

• 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.

Other Information About Hobbies and Interests

• Type of Hobby: I like computing
• Area of Interest: I like watching good movies

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

• 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.

• <input type="text" name="hobby" size=30>
• <input type="text" name="interest" size=30>

@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

• 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.

• @customer_fields = ( 1,0 )

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

$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
  • $shipping
  • $show_shipping

• 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.

• 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.

• 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.

$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.

• 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.

• 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.

$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.

• 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

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

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.

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.

• 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/"

• 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.

$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 = "";

$site_address = "111 Merchant Ave.";
$site_city = "Austin";
$site_state = "Texas";
$site_zip = "77777";
$site_phone = "444.444.4444";
$site_fax = "555.555.4444";
 
 

11.  File Locations

>>> GO TO TABLE OF CONTENTS

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

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.
 

These are the files needed by the scripts:

>>> GO TO TABLE OF CONTENTS

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';

orderform14.cgi

• This file is started from your HTML OrderForm input Page. It must have complete read, execute permissions to run.

• 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.

• 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.

• 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.

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.

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.
 

Setting file locations

>>> GO TO TABLE OF CONTENTS

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";

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.

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.
 
 

12.  Merchant and Customer Mail Options

>>> GO TO TABLE OF CONTENTS

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

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.
 

Where do you send the mail to ?

>>> GO TO TABLE OF CONTENTS

Once your mail program location is identified, then you can send mail:

• To the Merchant
• To the Customer

$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.

$mailprog = '/var/qmail/bin/qmail-inject';

• If you are using "Qmail" then this might be a typical location for a server's "Qmail" program.

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.

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.

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.

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.
 

Keep the mail off the internet or use PGP

>>> GO TO TABLE OF CONTENTS

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 ..
 
 

A checklist for installing CGI on Unix type servers.

>>> GO TO TABLE OF CONTENTS

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.
  • #!/usr/local/bin/perl

• 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.

• 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

• 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:

• Can I do this with the shipping configurations ?
• Can MOF accept input from multiple OrderForms ?
• Can MOF submit totals to my Online Authorization Service ?
• Is MOF compatible with MS FrontPage 9x ?
• Basic trouble shooting tips.
• Error opening DAT files or RDB files.

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

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:

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.
 

Can MOF accept input from multiple OrderForms ?

>>> GO TO TABLE OF CONTENTS

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.
 

Is MOF compatible with MS FrontPage 9x ?

>>> GO TO TABLE OF CONTENTS

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 ?

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.

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.

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.

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

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
   

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

• 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

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

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 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 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)

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.