How Do I Create a Forms Package for Multiple Accounts?

Background

In a prior release, Quik! built a method for supporting the addition of multiple copies of the same form to a form package. This was done by renaming the fields for the first copy of the form by adding a "-1" to the field name, and the 2nd copy with "-2", etc. The original feature was designed for adding copies of forms uniformly within the package or when the form copy is meant to extend the data entry capabilities of the form package (e.g. adding a second beneficiary form so the user can add more beneficiaries).

What Does Controlling Form Copy Instance Numbers Mean To You?

With version 5.4 we now fully support the ability of creating a single forms package for multiple accounts, with some forms being duplicated for some of the accounts.

Example 1:

There's a need to bundle the forms for 3 accounts together but with differing forms. Let's say Acct A gets form IDs 1, 2 and 3, Acct B gets form IDs 1 and 3, and Acct C gets form IDs 2 and 3. 

• The field names for Acct A are the default, normal field names.
• For Acct B the field names are given a suffix of -1
• For Acct C the field names are given a suffix of -2

The problem is that FormID 2 only gets copied in once and has fields named -1 but it's for Acct C that needs fields named -2.

Example 1 Solution:

You can now add FormIDs in groups.

This is done by using the same method of adding FormIDs today (A QuikFormID property). Just provide a CSV list of the forms you want in the first group (e.g. "1,2,3"). Then for each additional group of forms call the same method again and pass the FormIDs specific to that group (e.g. "2,3,12" for the second group, "2,14,1,1" for the third group, etc.).

By passing in forms as groups the Engine can build the fields for those groups with their own unique instance number. 

Please Note: No more than 100 FormIDs can be generated at a time.

Technical Details

• For the first group of forms, fields are built normally without the field instance extension. If, within the first group, FormIDs are duplicated (e.g. form group 1 has forms "1,2,2" where form ID 2 is repeated) then the field instance will be "-1".  
  • “1own.FName” for the first instance of FormID 1 in this first group of forms.
  • “1own.FName-1” for the second instance of FormID 2 in this first group of forms.
• For the second group of forms, fields will be built with a field instance extension. The extension number will start at 1000 (e.g. "1own.FName-1000") and grow as duplicate forms are included in the same package (e.g. the second copy of the same form could have a field named "1own.FName-1001"). 
  • “1own.FName-1000” for the first instance
  • “1own.FName-1001” for the second instance
• Subsequent groups of forms will increase the instance number by 1000. For example, the third form group will have a field instance number starting with "2000" and increments by 1 for each copy of the same form within that group (e.g. if the group contains FormIDs "1,1,1,1" then the instance numbers would be "2000", "2001", "2002" and "2003" 
  • “1own.FName-2000”
  • “1own.FName-2001”
  • “1own.FName-2002”
  • “1own.FName-2003”

Why This Solution?

The above solution makes it possible for the complex instance numbers to be managed by the Quik! software and not you. You will still be able to prefill fields on the additional forms and form groups, but won't need to worry about having to define the numbering. This solution is flexible enough to allow copies of forms within a form group while allowing for multiple form groups.

Use Cases

There's a number of reasons for making use of this feature. The two most common are:

• Householding
• You have more data than what will fit on the one form
  • e.g. Having a 2nd/3rd or more copies of the form will allow for data that wouldn't fit in one form be split across multiples.