The program starts and presents a main "ribbon" with menus and speedbuttons. The user manually interacts with the program to build, organize, and transmit transactions.

The program starts and automatically conditions {DetailFilename} using {TransactionSpecifier}, {Argument1}, {Argument2}, etc. (if present). To skip an argument that is not required, use a single underscore character (_).

{DetailFilename} must be the absolute path and filename of the file to condition and send.

/HOLDERID:{HolderID} is optional, and specifies a holder ID to use for this transaction/connection which is different than the primary one in System Parameters. Its presence causes IRIS to switch personalities. This is useful for merchants who have multiple accounts, or warehouses which send transactions for two or more separate warehouse IDs. Example: /HOLDERID:M123456

If the /QUEUE parameter is specified, the transaction(s) will be added to the "Pending Transactions" list, but communications will not be initiated. This is used when you want to accumulate transactions throughout the day, and then send them to the provider system all at once. If /QUEUE is not specified, communication with the provider system is initiated.

The /JUSTRECV parameter is used to make IRIS call the provider system and just receive mail (detail confirmations) without sending any transactions.

If the /NOMAIL parameter is specified, the holder's mailbox will not be checked (for detail confirmations) while connected. This basically turns the process into a "send-only" session. Normally (without /NOMAIL specified), IRIS will check for mail and receive any that is waiting.

/ESI:{ESIFilename} is only used for shipping order transactions (shipping orders, early shipping orders, sample orders, and block shipping orders), and is optional. ESI stands for Extended Shipping Instructions. {ESIFilename} is the absolute path and filename of a text file containing free-form instructions. The file can also have formatted instructions that conform to the "SO Instructions" specification (DI records) published by EWR, Inc. for shipping order transactions.

Example:   IRIS   XFR   c:\myfiles\recap.txt   M123456

Same as command-line mode, but {ResponseFilename} is assumed to be the absolute path and filename of a response file. The response file is a text file of IRIS parameter sets (as described above in the command-line mode), one per line, each line separated by carriage return and line feed.

Dependent transactions: since a response file can contain multiple transactions, any given transaction can be marked as "dependent" upon its preceding transaction. This will cause IRIS to wait for positive acknowledgement for the preceding transaction before sending the dependent transaction. To do this, simply add the /DEPENDENT flag to the end of the transaction line.

If the /HOLDERID:{HolderID} parameter is specified on the first line of the response file, then it is treated as if it appeared on the command line.

Example:   IRIS   @c:\myfiles\autoewr.rsp

where autoewr.rsp contains:

LDP   popthese.txt
XFR   recap1.txt   M123456   9464   /DEPENDENT
XFR   poolbales.txt   Z998877   BP1

{TransmissionFilename} is the absolute path and filename of a fully-conditioned file. The program starts and communication with the provider system is initiated to send {TransmissionFilename}.

Example:   IRIS   %c:\myfiles\manytran.txt

Every transaction that is fed to IRIS is described by a three-letter Transaction Specifier. Most transactions also require 1 or more arguments, and a detail file of bale records. This document explains the Transaction Specifiers and arguments. Detail file specifications can be found on the EWR, Inc. website.

Transaction Specifiers defined (click one to see its arguments):

Definitions of the transaction arguments (an argument that is not required can be skipped by supplying a single underscore character (_) in its place)