Make is a powerful data generation tool that allows you to create checks and ultimately x9 files from scratch based on your specific testing requirements. You can easily create x9 test files from your specific use cases without having to encode and capture checks. The x9 files created by Make will have type 25/31 records where the MICR line data will match their corresponding tiff images. When using Make, you define use cases which represent each check that will be created. Make will generate a TIFF image for each use case where the use case data (amount, check number, ABA, account number, payee, memo line, etc) is used to dynamically draw the corresponding image. This means that your application systems can successfully perform code line match of the image to the x9 MICR data. The courtesy and legal amounts that are present on the check will also match the x9 records. All of this can be accomplished without having to encode and capture items.
X9 file creation within X9Assist is typically a two step process, where the output from Make is then used as input to Generate. Make and Generate provide complimentary functions:
- Make is used to create checks.
- Generate is used to build images for those checks and then wrap them with all of the required record types and structure needed to create a valid x9 file.
You have complete control over the check format that is used for this process, which includes the check artwork, fonts, and text locations. You can also specify print information including payee name, memo line, and up to five lines that are shown in the upper left hand corner of each check image. This information is taken from each use case and can include such things as your use case number, the department or user that submitted the use case, or your expected testing results. Since this information is inserted into the image, it becomes a logical component of the generated check and will be available to all downstream applications that process the resulting x9 file.
Input to Make can be as simple as creating an Excel workbook containing your individual use cases. Use of Excel as your use case creation tool provides several advantages:
- It is a common tool that everyone understands and supports.
- You can utilize Excel formulas to simplify the definition and support of your use cases. For example, you can use a formula to assign your item sequence number based on the specific business function. You can then use another formula to format the item sequence number into the memo line on your individually generated checks.
- There are many other tools that easily integrate with Excel.
You can build a use case library of the various use case files that you create over time. Each of your use case files are then utilized based on your business requirements to generate x9 test files, as input to your x9 enabled applications. The use case files can also be utilized to actually print check images, which you can then use as input to image enabled capture applications, remote capture, or branch capture applications.
Make operates with two input components that you must understand and select:
- A use case file can be defined with your specific MICR use (test) cases. Each record (input row) of the use case file represents the data for a check. You can build your use case files with our Use Case Creator tool, or you can build them from the actual test data. A use case file must be created in Excel format (XLS or CSV). You can also use the output files created by export as a use case file, where you would export either the type 25 or type 31 records from one of your existing x9 files. Note that Make typically accepts the MICR OnUs field in its component parts (field4, account, serial, and transaction code). But it also allows you to specify a complete MICR OnUs field as well.
- A reformatter defines the rules on how to transform your use case file into the actual data that is needed by Generate.
For each required check field that is manipulated by Make, you must specify one of the following:
- The use case file input column where this data will be taken. For example, if this is the ABA field and you have specified that in column one, then you will indicate that here. Note that column numbering is relative to one, so the first column is one (and not zero).
- The rules to be used to assign the data if it is not present in your use case file and it is instead to be statically or sequentially assigned. For example, if you use case file does not contain the item sequence number, you can specify a starting number and increment which will be used to create item sequence numbers and assign them to checks as they are created. For some x9 fields on the Make panel, there is an option to generate all possible values, which means that Make will use x9 rules to sequentially assign all of the defined values for this field.
Use Case Files
There are several sample use case files included in the X9Assist distribution. You should review these files since they represent formats that you can use as a basis for developing your own use case files. Use case files are stored in /x9_assist/lists/useCases.
deposit.xls is our most powerful example since is includes the ability to:
- Mark rows as comments
- Insert a credit to offset your debits (note you can have multiple credits if needed)
Define all fields on the MICR line
- Define the Payee and Memo text strings that will be used when your images are drawn
- Define the specific check format that you want used (if you leave this column blank, then the check format will be sequentially assigned by Generate)
Specific requirements regarding the creation of your use case files:
- You can provide a fully defined MICR OnUs field or the individual field components. If you provide the fully defined MICR OnUs, that value is taken first and will override any values that you provide for the individual fields.
- If you provide both Aux OnUs and a check serial number, then the Aux OnUs field is taken first and your serial number will not be used.
- If you need an eight digit ABA value encoded, then you need to provide that value with the dash in the ABA column. For example you must provide the value of 1234-5678. Providing the actual dash in the ABA field in the indicator that you do not have an ABA check digit.
Using Excel To Maintain your Use Cases
Why reinvent the wheel? MS-Excel is very commonly used within the industry. X9Assist takes advantages of your Excel knowledge by allow you to create, edit, and save your use case files directly as an Excel workbook. Make will read these workbooks directly without the need to convert them to some other format such as CSV. X9Assist supports both the XLS (Excel 97-2003) and XLSX ( Excel 2007) workbook formats.
You can optionally format your numeric fields using standard Excel patterns. You can also define amounts as decimals.
If you provide a numeric field via a formula, it is important that you format that column as containing numeric data (and not general or text data), and then set the number of decimal places appropriately (eg, set this as zero places to the right of the decimal point). This is needed since Excel internally defines all numeric fields in floating point notation. Failure to do this can cause a field with a value of 1234 to instead be read as 12339999999998 (since the value internally stored by Excel might be 1233.9999999998).
Columns identifiers can be entered either as numeric values (eg, 1, 2, 3, 4…) or as Excel identifiers (eg, A, B, C, D ….). When you enter column identifiers in Excel format, they will be converted and stored as their corresponding numerical value.
Most importantly, you can also use formulas within your Excel worksheets. Make will retrieve the resulting value that is assigned by your formulas. For example, you can use a formula to inspect your ABA and transaction code to assign the check format that you want to use for every item. Or you can define a formula to assign the memo field with your use case number.
Items will begin in a new bundle in one of several ways:
- The item count per bundle is exceeded (as defined in your generator).
- The item is a credit, and your generator indicates that credits should begin in a new bundle.
- You populate values in Bundle Cycle Number, Bundle User Field, or both of these columns. A new bundle is started automatically when these columns are populated and the value changes.
- You forcibly indicate that an item should begin in a new bundle. You can do this using the item type indicator column, where you instead insert the keyword “Bundle” on a row by itself (since this row is a separator and will not contain an actual item). Doing so will force the subsequent item to begin in a new bundle.
- You insert a “Y” in the new bundle column as identified by your reformatter.
There are two ways for credits to be created by Make:
- Define your offsetting credit within your generator.
- Include credits in your Make input. When you do this, you have the option of providing the credit amount, or setting the amount to zero (where it will be automatically assigned based on the debits that follow). You can have multiple credits within your Make input. You can also have multiple credit transactions (where multiple credits are offset by multiple debits); however, in if you have this more complex transaction, then you will have to explicitly assign the credit amounts.
For credits to be inserted into your generated file, you must ensure that credits are enabled in your generator. Note that you also have the option for credit image to be generated.
Use of Comments
Comments are identified by placing an asterisk (*) in either the comment column or in the item type column, as identified by your reformatter. Any header lines within your Excel workbook should be explicitly identified as comment lines, since they do not represent actual items. You can use the comment facility for various purposes. For example, a given item can be disabled (which will not be generated) by flagging it as a comment. Or, you can place comment lines within your use case file to describe the purpose of the test, information about specific test cases, or the originator of various bundles.
Process Control Field
Most banks use the process control field for two separate purposes. The first is to specify an optional transaction code that for their internal processing. The second is to provide the check serial number on consumer (retail) checks.
- The transaction code is typically one or two digits.
- The check serial number is typically four digits.
Your reformatter can define creation rules for both your check serial number and the transaction code. Note that both of these are optional, so either one or both may be present. The process control field can then be constructed as a combination of your check serial number and your transaction code. An option is provided to allow the transaction code to be appended to the left or to the right of your check serial number.
Make allows you to construct the OnUs field by defining several fields which will then be combined (optional field 4, account number, serial, and transaction code). As an alternative, Make allows you to provide the OnUs field in its entirety, formatted exactly as you want it. This does require that you provide the separator symbols (“/”) between the various logical elements within OnUs.
Make normally constructs the MICR line from the individual use case fields (AuxOnUs, EPC, Routing, OnUs, and Amount) that are then formatted per standard MICR line construction rules. There may be times when you want to assume control of MICR line formatting. This type of override processing is typically used in support of negative testing where you need to explicitly format the MICR line. Several examples are:
- Your application requires non-standard MICR lines.
- You want to purposefully create images (and perhaps printed items) with invalid MICR lines for negative use case testing.
In support of this, Make allows you to format your own MICR line which can be provided via your use case file. User input is typically limited to valid E13B characters. Make does not block the presence of other characters which may be useful for specific negative testing. The following E13B characters would typically be present in your use case file:
- 0 through 9 (the numeric MICR line digits)
- A (transit symbol)
- B (amount symbol)
- C (OnUs symbol)
- D (dash symbol)
- b (a single blank)
- * (digit error)
An example of a user provided MICR line would be as follows:
CMC-7 MICR Line Encoding
Make/Generate has the ability to create test items using CMC-7 item level encoding, which is based on the CMC-7 encoding standards as documented by ISO 1004. The CMC-7 font is widely used for checks and drafts throughout Europe, South America, and various other countries around the world. The CMC-7 character set consists of the ten numbers (0-9), five special symbols (S1 through S5), and twenty six letters.
Each country has their own unique layout for their encoded CMC-7 MICR line which incorporate their unique data elements and encoding. These layouts vary due to the internal identification and routing requirements as defined by each respective country. Because of these variations, it is important that you understand the CMC-7 requirements for the countries to be generated.
Make/Generate accommodate these differences through two facilities:
- Make allows you to take complete control of the MICR line format at the item level. For CMC-7, this includes use of the S1 through S5 special symbols (internally defined as A through E) within user provided MICR line data.
- Generate allows you to select the MICR font to be used for MICR font to be used for encoding. This font selection is made on the “image” tab.
Examples of CMC7 formatted MICR data lines which would be provided as input to Make and then used by Generate to format items are as follows (note the use of A-E and b for blanks):
Once you define your reformatter rules, you can use the “View” button to preview the items that will be created by Make using your use case file and reformatter definition. This optional step allows you to check your work before you actually generate a file. The test results are displayed within the Text Editor in CSV format. You should always test your new reformatter rules to see if they are creating checks in the manner that you expect, prior to actually running generate. Test will display the Make created fields as they have been manufactured per your defined parameters. This field list represents the internal interface from Make to Generate.
Test allows you to see your Make results without actually running generate. This allows you to view your field mapping to ensure that you are creating your fields as expected. You can make adjustments to your mapping and repeat this process until you get the output you expect.
Test allows you to save your Make results to your own external file. This would allow you to take your Make results, make additional modifications, and then bring the modified file directly into Generate. You can do this if you have requirements that cannot be directly supported by the Make process.
When you select generate, checks will be created and written to an intermediate file which will be sent to the standard X9Assist Generate function. You will be presented with the Generate panel where you specify generate parameters used to create the new x9 file. Generate similarly allows configurations to be defined and saved, which makes that process configurable and reusable similar to Make.