Welcome To Release 15.01 > Upgrade Readiness Report |
The Readiness Report is necessary in order to upgrade from Version 10 to Version 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 next topic in this guide. |
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.
![]() |
|
The Readiness Report is included in both the 10.31.15 and 10.31.20 release.
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.
- Once all changes have been made, execute the report again to verify there are no issues or failures.
Below is a list of all reports that are run. The severity shows you the highest impact in which the report could result.
Expandable 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.
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:
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:
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:
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.
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.
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. For each workflow that has been identified by this test:
|
||
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:
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: 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.
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.
Details: Below is the number of account holders identified by this test as having inconsistent data across their linked accounts.
|
||
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". 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. 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.
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.
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.
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.
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. 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:
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:
For item #2, you will need assistance from Akcelerant. 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.
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. 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: 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.
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.
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. 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"):
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. 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"): 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. Account > USERS > Member > Liquid Assets 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. 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. 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. 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. 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. 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. Account > Account Holders > Primary > Profile Financial > TotalLiability Account > USERS > Member > Total Liability 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.
Account > USERS > Member > Total Net Worth 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. 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. 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.
|
||
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. 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"):
|
||
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.
|
||
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"):
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"):
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"):
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"):
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"):
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"):
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"):
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 > Work > Country Case > Primary > Address > Other > Country Case > Fraud > Investigation > Suspect > Suspect 1 > Country Case > Fraud > Investigation > Suspect > Suspect 2 > Country
|
||
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:
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:
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:
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: 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: |
||
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 |