Applies to X9Vision?	Applies to X9Validator?	Applies to X9Assist?	\| \|	Applies to X9.37?	Applies to ACH?	Applies to CPA005?
No	No	Yes	\| \|	Yes	Yes	Yes

Our Make/Generate tools can be used to create test files from use case files that can be either Excel or CSV. Our reformatter process allows you to define the content of the use case files based on your requirements. The steps needed to manufacture test files typically consists of the following steps:

Define your item level test cases.
Use Excel to enter your items (debits and credits).
Create and populate addenda (endorsement) records to accompany your transactions.
Wrap the resulting transactions into bundles, a cash letter (for x9), and an overall file with the appropriate records, control totals, and file structure.
For x9, also create industry conforming TIFF images that match the generated items so CAR/LAR can be run against the resulting file.
Build the data file with field values and automatically calculate and populate trailer record totals.

X9Assist is your tool to address these data generation requirements. The following tools are used to perform each of the above tasks:

Use case definition tool	MS-Excel
Build MICR transactions from your use cases	Make
Create addenda records	Generate
Wrap transactions and into a valid x9 file	Generate
Create conforming TIFF images	Import
Build the final file structure per specifications	Import

Make has been designed to simplify the creation of your test files. When paired with Generate, you can easily create test files from simple input files which can either XLS, XLSX, or CSV. Make and Generate assume all of the tasks needed to format the data fields, construct the record types, and insert the needed headers and trailers with the appropriate control totals.

A Make run will always invoke our make, generate, and import processes. However, although these tools can all be used individually, Make has been designed in a manner that allows your to view this as a single tool which is executed in a single step, with the goal of reducing complexity and increasing your productivity. Make can satisfy the test document requirements for even the most complex testing needs based on the continuing enhancements that have been made.

For x9 files, Make/Generate can create output tiff images using either the E13B or CMC7 fonts to construct and draw the associated encoded MICR lines within the MICR band area.

Just to review:

Make is used to create items (debits and credits) from your use case definitions.
Generate is used to create various additional record types (addenda, image records, credit records, headers, and trailers) as needed to ultimately build a valid file structure.
Import (for X9) is used to build the final output file by forming each data record per the requested file specification, assigning field attributes (lengths, justification, padding, etc) and ultimately writing the output file as both fixed and variable length records. This final step is not used for ach, since the file format is much simpler in nature.

You can view Make as a single tool that performs all of these functions. It is also interesting that each of these tools can be used independently for their respective functions. In this manner, X9Assist is designed to provide the appropriate tool to meet your needs.

Make/Generate as a Single Step Process

Although Generate can be run as a stand alone process, it is more typically run within a fully integrated Make/Generate function where they are run together as a single step. The Make panel allows you to first load your reformatter (which defines your Make parameters) and your generator (which defines your Generate parameters). When you run Make, you will see the Generate tabs are appended to the bottom of the Make tabs (on the right). The combined list of tabs provides all functionality to run Make and Generate within a single step operation.

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.

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.

Using Excel Custom Number Formats

A number format is a special code to control how a value is displayed within Excel. Custom number formats can be used to control the display of numbers, dates, times, fractions, percentages, and other numeric values. Through the use of custom formats, you can do things like format dates to show month names only, format large numbers in millions or thousands, and display negative numbers in red.

You can optionally format your amount columns as numeric using 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). You can set the number of decimal places based on your formatting requirements (typically zero or two). If you use a format string against a numeric field, then Make will remove any commas, periods, or dollar signs that are present within the resulting string.

Generally, routing numbers are entered into your use case files as 9 digit numbers. However, there are times when it is desirable to explicitly format routings as either xxxx-xxxx (older US eight digit format) or xxxxx-xxx (Canadian format). X9Assist refers to these formats as 4×4 and 5×3, respectively. In these situations, it is recommended that these cells be formatted as text and not as numeric data with a custom formatting pattern. Using Excel text allows data to be entered on a WYSIWYG basis (what you see is what you get). By using this approach, you can define routing numbers in any desirable format as needed for negative use case testing (for example, 3×5 or 6×2). However, if there is a specific need to define routing numbers as numeric with a formatting pattern, then the following may be used:

Routing Format	Usage	Format 1	Format 2
4×4	US routing format	0000-0000	####-####
5×3	Canadian routing format	00000-000	#####-###

Other than the above stated exceptions, we do not recommend the use of custom number formats within your Excel use case definitions. Our alternative recommendation is that columns should be formatted as “Text” which means that the content will be treated as text even when a number is entered, and that the cell will be displayed and passed to Make exactly as it is entered. Using this best practice allows your fields to be processed on a WYSIWYG basis (what you see is what you get). Although Make supports the translation of numeric fields to strings through the use of Excel custom format strings, we do not recommend this only due to the complexities that are added to the process.

Using Excel Formulas

You can also use formulas within your Excel worksheets to calculate values and feed those into Make. For example, you can use a formula to add up a list of items and provide that total into Make (also note that a deposit amount can be provided as zero, and Make will automatically calculate the tote for you). Another example of using a formula would be to inspect your ABA and transaction code combination, 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. There are many potential uses formulas, allowing you to provide automation to your Make process.

Running Make

Make operates with several input components that must be selected:

A reformatter which defines the rules on how to transform your use case file into the actual data that is needed by Generate. A high level description of this process is presented in the help section on the left hand side of the Make panel.
A generator which defines the rules on how your items will be wrapped to ultimately create the desired output file. The selection of a generator within Make is optional. If you do not select a generator, then Make will interface to Generate, where you can subsequently define and invoke your generator. You will want to omit an generator the first several times that you use Make, to allow you to fully understand how Generate works and to build and save a generate configuration. Once you begin to get comfortable with the overall flow of the Make and Generate, you will be in a position to select one of your generators and then run Make as a single step (bypassing the Generate step from Make). You can only do this when you have defined and tested a generate configuration and fully understand the end to end Make/Generate process.
A use case file which contains your specific routing/account use cases (these are your test cases). Each record (input row) of the use case file represents the data used to create a single check. You can build your use case definitions with our Use Case Creator tool, or you can build them from your own use cases, based on the actual data that you want to utilize for a given test. A use case file must be created in Excel format (XLS or CSV). Excel XLS files must be saved as an Excel 97-2003 workbook.
You can also use the output files created by export as a use case file, where you would map the column definitions to those specific data elements.
For x9, 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, which is how the type 25 and 31 records are formatted.

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 fields on the Make panel, there is an option to generate all possible values, which means that Make will use the configuration rules to sequentially assign all of the defined values for this field.

Reformatters

Reformatters represent the power of the Make process since to provides the capability to easily translate your use cases into the format required by Generate. There are several reformatters that are included in the X9Assist distribution. You should review these reformatters since they represent strategies that can be used as a basis for developing your own use case reformatters.

Although you can write your own programs to create the input required by Generate, Make can be used to virtually eliminate the need for that, by performing these data translations for you.

The following reformatters are included in the X9Assist distribution:

Type	Reformatter Name	Folder	Description
x9	default937.Reformatter.xml	/ x9_assist / xml / makeItems /	This is a basic x9 reformatter which is designed to work with a simple use case file that contains four columns: AuxOnUs, Routing, Account, and Serial Number. This basic reformatter is provided as an example but most probably will not be used in real world applications.
x9	depositReformatter.xml	/ x9_assist / xml / makeItems /	This is a more complex x9 reformatter which is designed to work with the depositFile.xlsx use case file, which is also provided with the distribution. All users tend to manipulate the reformatter content to meet their specific requirements, which is one of the benefits of using Excel as the basis for these documents. Once you understand how this reformatter works in conjunction with the sample use case file, you can then modify these examples for your organization.
ACH	There are a large number of reformatters for the ACH transaction environment, where they are created by standard entry class and file type (transactions, returns, dishonored, contested). These various reformatters are stored into sub-folders by their respective file types.	/ x9_assist / xml / makeAch / See the table below for a complete list of the standard ACH reformatters.	Similar to x9, these reformatters can be used as the basis to create your specific reformatters, based on your specific requirements. Because of that, you should not modify our standard reformatters. If you mistakenly modify a standard system reformatter, you can just delete it and X9Assist will automatically recreate it during the next user session.
CPA005	defaultCp5.reformatter.xml	/ x9_assist / xml / makeCpa005 /	This reformatter is used to work with Canadian electronic CPA005 files.

Saving and Reusing Reformatters

You can create new reformatters and save them for future use, and can assign your own name to the reformatter based on the purpose. This will allow you to build a library of reformatters that can be repetitively used for explicit test generation purposes.

Generators

Make/Generate is an integrated process where the reformatter and the generator are both accessible during the make process. Make allows a generator to be loaded, modified, saved, and ultimately used to create the output file. This process is extremely integrated.

Use of Heading Lines

Excel workbooks often include heading lines that provide instructions on usage. These are present as help (or tips) as to how the columns within the workbook should be populated. These leading lines within the workbook can be tagged with an “H” in the comment column to indicate that they are headings and not items. Excel conditional formatting can be used within your reformatter definition to color code heading rows based on presence of the “H” value.

Use of Comments

Comment lines are identified by placing an asterisk (*) in either the comment column or in the item type column, as identified by your reformatter. 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. Excel conditional formatting can be used within your reformatter definition to color code comment rows based on presence of the “*” value.

New Batches / Bundles

Items can be started 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.
The item has a value of “B” in the “NewBundleOrCashLetter” column as identified by your reformatter.
You populate differing 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 values for the current bundle have changed.
You indicate that an item should begin in a new bundle using the item type indicator column, where you instead the keyword “Batch” (or “Bundle”) on a row by itself. When you do this, the row is treated as a separator line identifying the start of a new bundle, and will be otherwise ignored. The row will trigger the next item to begin in a new bundle.

New Cash Letters

Items can be started in a new cash letter in one of several ways:

The item has a value of “CL” in the “NewBundleOrCashLetter” column as identified by your reformatter.
You indicate that an item should begin in a new cash letter using the item type indicator column, where you insert the keyword “CashLetter” on a row by itself. When you do this, the row is treated as a separator line identifying the start of a new cash letter, and will be otherwise ignored. The row will trigger the next item to begin in a new cash letter.

Character Set

Make uses the ISO 8859_1 character set to internally represent strings that can be drawn within item images. Any character that is included in that system character set can be present in your use case files and will be drawn into images. ISO 8859-1 is commonly used throughout the Americas and Western Europe and specifically includes the French diacritical accents.

Use Case Files

Our general intention is that you should not modify our templates, but alternatively use them as the basis to either save or further develop your own spreadsheets subject to your specific requirements.

There are two X9 use case file examples. One is very basic (useCase100) while the second is a more “real world” example (depositFile.xlsx).
There are also several ACH use case examples, which represent all commonly used NACHA transaction formats. These templates can be used as provided, or can also serve as a basis for developing your own use case templates. Where appropriate, these use case files will create balanced files, by automatically inserting an offsetting item which will net the file to zero. These templates have separate tabs (worksheets) for various standard entry classes. The reason for this is that the columns within the templates vary based on the specific data requirements. Because of this, you cannot combine multiple standard entry classes into a single worksheet. If you need to create an ACH file with more than one standard entry class, then the files should be created separately and then merged.

Our standard use case templates (included in the X9Assist distribution) are as follows:

File Type	Use Case Name	Description
X9	useCase100.csv	A very simple use case file that is designed to work with default937.Reformatter.
X9	depositFile.xlsx	A more complex use case file that demonstrates some of the more advanced capabilities of Make. This example shows the power of using Excel and should be used as the basis for any use case files that you create.
ACH	ach_ACK.xlsm	Sample transactions for these entry classes.
ACH	ach_ARC_BOC_RCK.xlsm	Sample transactions for these entry classes.
ACH	ach_ADV.xlsm	Sample transactions for these entry classes.
ACH	ach_ATX.xlsm	Sample transactions for these entry classes.
ACH	ach_CCD_CIE_DNE_PPD_WEB.xlsm	Sample transactions for these entry classes.
ACH	ach_COR.xlsm	Sample transactions for these entry classes.
ACH	ach_CTX_ENR_TRX.xlsm	Sample transactions for these entry classes.
ACH	ach_IAT.xlsm	Sample transactions for these entry classes.
ACH	ach_MTE_POS.xlsm	Sample transactions for these entry classes.
ACH	ach_POP.xlsm	Sample transactions for these entry classes.
ACH	ach_SHR.xlsm	Sample transactions for these entry classes.
ACH	ach_TEL.xlsm	Sample transactions for these entry classes.
ACH	ach_TRC_XCK.xlsm	Sample transactions for these entry classes.
CPA005	cpa005.xlsx	Contains sample CPA005 transactions.

Creating Balanced ACH Files

ACH files can be either “balanced” or “unbalanced”. Balanced files contain an offsetting entry that automatically credits/debits the customer’s offset account for the debit and/or credit transactions that are present within the file. A debit file will contain an offsetting credit, while a credit file will contain an offsetting debit. From the bank’s perspective, a balanced file nets to zero, since the total amount of the transactions are offset by the balancing entry, which means that the net of debits and credits will be zero. Unbalanced files do not have this offsetting entry. Unbalanced files can be all credits, all debits or a mixture of debits and credits that probably do not balance against each other. When an unbalanced file is generated,, the receiving financial institution must make a manual entry to credit/debit the customer’s account for the activity. The bottom line is that transaction files must ultimately always net to a logical zero. The only question is where the balancing entry will be created. Typically, if your financial institution has required that you prefund ACH Activity, you will be required to submit unbalanced. Most financial institutions require balanced files since the files are self-posting, manual entry mistakes are eliminated.

Our use case files are created using Excel, which makes the creation of a balancing entry relatively easy since an Excel formula can be used to automatically calculate the offsetting transaction that is required. There are several important considerations for this process:

The balancing entry should typically be the last item within your transaction file.
The balancing entry can be located in its own batch, making it readily identifiable.
The balancing entry should have a description such as “offset” or “summary”.

Use Case File Tips

The following tips are helpful when creating your use case files:

The comment column must always be the first column (“A”) within your document.
Header lines (those at the top of your spreadsheet) can be identified with an “H” in the comment column. This is done by tradition as a unique way to tag those lines.
Comment lines (any row that is not considered to contain use case data) should have an asterisk (“*”) in the comment colulmn. For example, you can use comment lines to separate your data into logical groups or further identify the source or purpose of specific test cases.
A spreadsheet row that has absolutely no populated data will be discarded and will not create a resulting item.
Identify each individual transaction row as either a debit or credit (D=Debit, C=Credit). A row will default to a debit when no value is present.
Note that you can have credits defined throughout your Make file, and you can also have multiple credits offset by your debits when that is a requirement. You can complete control over the order of the individual items.
Items will automatically fill each batch/bundle unless overridden in one of several alternative manners.
Within Generate, you can indicate that each credit should begin in a new batch.
You can also insert a row within the use case file that has “batch” in the item type column, which will forcibly begin a new batch at that point within the generated file. In this scenario, the use case row is blank except for the inserted bundle identifier.
Define all needed item related fields and assign appropriate values.
For x9, define the Payee, Memo, and name/address text strings that will be inserted into virtual images as they are dynamically drawn.
For x9, 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).
Consider using customized Excel calculations to automatically assign values based on your specific requirements; for example, you could assign the transaction code automatically from the ABA column.

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.
Make has extensive support for the type 68 user record. Please refer to that topic for specific information on how to define and create your custom user records.
Make includes support for the fixed and variable formats of the type 27 and type 34 addendum records. Please refer to that topic for more information on creating those record types.

Process Control Field (For X9)

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.

OnUs Field (For X9)

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.

MICR Line (For X9)

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:

A057770930Ab20915353C7837bbbbbbB0000010000B

CMC-7 MICR Line Encoding (For X9)

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

C4440101bC123456789123Eb111122223333A

C4440102E0182Cb4014Eb111122223333Bb4227A

Credits (For X9)

An input file to Make/Generate typically has a single credit (which offsets the checks that are present), but in more complex testing scenarios you may have multiple credits present. There are two approaches that can be used to create credits within the Make process:

Include the credit(s) in your Make/Generate input. When using this approach, you have total control over the order of the credits relative to the debits, and you also have total control of the amount that this present on the credits themselves. Remember that credits are identified within Make use case input using the “ItemType” column, which must be populated with “C” to indicate that an individual item is a credit (and not a debit which is a “D”). To take absolute control over the credit amount, you can explicitly include the required amount within the credit item. In this situation, your provided credit amount will be used (it will not be calculated). You can alternatively set the credit amount to zero, which indicates that you want the amount to be auto-calculated by Make/Generate, based on the offsetting debits which are present. Use of auto-calculate is required if you are having Make/Generate insert the credit into your ICL file (since the credit does not otherwise appear). It is also helpful even when you include the credit in your use case file, when the checks may change from test to test and you always want the file to be in balance.

Your generator can indicate that an offsetting credit should be automatically created and inserted. When this is needed, indicators must be set on two separate Generator panels. First is on the Generate tab itself, where you must indicate that credit (type 61/62) records are to be created. Second is on the Credits tab, where you must indicate the attributes of the credit record to be manufactured and inserted. When using this approach, there will be a single credit which is inserted using the defined attributes to offset the debits which are present in your use case file. The inserted credit will be immediately after the bundle header (this sequence is typically described as credits first). The credit amount will be automatically calculated from the offsetting checks. This is typically defined as an ICL (image cash letter) which contains a single credit offset by the presents checks.

Generate also supports multiple credit scenarios. When this is needed, the credits must be present within your use case file. They cannot be automatically created and inserted by Make/Generate, since their exactly position would be unknown. In this situation you can have a series of transactions, each of which consists of a credit offset by its corresponding debits. Depending on your requirements, there can also be more complex transactions, where you have multiple credits offset by multiple debits. Obviously, in these complex scenarios, you use case input is responsible for both the credit amounts as well as their logical sequence.

Depending on your requirements, credits may or may not require images. If images are to be created, you must indicate this on the Generate tab using the “create credit images” check box.

Addenda (For X9)

Make/Generate supports the creation of both primary (BOFD or Bank of First Deposit) and secondary endorsements, which are attached to each generated use case item. It is important to remember that creation of endorsement records must be enabled on the Generate tab when using these facilities. No addendum records will be created if those corresponding check boxes have not been enabled.

The primary endorsements are record type 26 (for ICL) and record type 32 (for ICLR). The secondary endorsements are record type 28 (for ICL) and record type 35 (for ICLR). Record types 26/28 will be attached to the type 25 check detail record. Record types 32/35 will be attached to the type 31 return detail record.

The most typical use of Make/Generate is to manufacture specific test data that evolves around use case items. Within this underlying purpose, endorsements are created as necessary attachments since they will be required by those image enabled applications which process the generated files. These creation of these endorsements is associated with the need to create a logically complete file, and less about the specific content of the endorsements themselves. To that end, Make/Generate provides facilities to build both the primary and secondary endorsements around these specific needs.

Items can optionally have a single primary endorsement using a specified routing. All primary endorsements will have this same routing. By default, the first endorsement will always have the truncation indicator set to “Y”. This default behavior is can be disabled using a check box on the addenda panel.

Items can optionally have multiple secondary endorsements (from 0 to 99). The routing can be either assigned from a specifically assigned number, or can be randomly selected from a user provided list. Generating a single secondary endorsement with a fixed routing is the most commonly used approach for testing. However, in more complex situations, the routing can be assigned from a user constructed list which represents your exchange partners. Assignment from the list allows files to be generated the mimic your production environment.

Invalid Image Test Cases (For X9)

Generate has many capabilities, one of which is to create invalid image test cases. Our invalid image function provides a mechanism to create flawed images that can be sent to your capture systems to see how they react to these various scenarios. The list of invalid image variants has increased over time and we are open to suggestions as to improvements for this facility.

To use this function, you must select the “draw new images” option on the parameters panel (on the left). This process has numerous available options:

You can select the invalid image test cases to be generated.
Check boxes are provided which allow you to easily select all tests or entire groups.
You must indicate the number of images to be generated per test case, which will default to one when not entered.
The invalid image scenario is incorporated into the front side image. Depending on the test case, the resulting image may or may not be be viewable. This is dependent on the type of structural error which has been selected for that image.
The invalid image test case name is drawn into the back side image which is otherwise not modified by this process. This means that each invalid image test case can be easily identified by looking that the corresponding back side image.

Using Make to Create Very Large Files

Make can be used to create very large x9 files. Although Make does not have an internal limitation on the number of items within a single file (within reason). While the XLS file format is limited to a maximum of 65,536 rows, XLSX and CSV do not have this limitation. Thus, those data formats can be be used to represent use case definitions with a very large number of items.

View

Once you define your reformatter rules, you can use the “View” button to view the checks that would be created by Make. This preview 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 preview the output from your new reformatter rules to see if they are creating checks in the manner that you expect, prior to actually running generate.

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

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

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

Generate

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 can specify your generate parameters to create a new output file. Generate allows configurations to be saved, which makes that process configurable and reusable similar to Make.