Background
SAI wants Quik! to support the concept of creating a single forms package for multiple accounts, with some forms being duplicated for some of the accounts.
Problem
Currently Quik! does support adding multiple copies of the same form to a form package. We do this 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).
Here's SAI's scenario... They want to bundle the forms for 3 accounts together but with differing forms. Let's say Acct A gets form ID 1,2,3, Acct B gets 1,3 and Acct C get 2,3.
- The field names for Acct A are the default, normal field names.
- For Acct B the field names are -1
- For Acct C the field names are -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.
Proposed Solution
Modify the QFE to allow the customer to add FormIDs in groups. Using the same method of adding FormIDs today (QuikFormID property) the customer will provide a CSV list of the forms they want in the first group (e.g. "1,2,3"). Then for each additional group of forms they'll 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 allowing the customer to pass in forms as groups the QFE can build the fields for those groups with their own unique instance number.
- For the first group of forms, fields will be 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". You’ll pass normal field names like “1own.FName” and “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"). Let’s say this second group of forms is the same as the first group, FormIDs 1,2,2. So for this group you’ll pass “1own.FName-1000” and for the second instance of FormID 2 the field name will be “1own.FName-1001”.
- Subsequent groups of forms will be 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" and the field names would be “1own.FName-2000”, “1own.FName-2001”, “1own.FName-2002”, “1own.FName-2003”).
NOTE: The QFE must still enforce a rule that no more than 100 FormIDs can be generated at a time.
Why This Solution
The above solution makes it possible for the instance numbers to be managed by the QFE software and not by the customer. The customer must understand the naming convention in order to prefill fields on the additional forms and form groups but the customer does not have to define the numbering, and therefore the customer cannot break the software with a numbering scheme that wasn't intended. This solution is also flexible enough to allow copies of forms within a form group while allowing for multiple form groups.
How Will This Solution Impact Quik!?
- The QFE add form ID method will need to be modified.
- The QFE software will need to control the field names for form copies in relation to the value specified by the customer
- The HTMLFormViewTransaction project will need to be modified for the print/sign routines.
- How will saving forms to the server (e.g. ViaForms) be affected?
- What other web services are affected?
Engineering Team's Estimate
Esteban Sager estimates 2 weeks to rebuild the QFE software, plus 1-3 weeks for the related web services.
Actual Time
The engineering team spent 130 hours on this project plus 30 hours for Chad and Rich's time is 160 hours total.
Action items
- Esteban Sager Gonzalo Luna Please provide an estimate for the number of hours you estimate it will take to build, test and deploy this new feature in version 5.4 of the QFE.dll.
- Richard Walker Provide estimate to Aaron Spahr, Tu Nguyen, Roxanne Weiland at SAI