Akcelerant Collections Guide
Upgrade Readiness Report

The Readiness Report is necessary in order to upgrade from Version 10 to Versions 14.00, 14.02, 15.00 or 15.01. If upgrading to 15.01 directly from version 10, please review the below information.

If currently on version 15.01, please proceed to the Uninstalling the Framework Prior to Version 14 Performing an Upgrade Installation topic of this guide.

Are You Ready for an Upgrade?

The Readiness Report allows institutions to run a series of pre-upgrade tests to ensure their environment is ready to upgrade to version 15.01. Specific features contain data conditions that potentially result in failure or warning messages returned when preparing for the upgrade. These tests scan the database to see if problems occur.

  • Every institution needs to run the readiness report prior to upgrading to version 14.00.00 or later to ensure that all failure conditions are eliminated. The upgrade process cannot continue until the report is run at least once and all failure messages are eliminated.
  • The Readiness Report is not applicable for those using the Framework Lending solution.

Installing the Readiness Report

The Readiness Report is included in both the 10.31.15 and 10.31.20 release.

Readiness Report Overview

The time it takes to execute the report varies per customer based on the amount of data in the database.

Possible results for individual tests and the entire report include:

Icon Description

 

A green check mark indicates the test/report has passed and the upgrade can be performed without issues.

A yellow triangle with an exclamation point in the center indicates the test/report has completed with an issue that should be investigated further and corrected before upgrading.

 

A red ‘X’ indicates that the test/report has not passed. Please contact an Akcelerant Customer Care Representative for assistance.

Section Description
Summary                  This section describes the purpose of the report and what the report is checking for prior to the upgrade.
Impact/Severity This section describes the importance of the report and details the impact/severity of the report item. It informs the system administrator why this report needs to pass before upgrading. It also informs the system administrator as to why this report could have failed.
To Resolve This section contains information to help resolve the issue. This section is only displayed if the test receives a warning or failure result.
Details This section contains the number of items impacted. This section is only displayed if the test receives a warning or failure result.

Before making any changes, contact an Akcelerant Customer Care Representative to discuss the report results.

Details of Each Report

Below is a list of all reports that are run. The severity shows you the highest impact in which the report could result.

ShowExpandable Report Details

Report Description
Workflows Using Valid Contact Flag or Busy Signal Flag

Severity: WARNING

Summary: The Valid Contact and Busy Signal flags have been moved from Workflow to Contact Attempts. The Contact Method step requires that the user select a Contact Result for each Contact Attempt, and each Contact Result can be configured as Valid Contacts. This test identifies workflows that have the Workflow Valid Contact or Busy Signal flags set to true, but do not have the Contact Method step in the workflow. If the Contact Step is not in the workflow, the workflow will no longer add a Valid Contact following the upgrade.

Impact/Severity: The upgrade will not fail if no changes are made. But if you do not ensure that the translation is made from the previous Workflow flags to the Contact Method step, then incentives or performance tracking may not work correctly following the upgrade. Without the Contact Method step, there will be no Valid Contacts or Busy Signals logged during workflow execution.

To Resolve:

Before the Upgrade: For each workflow listed in the details below, add a Contact Method step to the workflow.

1. Navigate to System Management > Workflow > Workflows.

2. Locate and Edit a workflow that has been identified in this test.

3. Click on the Design tab.

4. Right-click on the Start Workflow icon and choose "New Step After."

5. From the list of workflow steps, choose Contact Method.

6. In the Contact Method step, enter "Contact Method" as the Step Title.

7. Save the workflow step.

8. Save and Close the workflow.

9. Repeat as needed for any remaining workflows that have been identified in this test.

After the Upgrade: As part of the upgrade to v15.01, there is a System Lookup called CONTACT_RESULT (you can get to it by navigating to System Management > Field Configurations). The system defined values are:

Right Party Contact (Valid Contact = yes)
Left Message (Valid Contact = no)
Busy Signal (Valid Contact = no)
No Answer (Valid Contact = no)
Disconnected (Valid Contact = no)
Wrong Number (Valid Contact = no)

The Valid Contact property of each system defined Contact Result may be configured, and new Contact Results can be added.

Details: The following workflows are marked as “Valid Contact” or “Busy Signal” workflows but do not include a Contact Method workflow step.                  
Reports/Views/Exports Using Busy Signal Flag

Severity: FAILURE

Summary: In your current version of the Framework a field called Busy Signal Flag is available for use in views, reports and exports. This field is being removed from the Framework as part of V14 and above. It has been replaced with a Contact Result called “Busy Signal”. This test looks at all of your views, reports, and exports and lists those that have the Busy Signal Flag in either the field list or the criteria.

Impact/Severity: The V15.01 upgrade will fail if it encounters any views, reports, or exports that use the Busy Signal Flag in the field listing or criteria.

To Resolve:

Before the Upgrade: For each item listed below:

1. Navigate to the appropriate menu item under System Management.

2. Double-click on the item that the field needs to be removed from.

3. Navigate to the field tab and remove the field if it is there.

4. Navigate to the criteria tab and remove the line of criteria that contains the field, if there is one.

5. Save and close the item.

After the Upgrade: Following the upgrade to v15.01, a new System Lookup called CONTACT_RESULTS will be available for use in views, reports, and exports. For any view, report, or export that originally included the Busy Signal Flag, you can add in the contact result of the contact attempt (that is BUSY_SIGNAL) using one or both of the fields listed below:


     Workflow/Comment > Workflow > Contact Attempts > Result - Description
     Workflow/Comment > Workflow > Contact Attempts > Result - Lookup

If replacing a field, then use “Result – Description”.  If replacing a criteria, then use “Result – Lookup”.  Please note that adding Contact Result fields to either the field listing or criteria will result in a row returned for each Contact Result.

Be sure you print this page or document the reports/views/export before you start changing fields. 

Details: The following reports, views, and/or exports contain the workflow for which the Busy Signal field is being removed.                  

Workflow Screens Using Account and Case Data

Severity: WARNING

Summary: V14 and above has completely new screen designer functionality, and as a result it is not possible to have both Account and Case level fields on the same screen. This test looks at all workflows with View Screen steps configured. For each View Screen step, the test looks at the screen and determines if both Account and Case level fields are present. The V15.01 upgrade will take the original screen that contains both types of data and create two screens - one for account data and one for case data. The account screen will be set in the View Screen step of the workflow, while the case screen will not be associated to the workflow. The new screens are named [Old Screen] (Account) and [Old Screen] (Case).

Impact/Severity: The upgrade can complete without any changes made to these screens ahead of time. If you leave things the way they are, the case data will not be visible on a screen during the execution of the workflow after the upgrade (because it's been moved to its own screen). But you will lose the case fields as part of the workflow. If you want to have a similar user experience, then go break the screen into two screens before the upgrade.

To Resolve: There are several approaches you can take for this particular test. As an example, let's say there is a workflow with a View Screen step; the screen is called "Foreclosure" and it has both account and case level fields on it.

Pre-Upgrade Approach: Modify Screen configurations to "split" the screens prior to the upgrade, so that the upgrade keeps the workflow intact.

1. Navigate to System Management > Screens.

2. Double click on the Foreclosure screen to edit it.

3. Review the fields that are on the screen.

4. Identify which fields are case-based, and remove them from the screen.

5. Save and close the screen.

6. Create a new screen (it can be named anything).

7. In the Design, add the case level fields that you removed from the original screen and configure the remaining tabs.

8. Save and Close the screen.

9. Navigate to the workflow identified in the test and add the newly created screen as its own View Screen step.

Post-Upgrade Approach: Allow the upgrade to complete, then go add a second view screen step and use the newly created case screen. If you do this, then be sure to print out the list below so you know what to re-add. The screen name will be the old screen name with “ – case” after it. Add the case level screen created by the upgrade to the workflow.
Using the same example, if you don't make any screen or workflow changes prior to the upgrade, the upgrade is going to split the original "Foreclosure" screen into two separate screens - one called "Foreclosure (Account)" that will be associated with the workflow, and one called "Foreclosure (Case)" that will not be associated with the workflow.

For each workflow that has been identified by this test:

  1. Navigate to System Management > Workflow > Workflows.
  2. Double click on the workflow to edit it.
  3. Navigate to the Design tab and identify where in the workflow the "Foreclosure (Case)" screen should be inserted.
  4. Right click on a step in the workflow and add a new step.
  5. Choose the View Screen step, and assign the "Foreclosure (Case)" screen.
  6. Save and Close the workflow.
Details: The following workflows include a View Screen workflow step that renders a screen that contains both account and case data.                    
Cases Using Custom Case Status Values

Severity: FAILURE

Summary: Prior to V14, the Framework allowed Case Status to have whatever values the customer wanted. But the Framework will begin implementing business logic around the Case Status field, such as system defined reporting, escalation, etc. In order to build system defined processing around Case Status, the values must be system defined. The upgrade to V15.01 requires that only four Case Status lookup values exist: Open, Closed, On Hold, and Cancelled. Any Framework cases (for Bankruptcy, Repossession, etc.) that have a Case Status value other than one of these four values must be modified so that the Case Status is Open, Closed, On Hold, or Cancelled.

Impact/Severity: If there are any active cases that have a non-system Case Status value at the time the V15.01 upgrade is executed for your Framework, the upgrade will fail. Any items identified by this test must be corrected prior to upgrading to V15.01.

To Resolve: For each item listed below, the Case Status needs to be changed to be one of the standard Case Status values that the V15.01 Framework requires (Open, Closed, On Hold, Cancelled). Contact your Akcelerant Customer Care Specialist to assist with resolving this test.

Details: The following active cases are using non-standard status values.

User Defined Case Status Values

Severity: FAILURE

Summary: Prior to V14, the Framework allowed Case Status to have whatever values the customer wanted. But the Framework will begin implementing business logic around the Case Status field, such as system defined reporting, escalation, etc. In order to build system defined processing around Case Status, the values must be system defined. The upgrade to V15.01 requires that only four Case Status lookup values exist: Open, Closed, On Hold, and Cancelled. Any active Framework cases (for Bankruptcy, Repossession, etc.) that have a Case Status value other than one of these four values must be modified so that the Case Status is Open, Closed, On Hold, or Cancelled.

Impact/Severity: If there are any active cases that have a non-system Case Status value at the time the V15.01 upgrade is executed for your Framework, the upgrade will fail. Any items identified by this test must be corrected prior to upgrading to V15.01.

To Resolve: For each item listed below, the Case Status values must be modified to match system values. Contact your Akcelerant Customer Care Specialist to assist with resolving this test.

Details: The following Case Status lookup values are non-standard.                    
Phone Type Mappings

Severity: INFORMATIONAL

Summary: In the pre-V14 and 15 Framework, users were limited to five (5) slots per borrower (primary and each secondary) for recording phone numbers. The number of allowable phone numbers in V15.01 is unlimited, and each phone number in V15.01 has a phone type. As part of the upgrade, the Framework will assign a Phone Type to each phone number in the Framework. In order, the phone numbers will be identified as:

1. Whatever value is in the Framework PH1 slot for a primary or secondary will be set with a Phone Type = Home (many customers already have this phone number labeled as "Home Phone" so there is likely no visible change).
2. Whatever value is in the Framework PH2 slot for a primary or secondary will be set with a Phone Type = Work (many customers already have this phone number labeled as "Work Phone" so there is likely no visible change).
3. Whatever value is in the Framework PH3 slot for a primary or secondary will be set with a Phone Type = Mobile (many customers already have this phone number labeled as "Cell Phone" or "Mobile Phone", so there is likely no visible change).
4. Whatever value is in the Framework PH4 slot for a primary or secondary will be set with a Phone Type = Fax after the upgrade.
5. Whatever value is in the Framework PH5 slot for a primary or secondary will be set with a Phone Type = Other after the upgrade.

If your organization currently uses these ‘slots’ for different phone types, contact your Akcelerant Customer Care Specialist after your upgrade to V15.01 for information on how to create a new Phone Type and use it in place of one of the above mappings.

Impact/Severity: This test is strictly informational, and has no impact on your ability to upgrade to V15.01.

To Resolve: N/A 

Details: N/A              
Address History, Phone History and Account Relationship Screens in Workflow Steps Severity: FAILURE

Summary: The Address History, Phone History and Account Relationships screens have been removed in Framework version 14 and higher. In versions prior to 14, the Framework only had the ability to audit some fields, such as address and phone, which could be viewed within the Address History and Phone History system-defined screens. Now, the Framework has the ability to audit all fields at the person and account levels, so the Address History and Phone History screens have been eliminated and replaced with new Audit screens to show the audit history of fields. As of version 14, the Account Relationships screen has been removed and replaced with the Related Accounts Grid and Overview section of the person workspace. This test identifies the workflows that contain the Address History, Phone History and/or Account Relationships screens as View Screen steps so that they can be modified to include different screens. If the workflows are not modified, the View Screen steps that contain the Address History, Phone History or Account Relationships screens are blank when the workflow is executed in the workspace.

Impact/Severity: The upgrade will fail if it encounters any workflows that have the Address History, Phone History or Account Relationships screens tied to a View Screen step in an active workflow.

To Resolve: Prior to the upgrade, for each workflow listed in the details below:

  1. Navigate to System Management > Workflow > Workflows and edit the workflow.
  2. Navigate to the Design tab and locate the View Screen step that contains the Address History, Phone History or Account Relationship screen.
  3. Remove the View Screen step entirely or replace the Address History, Phone History or Account Relationship screen with another screen.
  4. Save the workflow.

After an upgrade, three new screens at the account, case and person levels are available to display an audit history of field changes. To accomplish a similar end-user experience after the upgrade, review the workflows that were modified prior to the upgrade and insert a View Screen step for the Audit-Person screen, as addresses and phone numbers are stored at the person level in version 14 and above.

Details: The following workflows require correction.      
Inconsistent Borrower Data

Severity: WARNING

Summary: In V10 borrower data is duplicated across each account. In V14 and above, all borrower data is rolled up into a single person record. This test finds borrowers who have inconsistent data across the accounts they hold so that the information can be reviewed prior to the upgrade. If a borrower has multiple accounts, the Framework will take one of the borrower records and all the data associated with it, and use that information to create the V15.01 person record during the upgrade. If some of the V10 borrower records have missing or conflicting data in a field, there is the risk of data being lost.

Impact/Severity: As an example, John Doe has 4 accounts with you. On two of those borrower records there is a value in the email address field, and on the other two records that information is missing. During the upgrade, it is possible that the Framework will roll up the borrower data using one of the records that does not include the email address. In this situation, the V15.01 person record will not include an email address.
This test looks at all records in V10 that have the same Account Link value (Account > Account Information > Miscellaneous > Account Link). Depending on your financial institution nature and your core processor, this is generally the Member Number, Person Number, or CIF.
If the test finds borrower records where the data in any of the below fields differs within a single Account Link value, it will be identified so that you have the opportunity to review and make corrections as needed.


Full Name
First Name
Middle Name
Last Name
SSN
Birth Date
Email
Mothers Maiden Name
Employer

To Resolve: You must clean up the inconsistencies across the identified records or accept the risk of lost data. This test will identify for you how many account holders are affected. To get a detailed list of the inconsistencies, you can download the report definition file and then run the report through your V10 Framework.

1. In V10, navigate to System Management > Reports.

2. Click Create to start a new report.

3. For the Report Creation Type, choose “Predefined” from the drop-down.

4. Locate the file that you just downloaded by clicking on the Browse button next to the Upload Report Definition field.

5. Assign the report to the appropriate user(s).

6. Click Save and Close, then run the report.

Details: Below is the number of account holders identified by this test as having inconsistent data across their linked accounts.            

If a timeout error is received during execution of this test ("Unable to complete test, Timeout expired"), please contact an Akcelerant Customer Care Representative.
Invalid SSNs

Severity: WARNING

Summary: The person-centric nature of V15.01 depends on valid SSN values in order to consolidate all of a borrower's accounts. In order to ensure that accounts are not tied to a person if they don't actually belong to that person, all Framework imports (core interface as well as profile import) require that SSN values are "valid".
An SSN is invalid if is it not 9 digits (after any dashes or other punctuation are removed), or it is all of the same number (111111111, 222222222, etc.).

Impact/Severity: If SSNs are not valid for an account holder, it is possible that all accounts associated with that account holder will not get linked to them in V15.01. This equates to how data was presented in V10. In other words, if the SSN is not valid then those accounts will become member account centric, rather than person centric.
Please note that this is a warning test, and does not require that you correct any data. If you are a Fiserv DNA or Fiserv IBS customer, then you can disregard this warning.

To Resolve: To avoid loss of V15.01 person centric functionality, the SSN values for the identified records should be corrected so that they are valid. This test will identify how many account holders are affected. To get a detailed listing of the inconsistencies, you can download the report definition file and then run the report through your v10 Framework.

  1. In V10, navigate to System Management > Reports. Click Create to start a new report.
  2. For the Report Creation Type, choose “Predefined” from the drop-down.
  3. Locate the file that you just downloaded by clicking on the Browse button next to the Upload Report Definition field.
  4. Assign the report to the appropriate user(s).
  5. Click Save and Close, then run the report.
The invalid SSN values must be fixed in your system of record (i.e. your core processor) and then a new import will need to be run so that the correct values are in the Framework database.

Details: Below is the number of account holders identified by this test as having invalid SSN values.

Profile Imports - Person Data Without Tax ID Code Designation

Severity: WARNING

Summary: Because V15.01 is person-centric, a number of changes have been made with regard to how data is linked together to identify all accounts that a person is associated with. In addition, changes have been made in the logic to determine whether someone is a Person or an Organization (Business). The core interfaces have been modified to accommodate the new logic, but if you use Profile Imports to bring additional borrower data into the Framework, adjustments may need to be made in order for person linking and business identification to be handled correctly. This test looks at all "Create/Update" Profile Import layouts that have any person-related fields (names, addresses, etc.) that do not also include the Tax ID Code field. In V15.01, the Profile Import will look at the value in the Tax ID Code field, and if there is a "B" or a "b" in that field, the "person" will be identified as an Organization.

Impact/Severity: Without a Tax ID Code, the upgrade can complete, but any business accounts imported through profile import will be categorized as person accounts. That means that business and persons would incorrectly be shown together on the related accounts grid.

To Resolve: If you don't import business/commercial accounts into the Framework using Profile Import, then no action will be required either before or after the upgrade.

If you are using profile import to bring business accounts into the Framework, you will need to add a new field to the end of the file you're currently providing, and populate that field with either "B" or "b" for each person in the file that you want marked as Organizations. Persons in the file that are not for business accounts do not need to have any value in this field. In addition, the configuration of the profile import layout will need to be modified to add this field. This is a task that Akcelerant needs to perform.

  1. Open a support case through the Collaboration Portal
  2. Title the case "V15.01 Upgrade Readiness - Profile Import Tax ID Code"
  3. In the description of the case, either list out the profile import names identified below that need to be modified, or attach a screenshot of the readiness test.

If you are unsure of what fields are currently configured for your profile imports, please contact your Akcelerant Customer Care Specialist.

Details: The following profile import layouts include person data but are not currently configured to include the Tax ID Code field.         

Profile Imports - Person Data Without SSN

Severity: FAILURE

Summary: Because V15.01 is person-centric, a number of changes have been made with regard to how data is linked together to identify all accounts that a person is associated with. The core interfaces have been modified to accommodate the new logic, but if you use Profile Imports to bring additional borrower data into the Framework, adjustments may need to be made in order for person linking to be handled correctly. This test looks at all "Create/Update" Profile Import layouts that have any person-related fields (names, addresses, etc.) that do not also include the SSN field. This applies to both the Primary and the Secondary borrowers in the Framework.

Impact/Severity: The V15.01 upgrade will fail if there are any Profile Import layouts that contain borrower/coborrower information but are missing the applicable SSN field.

To Resolve: If you are using profile import to "create" people in the Framework, you will need to add the SSN field to the end of the file you're currently providing, and populate that field with the SSN for the person being included.

This could result in more than one field being added to the file; if the file contains information for the Primary AND Secondary 1, you will need to add the Primary SSN AND the Secondary 1 SSN to the end of the file.

In addition, the configuration of the profile import layout will need to be modified to add the field(s). This is a task that Akcelerant needs to perform.

1. Open a support case through the Collaboration Portal.

2. Title the case "V15.01 Upgrade Readiness - Profile Import SSN."

3. In the description of the case, either list out the profile import names identified below that need to be modified, or attach a screenshot of the readiness test.

If you are unsure of what fields are currently configured for your profile imports, please contact your Akcelerant Customer Care Specialist for a screenshot of the layout(s).

Details: The following profile import layouts include person data but are not currently configured to include the SSN field.                        
Profile Imports - Custom Procedures

Severity: WARNING

Summary: If your organization uses Profile Imports to bring data into the Framework, it is possible that there is some custom code that is "tied" to that profile import. This custom code is in the form of stored procedures that were written by Akcelerant or your institution to perform tasks that the profile import cannot do. Because of the architectural changes made to the Framework database in V15.01, stored procedures that are tied to profile imports in V10 may need to be modified following the upgrade. Because of this, Akcelerant needs to review all custom stored procedures identified below prior to the upgrade to either confirm that there are no changes required, or to make the necessary changes to accommodate the new architecture.

Impact/Severity: The upgrade can complete but the behavior of the pre- or post-profile import stored procedures in profile imports may not work correctly after the upgrade.

To Resolve: Because this information can only be obtained directly through the Framework database, assistance from Akcelerant is required.

1. Open a support case through the Collaboration Portal.

2. Title the case "V15.01 Upgrade Readiness - Custom Stored Procedures."

3. In the description of the case, either list out the results identified below, or attach a screenshot of the readiness test.

4. Prior to the upgrade, a Product Support Developer will connect to the V10 Framework database, take a copy of the stored procedure(s) that have been identified, and have the contents evaluated for accuracy in V15.01.

5. If no changes are needed to the stored procedure(s), then no further action is required.

6. If changes are needed to one or more stored procedures in order to function correctly in V15.01, the Product Support Developer will reconnect to your Framework database post-upgrade and place the correct code prior to the next execution of your profile imports.

Details: The following Profile Import(s) and stored procedure(s) require review.                
Profile Imports - Creating Persons With a Delinquent Only Core Severity: WARNING              

Summary: Because of how people will be created in V15.01, it will be possible for duplicates to be created under certain circumstances. This test looks to see if you have any profile imports that are configured as “create/update” AND you have a core interface activated that can be configured as Delinquent Only.

Impact/Severity: The upgrade can complete, but if the order of person creation is such that the profile import creates the person before the batch interface does, the V15.01 Framework could have duplicate person records. If your organization falls under one of the following scenarios, your profile import configurations should be reviewed for potential modification to avoid having duplicate person records created:

  1. You have DNA or Miser as your core processor, your current Framework batch interface files include Delinquent Only accounts, and you use create/update profile imports that include person-level data.
  2. You have IBS or XP as your core processor and you use create/update profile imports that include person-level data.
With the above scenarios, your profile import may create a new person that did not previously exist in the Framework (it is not being transmitted through the core interface because it is not yet delinquent). If the person becomes delinquent later, the core interface will begin sending that person through the batch files.

To Resolve: If your core processor is DNA or Miser and your current Framework interface is set to provide all accounts each day, no action is required.

If your core processor is sending Delinquent Only accounts each day through the batch interface, one of the following approaches is recommended:

1. Import all of your Framework data using profile import rather than through the core batch import.

2. Add the core-specific person source identifier to your profile import and populate it with the applicable values.

For item #2, you will need assistance from Akcelerant.

1. Open a support case through the Collaboration Portal.

2. Title the case "V15.01 Upgrade Readiness - Profile Import and Delinquent Only Core."

3. In the description of the case, either list out the results identified below, or attach a screenshot of the readiness test.

Details: The following profile imports are set as create/update and your organization has a core processor that allows for Delinquent Only batch files.                                        
Profile Imports - Missing Field List Records

Severity: FAILURE

Summary: If your organization uses Profile Imports to bring data into the Framework, it is possible that there are fields available for profile imports that are not available elsewhere in the Framework. If any of these fields exist on a Profile Import, Akcelerant will need to add additional records to ensure these fields upgrade properly.

Impact/Severity: The fields with missing records will not upgrade properly, and the profile will be left in an unusable state.

To Resolve: Because the fix must be applied directly to the Framework database, assistance from Akcelerant is required.

1. Open a support case through the Collaboration Portal.

2. Title the case “V15.01 Upgrade Readiness - Profile Import Missing Field List Records.”

3. In the description of the case, either list out the results identified below, or attach a screenshot of the readiness test.

4. Prior to the upgrade, a Product Support Developer will connect to the V10 Framework database and add the missing records.

Details: The following Profile Import field(s) require review.

Database - Unknown Custom Indexes

Severity: FAILURE

Summary: Over time, it's possible that one or more Custom Indexes have been added to your Framework database. Generally a custom index is added to assist with faster processing of large amounts of data. This test identifies any custom indexes that need to be removed from the Framework database prior to the upgrade.

Impact/Severity: The V15.01 upgrade will fail if there are any unexpected custom indexes in your V10 Framework database.

To Resolve: Because the only way to resolve these items is directly through the Framework database, assistance from Akcelerant is required.

1. Open a support case through the Collaboration Portal.

2. Title the case "V15.01 Upgrade Readiness - Custom Index Test Failure."

3. In the description of the case, either list out the results identified below, or attach a screenshot of the readiness test.

4. Prior to the upgrade, a Product Support Developer will connect to the V10 Framework database, remove the index(es) that have been identified, and create a script to add the index(es) back into the database.

5. Post upgrade, a Product Support Developer or Customer Care Specialist will connect to the V15.01 Framework database and recreate the index(es).

Details: The following custom indexes have been identified in your V10 database.                                      
Database - Custom Indexes

Severity: WARNING

Summary: Over time, it's possible that one or more Custom Indexes have been added to your Framework database. Generally a custom index is added to assist with faster processing of large amounts of data. Custom indexes may no longer be correct following the upgrade to V15.01.

Impact/Severity: Custom indexes may no longer be correct following the upgrade to V15.01. This may cause errors in the system.

To Resolve: Contact your Customer Care Specialist to review this warning and ensure that your upgrade can continue.

Details: The following custom indexes have been identified in your V10 database.                                         
Unsupported Standard Fields in the Field List

Severity: FAILURE

Summary: This test looks for fields in your field list that are not part of the standard V15.01 field list. Some field lists contain only a subset of the available standard fields. For example, the Promise field list only contains a handful of account-level fields. If an unsupported standard field was added to your field list in the past by Professional Services or Customer Care, it will cause issues during the upgrade to V15.01. This test prevents the upgrade until these fields are handled in such a way that no issues with be encountered.

Impact/Severity: You cannot upgrade to V15.01 until these unsupported standard fields are handled.

To Resolve: Contact your Customer Care Specialist to analyze the fields below. The fields will be added to the standard field list and made available to all customers.

Details: The following fields are unsupported standard fields.                                       
Scheduled Reports

Severity: WARNING

Summary: If you have any reports in your current version of the Framework that have been Scheduled (as opposed to being an "on demand" report), they will need to be resaved immediately after your upgrade to V15.01. This is because the details of the Schedule are written to a location that is outside the basic Framework. This test lists all reports in your current version of the Framework that are scheduled. You will need to use Server Manager to reset these scheduled reports.

Impact/Severity: The upgrade will not fail if you have any scheduled reports, and there are no steps that need to be performed prior to the upgrade. If your scheduled reports are not resaved after the upgrade, they will not generate correctly and will not run on the configured schedule.

To Resolve:

1. Following the upgrade, go to the server where the Reporting feature is installed.

2. Launch server manager on that server.

3. Navigate to the reporting services item on the left.

4. Choose Regenerate Reports and click Update.

Details: The following reports are currently configured to run on a schedule.                     
Core-Specific User Defined Fields

Severity: WARNING

Summary: This test identifies any core-specific user defined fields that have had their labels changed over the course of time. The upgrade to V15.01 will revert the labels to their original values.

Impact/Severity: This test is a warning. While label changes on core-specific user defined fields will not cause your upgrade to fail, this test identifies those items that have had label changes so that you can take note before the upgrade. In addition, any core-specific user defined fields in use on screens, reports, and views will retain the labels on those items.

To Resolve: N/A

Details: The following field paths/labels will be reverted during the upgrade to V15.01. For each row, you are being provided with the Framework Table the field exists in, the Field List Type (Queue, Report, Screen), the Original Field Path (what the field list will show after the V15.01 upgrade), and what the current Field Path is (what the field is called in V10).                                    
Data Type Mismatch - Field Lengths

Severity: WARNING

Summary: In V15.01, the lengths of some fields have been shortened from what they are in V10. An example might be that the field for License Plate is 200 characters long in V10, but that same field will only be 50 characters in V15.01. This test looks at the data you have stored in these fields, and identifies any accounts where the data currently entered will exceed the new length of the field in V15.01.

Impact/Severity: The upgrade can complete but any characters that are beyond the new length for that field in V15.01 will be stripped out and only the first XX characters will be kept (based on the new field length).

To Resolve: For each row below, we provide the field path for the field that needs to be reviewed, the Account Identifier that contains a value that will be shortened as part of the upgrade, the Case Number (if it is a case level field), and the V15.01 field length. The accounts/cases listed below must be opened in the workspace and the field in question must be added to a screen in order to be modified. The length of the value in the field must be modified to accommodate the new field length; no other field or data changes need to be made.

Details: The following fields have data that will exceed the maximum length in 15.01.              
Data Type Mismatch - Text to Number

Severity: WARNING

Summary: Between V10 and V15.01, there have been some changes made to Framework fields with regard to their data type (the fields in V15.01 are "number" fields and the same field in V10 is a "text" field). This test looks at all of the fields that will be changing from one data type to another, and identifies if there is any data in those fields for any of your accounts. Because these fields are "text" fields in V10, it's possible that a user has entered non-numeric characters. Because of this, the data will not be able to be converted to a "number" during the upgrade.

Impact/Severity: This is a warning, so the upgrade can complete without any action taken. But if any of the fields listed below are not addressed, then the data in these fields will be cleared during the upgrade.

To Resolve: For each of the fields identified below, open a screen that contains the field and review the data in the field. Either clear the value of the field, or change it to a value that is a number. Then save the screen.

You may need to build a screen to display these fields.

Details: The following fields have data that will not convert during the upgrade. 

Data Type Mismatch - Floats to Decimal

Severity: FAILURE

Summary: During the V15.01 upgrade, the data types for some fields are going to change from “float” to “decimal”. These are both numerical fields, but their structure is different in the database. As a result, data that is currently being stored in these fields, while valid for a “float” field, may be invalid when trying to be converted to a “decimal”. A decimal has a max value of 100,000. A float has a maximum value of more than 100,000. This test identifies any fields that are changing from Float to Decimal, and exceed the max value for a Decimal.
Impact/Severity: The upgrade will fail if there are any fields with data that will be considered invalid based on the data type change.

To Resolve: For each of the fields identified below, open a screen that contains the field and review the data in the field. Either clear the value of the field, or change it to a valid number. Then save the screen. 
You may need to build a screen to display these fields.

Details: The following fields have been identified as having invalid data based on the data type change during the upgrade.

Elimination of tblBorrower.Business

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.
Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists. If you want this data to be maintained after the V15.01 upgrade, it must be migrated to a custom field before your upgrade.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. This will clear the "information" indicator the next time you run the Readiness Report and you won't need to review this item again.

To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

Account > Account Holders > Primary > Address Work > Business Name

If you wish to keep this data and have an available custom or user defined field that can be used, add that custom or user defined field to a detail screen (along with the field being removed) and manually copy/paste the data from the field being removed to the custom or user defined field.

If you do not have an available custom or user defined field that can be used and you wish to keep this data, contact your Akcelerant Customer Care Specialist to request a field be made available so that you have a field to populate the data in.  

If you want this data migrated for you by Akcelerant, a Statement of Work can be requested through your Customer Care Specialist.

Details: The following locations are currently using this field in either the Field List or Criteria.
Elimination of tblBorrower.CreditScore

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.
Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists. If you want this data to be maintained after the V15.01 upgrade, it must be migrated to a custom field before your upgrade.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs.

To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

     Account > Account Holders > Primary > Credit Score

If you wish to keep this data and have an available custom or user defined field that can be used, add that custom or user defined field to a detail screen (along with the field being removed) and manually copy/paste the data from the field being removed to the custom or user defined field.
If you do not have an available custom or user defined field that can be used and you wish to keep this data, contact your Akcelerant Customer Care Specialist to request a field be made available so that you have a field to populate the data in.   

If you want this data migrated for you by Akcelerant, a Statement of Work can be requested through your Customer Care Specialist.                  

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblBorrower.LiquidAssets

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists. If you want this data to be maintained after the V15.01 upgrade, it must be migrated to a custom field before your upgrade.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. This will clear the "information" indicator the next time you run the Readiness Report and you won't need to review this item again. 
To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

     Account > Account Holders > Primary > Profile Financial > LiquidAssets

     Account > USERS > Member > Liquid Assets

If you wish to keep this data and have an available custom or user defined field that can be used, add that custom or user defined field to a detail screen (along with the field being removed) and manually copy/paste the data from the field being removed to the custom or user defined field.
If you do not have an available custom or user defined field that can be used and you wish to keep this data, contact your Akcelerant Customer Care Specialist to request a field be made available so that you have a field to populate the data in. 
If you want this data migrated for you by Akcelerant, a Statement of Work can be requested through your Customer Care Specialist.

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblBorrower.LiquidWorth

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists. If you want this data to be maintained after the V15.01 upgrade, it must be migrated to a custom field before your upgrade.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. This will clear the "information" indicator the next time you run the Readiness Report and you won't need to review this item again. 
To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

     Account > Account Holders > Primary > Profile Financial > LiquidWorth

     Account > USERS > Member > Liquid Worth

If you wish to keep this data and have an available custom or user defined field that can be used, add that custom or user defined field to a detail screen (along with the field being removed) and manually copy/paste the data from the field being removed to the custom or user defined field.

If you do not have an available custom or user defined field that can be used and you wish to keep this data, contact your Akcelerant Customer Care Specialist to request a field be made available so that you have a field to populate the data in. 
If you want this data migrated for you by Akcelerant, a Statement of Work can be requested through your Customer Care Specialist.

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblBorrower.TotalAssets

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists. If you want this data to be maintained after the V15.01 upgrade, it must be migrated to a custom field before your upgrade.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. This will clear the "information" indicator the next time you run the Readiness Report and you won't need to review this item again. 
To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

     Account > Account Holders > Primary > Profile Financial > TotalAssets

     Account > USERS > Member > Total Assets                        

If you wish to keep this data and have an available custom or user defined field that can be used, add that custom or user defined field to a detail screen (along with the field being removed) and manually copy/paste the data from the field being removed to the custom or user defined field.
If you do not have an available custom or user defined field that can be used and you wish to keep this data, contact your Akcelerant Customer Care Specialist to request a field be made available so that you have a field to populate the data in.
If you want this data migrated for you by Akcelerant, a Statement of Work can be requested through your Customer Care Specialist.

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblBorrower.TotalLiability

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.
Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists. If you want this data to be maintained after the V15.01 upgrade, it must be migrated to a custom field before your upgrade.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. This will clear the "information" indicator the next time you run the Readiness Report and you won't need to review this item again. 
To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

     Account > Account Holders > Primary > Profile Financial > TotalLiability

     Account > USERS > Member > Total Liability

If you wish to keep this data and have an available custom or user defined field that can be used, add that custom or user defined field to a detail screen (along with the field being removed) and manually copy/paste the data from the field being removed to the custom or user defined field.

If you do not have an available custom or user defined field that can be used and you wish to keep this data, contact your Akcelerant Customer Care Specialist to request a field be made available so that you have a field to populate the data in. 

If you want this data migrated for you by Akcelerant, a Statement of Work can be requested through your Customer Care Specialist.

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblBorrower.TotalNetWorth

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists. If you want this data to be maintained after the V15.01 upgrade, it must be migrated to a custom field before your upgrade.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. This will clear the "information" indicator the next time you run the Readiness Report and you won't need to review this item again. 
To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

Account > Account Holders > Primary > Profile Financial > TotalNetWorth

           Account > USERS > Member > Total Net Worth

If you wish to keep this data and have an available custom or user defined field that can be used, add that custom or user defined field to a detail screen (along with the field being removed) and manually copy/paste the data from the field being removed to the custom or user defined field.

If you do not have an available custom or user defined field that can be used and you wish to keep this data, contact your Akcelerant Customer Care Specialist to request a field be made available so that you have a field to populate the data in. 
If you want this data migrated for you by Akcelerant, a Statement of Work can be requested through your Customer Care Specialist.                        

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCoborrower.CB1AccountNumber

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. This will clear the "information" indicator the next time you run the Readiness Report and you won't need to review this item again. 
To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

Account > Account Holders > Secondary > Secondary 1 > Account Number


Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCoborrower.CB1ID

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):


Account > Account Holders > Secondary > Secondary 1 > Reference ID


Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCoborrower.CB2AccountNumber

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

Account > Account Holders > Secondary > Secondary 2 > Account Number


Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCoborrower.CB2ID

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):


Account > Account Holders > Secondary > Secondary 2 > Reference ID

 

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCoborrower.CB3AccountNumber

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):


Account > Account Holders > Secondary > Secondary 3 > Account Number

 

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCoborrower.CB3ID

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):


Account > Account Holders > Secondary > Secondary 3 > Reference ID

 

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCoborrower.CB4AccountNumber

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

Account > Account Holders > Secondary > Secondary 4 > Account Number

 

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCoborrower.CB4ID

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

Account > Account Holders > Secondary > Secondary 4 > Reference ID

 

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCaseSecondary.CS2Prefix

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):


Case > Bankruptcy > Co-Filer > Attorney > Contact > Prefix
Case > Repossession > Disposition > Seller > Name Detail > Prefix

 

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of tblCaseSecondary.CS4Prefix

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):


Case > Bankruptcy > Filer > Attorney > Contact > Prefix

 

Details: The following locations are currently using this field in either the Field List or Criteria.

Elimination of Country Fields in tblCasePrimaryAddress and tblCaseSecondaryAddress

Severity: WARNING

Summary: This test checks to see if you currently use a field that is being removed in V15.01.

Impact/Severity: This field is being removed in V15.01 and will no longer be available for views, reports, letters, etc. The V15.01 upgrade will remove this field from the database and any data that is in it as well as all field lists.

To Resolve: For each item listed below, review the configuration and remove the field from the field and/or criteria tabs. To determine if this field contains data that you want to retain, you can build a view or report and ensure that the field in the following location is in both the field list and criteria (where the value of the field "Is Not Blank"):

     Case > Primary > Address > Home > Country

     Case > Primary > Address > Work > Country

     Case > Primary > Address > Other > Country

     Case > Fraud > Investigation > Suspect > Suspect 1 > Country

     Case > Fraud > Investigation > Suspect > Suspect 2 > Country


Details: The following locations are currently using these fields in either the Field List or Criteria.

Change Field Workflow Step changes fields that are one-to-many

Severity: FAILURE                        

Summary: There are certain types of Framework data elements that exist as a one-to-many relationship. An example of this is a person’s addresses. A person may have more than one address, so there is one person to many addresses. Any field that exists in a one-to-many relationship cannot be used in the Change Field Workflow Step. This includes persons, emails, phones, addresses, collaterals, etc. In Version 10, these items existed in a one-to-one relationship, so it was possible to use them in the Change Field workflow step. In version 14 and above, this is no longer possible.

Impact/Severity: The Version 15.01 upgrade will fail if there are any Change Field Workflow steps configured to change the value of any one-to-many fields.

To Resolve: In order to resolve this failed test, the Change Field workflow step must be modified to only use one-to-one fields. All one-to-one fields are available in the field list selector in the workflow step properties. In some cases, the field in question may have been repurposed and creating a new one-to-one custom field may be a suitable replacement.

Details: The following Change Field workflow steps have been identified in version 10.

Field List Inconsistencies

Severity: Warning

Summary: To properly migrate a field to V15.01, the Short Display of the field must match across all Field List Types in which the field is included. This report shows all of the variations in Short Displays that are associated to a single field.

Impact/Severity: The upgrade will not fail; however, field lists for queues, reports, screens, views and workflows will be unable to locate these fields because they are not mapped properly during the upgrade.

To Resolve:

Before the upgrade:

For each field listed in the readiness test, identify the Short Display to be used in V15.01 by following the below steps:

  1. Open a support case through the Collaboration Portal
  2. Title the case "V15.01 Upgrade Readiness - Field List Inconsistencies"
  3. Attach a screenshot of this readiness test to the case
  4. Prior to the upgrade, Akcelerant will asssit you to resolve this error and identify the Short Display that is to be used in V15.01.

Details: The table identifies the inconsistencies in Short Displays of the fields in version 10.

Report Fields containing non-CLS compliant names

Severity: WARNING

Summary: The labels used by report fields must begin with a letter to be CLS-compliant.

Impact/Severity: The upgrade will not fail if no changes are made. Reports with non-compliant fields will not be able to regenerate if modified in the designer.

To Resolve: Before the upgrade, for each report listed in the details below:

  1. Navigate to Reports.
  2. Locate and Edit the report.
  3. Click on the Fields tab.
  4. Look for all fields whose Display Name does not begin with a letter.
  5. Modify the Display Names of those fields.
  6. Save the report.

If the report saves successfully, you are finished with this report. However if an error occurs, it is most likely because the report has been modified in the designer. In this case, do the following:

  1. While the report is still open in the editor, go the report listing page and click "Design" on the report to open it in designer.
  2. In the designer, double-click on Datasets > DataFields to open the Dataset Properties dialog.
  3. Replace all of the SQL aliases that used non-compliant names with the new display names you chose.
  4. Click on "Refresh Fields" and then close the properties dialog.
  5. Change each field used on the designer surface whose display name changed so that it is reflective of the new field alias.
  6. Save and close the designer.
  7. Now try to save the report from the edit report dialog in the Framework.

Details: The following reports contain one or more fields whose labels are non-CLS compliant.

Property Address data may be lost during upgrade

Severity: WARNING

Summary: Prior to V14 and 15, property address data was stored in three separate locations in the Framework database – tblAccountCollateral, tblAccountMortgage and tblAccountSecured. This redundancy was eliminated in V14 and above. There is a possibility of data loss if differing data is being stored in more than one location in the database at the time of upgrade. 

Impact/Severity: The upgrade will not fail due to this data loss. The upgrade will consolidate the three records into a single record. As long as an account does not have data in multiple locations, there is no impact. If data is stored in more than one location, data will be lost during the upgrade unless action is not taken. If you want this data to be maintained after the V15.01 upgrade, it must be migrated to custom fields before your upgrade.

To Resolve: In order to be able to effectively evaluate all property address data for the accounts returned below to determine if any data should be stored elsewhere in your system prior to the upgrade, it is recommended that you build a detail screen that includes the following fields:

     From the Account > Product > Loan > Collateral folder: Collateral Address, Collateral City, Collateral State, Collateral Postal (these are fields stored in the database within tblAccountCollateral)
     From the Account > Product > Loan > Mortgage > Property folder: Property Address, Property City, Property State, Property Postal (these are fields stored in the database within tblAccountMorgage)
     From the Account > Product > Loan > Secured folder: Property Address, Property City, Property State, Property Postal (these are fields stored in the database within tblAccountSecured)

During the upgrade, the property address data from tblAccountCollateral is migrated to its new location within the database. Then the upgrade takes the property address data from tblAccountMortgage and overlays what is already in the new location. Lastly, the upgrade takes the property address data from tblAccountSecured and overlays what is already in the new location. 

The upgrade does not overwrite data with blank values if ALL property address values from a particular table are empty.

If you find that multiple addresses are being stored for a particular account and you wish to retain this data in the Framework after the upgrade, you can use custom/user defined fields to input the data you need to keep. After you have moved the data to a custom/user defined field, clear the data from the account so that the upgrade sees empty fields. Note: if the same address data is being displayed as existing in more than one table below and the data is identical, no changes need to be made. The upgrade will migrate the data to the new location.

If you do not have custom/user defined fields available and you wish to keep this data, contact your Akcelerant Customer Care Specialist to request fields be made available so you can input the data. If you want this data migrated for you by Akcelerant, a Statement of Work can be requested through your Customer Care Specialist.

Details: Below are all accounts where there are property address values in multiple tables that get consolidated into a single table after the upgrade. The format of the results is as follows:

     Account Identifier: (tblAccountCollateral: value)  (tblAccountMortgage: value)  (tblAccountSecured: value)
     
For each row, review the values carefully. If any table is not listed for an account, that means there is no data stored in those fields.  If any/all tables show identical address values, then no action needs to be taken. If any two tables have differing address values, you will have to decide whether the data should be maintained for both or not. If you do not need to maintain both, pull up the account in a workspace, go to the screen you built, and clear the data you don't need any longer. If you do need to maintain both, copy/paste one set of address values into custom/user defined fields and then clear the data from the table  input one  table shows no address data and the other two tables show the exact same values then no action needs to be taken.  If all three tables show different address values, then you will need to pick two sets to clear (after moving the values to custom/user defined fields if you wish to keep the data).

Number of Custom Fields

Severity: WARNING

Summary: This test looks for the number of custom fields. There are only able to be 1023 custom fields on the system.

Impact/Severity: The upgrade could potentially fail if the system has more than 550 custom fields without a full analyzation.

To Resolve: Contact your Customer Care Specialist to fully analyze the custom fields.

Details: N/A

Current Version and Core Import Validation Severity: FAILURE     

Summary: SourceIdentifiers identify the origin of a record and contain information necessary to match up the record during future imports. These SourceIdentifiers provide significant improvements to upgrade stability. Connectors that create people as part of the import process have been updated to include SourceIdentifiers through the 10.31 releases. This test identifies whether the appropriate 10.31 release has been installed, based on the Core interface.

Impact/Severity: After upgrading, duplicate person records could be created if the source identifiers have not been set.

To Resolve: Current version is not ready for an upgrade. Please see details section for the right version to be on and/or core import that needs to be run successfully before import.

Details:

Current version: XX.XX.XX

Minimum target version: XX.XX.XX

Core process status: [ProcessName] – [Successful / Not completed], [ProcessName] – [Successful / Not completed]

The following release must be installed based on the existing customer core prior to upgrading:

Release Core
10.31.15
  • Summit
  • Symitar
  • OSI
  • DataSafe
  • XP
  • IBS
  • Profile Import
10.31.21
  • Coast Capital
  • Miser
  • Fiserv Advantage
  • Fiserv CBS
  • Fiserv CUBE
  • UltraData
  • OTS

 

 


©2017 Akcelerant Software LLC. All Rights Reserved.