List of Manual Actions in IFS Application Components

This section contains information related to manual actions for IFS Application Components that might be needed to be executed during an upgrade installation. The manual actions must be executed before clean scripts are executed.

Click Show/Hide Legend to view a description of the columns in the table describing the manual actions. Click Export Table to download the entire table in Microsoft Excel format (*.xlsx) and view offline.

Note: This page uses javascript and is best viewed in Microsoft Edge, Google Chrome, or Mozilla Firefox.

Show/Hide Legend



Export Table - Right-click on the link and select Save As... to save the file.

Component
APP75
Upgrade
APP8
Upgrade
APP9
Upgrade
APP10
Upgrade
Installation Step
Mandatory Action
Activity Description
Functional Conditions for Execution
Technical Dependencies
Consequences
 (of not executing)
Script Name
Script requires
user input
Steps
Functional Assistance
Required
Parallel
Execution
Estimated
Duration
Additional Information
ACCRUL All All All All Pre - Immediate Yes Update vouchers in hold tables to General Ledger None None Inconsistent data in the General Ledger. This will affect Balances as well. N/A N/A Before upgrading Accrul make sure that all vouchers in the hold table, i.e. tables voucher_tab and voucher_row_tab, are updated to the General Ledger. Yes N/A   Vouchers based on a voucher type for which Store Original is selected, will still be available in the hold table after update to the General Ledger.
ACCRUL N/A N/A UPD1 - Any   Post - Immediate No Update Deductible% in the Tax Code window Only applicable for customers who want to update the Deductible % on the Tax Code window to a different Deductible % after the upgrade.
This might require for US and Canadian customers who intend to use the Non-Deductible Tax handling which was introduced in IFS Applications 9 – Update 1 for Tax Types Sales Tax and Use Tax.
None Cannot change the deductible % less than 100. N/A N/A /* Following example shows how to change Deductible Percentage of Tax Code 1 in company 10 to 40 */

DECLARE
   company_ VARCHAR2(20)         := '10';
   tax_code_ VARCHAR2(20)        := '1';
   deductible_percentage_ NUMBER := 40;

BEGIN
   UPDATE statutory_fee_tab
   SET deductible = deductible_percentage_
   WHERE company = company_
   AND fee_code = tax_code_;
   COMMIT;
END;
/

Yes N/A Short  
APPSRV All All RTM - UPD7 N/A Post - Anytime No Archive image and audio type media items in an Azure Blob Storage This script should be executed if you want to use the functionality which archives image and audio type media items in an Azure Blob Storage.   Space would be taken up in the database overtime. POST_APPSRV_App9_MediaArchiveAclGrants.sql Yes To execute the script follow the steps below:
  1. Login to the Oracle Database as SYSDBA
  2. Execute the POST_APPSRV_App9_MediaArchiveAclGrants.sql file located at ..\appsrv\manualdeploy\database\appsrv\
  3. When executing above script you will be prompted for information below
    APPLICATIONS_OWNER => App Owner for the Database
    AZURE_CLOUD_HOST => Host name of the Azure Blob Storage Account URL 
    (E.g.: <Azure Account Name>.blob.core.windows.net)
No   Cannot Predict  
BACLI All N/A N/A N/A Post - Immediate Yes Upgrade IFS Business Reporter reports based on MS Dot Net versions earlier than 4.0 IFS Business Reporter client is based on MS Dot NET 4.0 version. Reports created with previous versions, Apps 7.5 or earlier, of IFS Business Analytics (as it was named before Apps 10) cannot be opened with the Apps 10 client version, e.g. with IFS Business Reporter, without generating errors. None Reports will not work.
IFS Business Reporter Report Upgrade Utility Yes Use the tool named IFS Business Reporter Report Upgrade Utility.

The IFS Business Reporter Report Upgrade Utility handles upgrade of IFS Business Reporter reports according to the following:
  1. Reports saved on disk
  2. Automatic retrieval, upgrade and replacement of:
    1. Saved and Published reports
    2. Reports available in the Info Services report archive
    3. Reports saved in Budget Process component (Budget Template and Archived Budget Templates).
    4. Reports in the IFS Business Reporter specific Export Archive
No N/A Short The tool does not handle automatic upgrade of IFS Business Reporter reports added as document revisions in Document Management. This must be handled manually.

More about how to handle upgrade of IFS Business Reporter reports is described in a special section dealing with the The IFS Business Reporter Report Upgrade Utility.
BACLI All All All All Post - Immediate Yes Upgrading IFS Business Reporter reports containing the IFS() function to use a new function that does not conflict with MS Excel IFS() function A new function named IFS() was introduced in the Office 365 version of Microsoft Excel 2016 from the February 2016 update. This function conflicts with a IFS Business Reporter specific function with the same name. Since there is one common version of IFS Business Reporter supporting all versions of Microsoft Excel, it was necessary to modify IFS Business Reporter as of Update 3 of IFS Applications 9. The modification means that all existing IFS Business Reporter reports have to be updated to be compatible with IFS Business Reporter version 3.2.8 and higher. None Reports will not work. IFS Business Reporter Report Upgrade Utility Yes A new function named IFS() was introduced in the Office 365 version of Microsoft Excel 2016 from the February 2016 update. This function conflicts with a IFS Business Reporter specific function with the same name. Since there is one common version of IFS Business Reporter supporting all versions of Microsoft Excel, it was necessary to modify IFS Business Reporter as of Update 3 of IFS Applications 9. The modification means that all existing IFS Business Reporter reports have to be updated to be compatible with IFS Business Reporter version 3.2.8 and higher. No N/A Short The tool does not handle automatic upgrade of IFS Business Reporter reports added as document revisions in Document Management. This must be handled manually.

More about how to handle upgrade of IFS Business Reporter reports is described in a special section dealing with the The IFS Business Reporter Report Upgrade Utility.
BACLI All All All All Post-Immediate Yes Mandatory action
All IFS Business Reporter reports have to be modified.
This action is necessary due to refactoring of IFS Business Reporter and the new rendering option for the BR Execution Server based on OpenXML SDK.
Use a local computer:
- Install the latest version of IFS Business Reporter (BR)
- Use BR to do a bulk download of all published and saved reports.
- Use BR to do a bulk republish/resave of all downloaded reports. The republishing/resaving will make sure that compression and sorting of data sets is handled correctly.
Necessary action for customers using IFS Business Reporter, upgrading from before IFS Applications 10 Update 7 to Update 7 or later.
Republishing/resaving will ensure that compression of data sets is enabled and that data sets are sorted propely.
None It must be made sure that all reports are using data set compression and that data sets are sorted propely to ensure correct rendering of IFS Business Reporter reports. N/A N/A
  • On a local computer
    • Install latest version of IFS Business Reporter  (BR) on a local computer
    • Use BR to perform a bulk download of all saved and published reports
    • Perform a bulk republish/resave of all downloaded reports to make sure that compression of data sets is enabled and that data sets are sorted correctly.


No N/A Medium  
BACLI All All All All Post-Immediate Yes If the Business Reporter Execution Server (BRES) is used:
- Make sure to stop the BRES service and to uninstall BRES.
- Install the latest version of IFS Business Reporter
- Uninstall IFS Business Reporter (the action is needed to fix registry entries)
- Install BRES.

 NOTE that from Apps 10 Upd7, BRES does not require IFS Business Reporter to be installed on the server/computer hosting BRES.
Necessary action for customers using IFS Business Reporter Execution Server,  upgrading from before IFS Applications 10 Update 7 to Update 7 or later. None Installation and then uninstallation of IFS Business Reporter is necessary to fix some registry entries, preventing an error to appear when installing the Execution Server. N/A N/A

On the BRES server/computer

  • Stop the BRES service and uninstall BRES
  • Install latest version of IFS Business Reporter (BR)
  • Uninstall BR (some registry entries will be fixed)
  • Install the latest version BRES

NOTE: IFS Business Reporter is no longer a prerequisite when running IFS Business Reporter Execution Server.

For more information, please refer to the Installation documentation.

No N/A Medium  
CALLC All All All All Post-Immediate Yes Update/Clear the REF_ID3 and REF_ID4 columns in the BusinessObject handover table where ref_id3, ref_id4 are referencing the Object Type and Category instead of Location and Location Info Address ID. If EQUIP is installed None An error can be raised when trying to create a service request from the case connected to an Equipment Object. POST_Callc_App10_UpdateBusinessObjectData.sql No       Short  
CBSINT N/A N/A All N/A Post - Anytime No During upgrade of the database, the Foundation1 user account for the CBS Server CBSSERVER is dropped and recreated as an Oracle user with all of the necessary permissions granted. If the user existed in the database prior to the upgrade, the password is preserved. If the user did not previously exist, it is created as a locked account with expired password. If your existing CBS Server installation is using a different user account, it is suggested that the new CBSSERVER user account be used. To prepare the account for use, execute the following commands in SQL*Plus, logged in as the IFS application owner.  When upgrading the Scheduling Server and Bridge from previous versions, uninstall the previous version first, then perform a fresh installation. Consult the Installation Guide for additional information.  None CBS Server account may not get created. N/A No /* CBS Account can be unlocked though below Sql run as APPOWNER */

ALTER USER CBSSERVER ACCOUNT UNLOCK;
ALTER USER CBSSERVER IDENTIFIED BY &new_password;

No N/A Short CBS consists of traditional IFS Client and PL/SQL files plus three win32 components: the Scheduling Server, Bridge and Interactive Client. The Scheduling Server and Interactive client are contained within the same file (schedserve.exe).
COST N/A N/A All N/A   No When calculating costs for every part on a site or copying costs for every part on a site the logic drops and recreates the index on PART_COST_BUCKET_TAB. This reduces execution times by approximately 20%. But when recreating the indexes Oracle needs a large temporary tablespace since the indexes are very large.   None N/A N/A No N/A No N/S Cannot Predict For a customer with approximately 100,000 inventory parts (table INVENTORY_PART_TAB), 1,000,000 structure rows (table MANUF_STRUCTURE_TAB) connected to one site, the size of the PART_COST BUCKET table for one cost set, would be approximately 3 million rows.

When calculating more than one cost set, the size grows linearly with the number of cost sets

CHMGMT All N/A N/A N/A Pre -Immediate Yes Data in MRB_DISPOSITION_TAB will be converted when upgrading from earlier version than Chmgmt 2.0.0. For each existing disposition line, up to three new disposition lines will be created depending on quantities approved, scrapped and still pending. If it is necessary to keep the data in the old format, please archive the table before upgrading. None Old data will not be preserved and it will be lost. N/A No   No N/A Cannot Predict  
CRM N/A All All N/A Post - Anytime No These scripts are used to import required FNDMIG jobs to migrate data entered by old "IFS Sales & Marketing" solution into "IFS Applications" (ENTERP and CRM).
If you want to migrate data entered by old “IFS Sales & Marketing” solution into "IFS Applications" (ENTERP and CRM)

When upgrading from IFS Applications 8 to IFS Applications 10, there will be Invalid Objects in Sales and Marketing objects due to dependencies to PRAGMA REFERENCES. This is because not availability of any upgrade support for obsolete Sales and Marketing components from IFS Applications 8 to IFS Applications 10. Therefore, before running Migration scripts, it is necessary to correct these PRAGMA reference issues in IFS Sales and Marketing objects.

Not available the data entered by old “IFS Sales & Marketing” solution into "IFS Applications" (ENTERP and CRM)
  1. POST_CRM_App9_ImportCRMAccountMigrationJobs.sql -
    Import required FNDMIG jobs used to migrate Account information
  2. POST_CRM_App9_ImportCRMContactMigrationJobs.sql -
    Import required FNDMIG jobs used to migrate Contact information
  3. POST_CRM_App9_ImportCRMActvityMigrationJobs.sql -
    Import required FNDMIG jobs used to migrate Activity information
  4. POST_CRM_App9_ImportCRMOpportunityMigrationJobs.sql - Import FNDMIG jobs used to migrate Opportunity information
  5. POST_CRM_App9_ImportCRMLeadMigrationJobs.sql -
    Import required FNDMIG jobs used to migrate Lead information
  6. POST_CRM_App9_ImportCRMCustomMigrationJobs.sql -
    Import required FNDMIG jobs used to migrate Custom objects
No Detail information/steps about the CRM migration jobs can be found here. No Yes Cannot Predict  
DEMAND All All All N/A Post - Anytime Yes To run the Demand Plan Server, the user “DEMANDSERVER” should be in Active & Unlocked state. Therefore, use this manual action to set the “DEMANDSERVER” user as an Active user or to change the password or to unlock the “DEMANDSERVER” oracle user. Only applicable if Demand Server is used and DEMANDSERVER user is Locked or Inactive. No If the DEMANDSERVER user is locked or inactive then this user cannot be used to run Demand Plan Server. N/A N/A Options available in Solution Manager, "Users" window can be used to manage these user credentials. No Yes Short  
DOCMAN All N/A N/A N/A Post - Anytime Yes Rename Incorrect File Names if Unicode characters are present.

More info: File names are incorrectly named when Unicode characters are present in doc_class, doc_no, doc_sheet, doc_rev. In some of these cases the name of the file that resides in the repository, does not match with edm_file_tab.file_name entry.
Only applicable if IFS Enterprise Explorer is used and if there are FTP/SHARED repositories defined in the DOCMAN setup. IFS Middleware Server must be up and running before executing the script. There maybe mismatches between the file names in the repository and the corresponding edm_file_tab.file_name entry (see Info 1 in Additional Information column).  POST_DOCMAN_App8_CleanIncorrectFileNames.sql
This script will try to correct incorrect file names by renaming to the corresponding edm_file_tab.file_name value.
No To execute the script:
  1. Make sure IFS Middleware Server is up and running.
  2. Locate the script and change the log file path to a preferred location (see Info 2).
  3. Execute the script as IFS Application Owner.
No No Cannot Predict Info 1: File names are incorrectly named when Unicode characters are present in doc_class, doc_no, doc_sheet, doc_rev. In some of these cases the name of the file that resides in the repository, does not match with edm_file_tab.file_name entry. This script will try to correct them by renaming to the corresponding edm_file_tab.file_name value.

Info 2: If a large number of information is spooled, there is a probability that the limit of the serveroutput (1,000,000) is reached and the file will end in an error. To remedy this you will have to retry the script (before each run back up any previously generated log files). This script is re-runnable.
DOCMAN All All N/A N/A Post - Immediate No Fix Etrage association XML file references with no checked in date Fix Etrage association XML file references with no checked in date to improve download performance.

Only applicable if there is a CAD integration
None   POST_DOCMAN_App8_CleanupCheckedInDateForEtrageFiles.sql No This script will look for and fix Etrage association XML file references with no checked in date. If an ORIGINAL file reference exists on the same document revision, its date will be used. If no ORIGINAL file reference exists it will be listed.


To execute the script:
  1. Locate the script and change the log file path to a preferred location (see Info 1).
  2. Execute the script as IFS Application Owner.
No No Short Info 1: If a large number of information is spooled, there is a probability that the limit of the serveroutput (1,000,000) is reached and the file will end in an error. To remedy this you will have to retry the script (before each run back up any previously generated log files). This script is re-runnable.
DOCMAN RTM - SP7 All N/A N/A Post - Immediate Yes List Doc Access Lines for removal where Person ID is set to  asterisk (*) None Upgrade should be completed. No invalid objects should exist in database. Incorrect/unwanted access levels for relevant documents are granted to all users. POST_DOCMAN_App8_ConditionallyDisplayDocAccessLines.sql
Generates a report that contains a list of Access Lines for removal.
Yes The script will identify
  • All the document access lines for users with person id *
  • (asterisk)
  • And then the access lines where * has edit access without the intention of the creator of the revision/sheet.

A report is generated in the specified location (default c:\accesslines_88317.html). Someone has to then decide whether the access line should be deleted or not.

To execute the script:
  1. Make sure the Upgrade is completed with ZERO invalid objects.
  2. If required, locate the script and change the location to where the report should be generated (fileName
  3. Execute the script as IFS Application Owner.
  4. Go through the generated report (accesslines_88317.html) and manually delete the records as needed.
Yes No
Short  
DOCMAN All All N/A N/A Post - Anytime No Re-enable Document Content Search domain The 'Document Content' search domain should exist. Execute only if the search domain needs to be re-enabled. None Cannot see summary of search results for Document Content POST_DOCMAN_App8_EnableDocumentContentSD.sql No Execute the script as IFS Application Owner. No No Cannot Predict  
DOCMAN RTM - SP6 N/A N/A N/A Post - Immediate Yes List Document Classes that have duplicate groups or persons in the Document Access Templates (for manual removal of duplicates) Access templates of some document classes may have duplicate groups or persons.

Starting from IFS Applications 7.5 SP6 adding duplicate records to the access templates is not allowed.
None Duplicate values/incorrect data continue to exist in the database. POST_DOCMAN_App8_ListDupDocClasses.sql
Lists document classes that have duplicate groups or persons (for evaluation and manual removal)
No To execute the script:
  1. Execute the script as IFS Application Owner.
  2. Carefully go through the generated log file (doc_classes_with_Dup_Acccess.log) and manually delete records as needed.
No No Cannot Predict  
DOCMAN All All RTM - UPD1 N/A Post - Immediate No List Person Group records where Person ID with asterisk (*) is included Only applicable if a person with the Person ID * (asterisk) has been added to Person Group.

Starting from IFS Applications 8 SP2 adding a person with Person ID * (asterisk) is not allowed.
Upgrade should be completed. No invalid objects should exist in database. Users can approve a step of the Document Approval Process even if they do not belong to the group of the approval step. This issue occurs if the person * (Person ID is asterisk) is in the group. POST_DOCMAN_App8_ListStarPersonGroups.sql
Lists person groups for modification.
No To execute the script:
  1. Execute the script as IFS Application Owner.
  2. Carefully go through the generated log file (group_id_with_Star_Person.log) and manually modify the records as needed (see Info 1).
Yes No Cannot Predict Info 1: If a large number of information is spooled, there is a probability that the limit of the serveroutput (1,000,000) is reached and the file will end in an error. To remedy this you will have to retry the script (before each run back up any previously generated log files). This script is re-runnable.
DOCMAN All N/A N/A N/A Post - Immediate Yes Correct the file names in the FTP server by relocating them to the correct directory File names are incorrectly named and placed when FTP repositories are defined with "Path" not ending with "/". For example if the path is /parent/child, then the file is placed in the folder ftp://:/parent as a file named child<filename>, it should instead be placed in the folder ftp://:/parent/child as <filename>. IFS Middleware Server must be up and running before executing the script. There should be at least one FTP repository defined in DOCMAN. Incorrect file names will continue to exist in DOCMAN. POST_DOCMAN_App8_RelocateStrandedFtpFiles.sql
This script will try to correct the file names in the FTP server by relocating them to the correct directory and renaming to the corresponding edm_file_tab.file_name value.
No Execute the script as IFS Application Owner. No No Cannot Predict  
DOCMAN All RTM - SP2 N/A N/A Post - Immediate Yes Set Date Connected values for all document connection records (doc_reference_object records) where Date Connected field is empty None POST_DOCMAN_App8_RepairDateConnectedInDocRefObjects.sql No Execute the script as IFS Application Owner. No No Cannot Predict
DOCMAN All N/A N/A N/A Post - Immediate Yes Correct FTP Null path File names are incorrectly named when FTP repositories are defined with "RepositoryAddres" but with out "Path".
  • In the above mentioned instance when files are checked in via FTS the actual file in repository does not match with edm_file_tab.file_name.
  • The file in repository has the following name: null<edm_file_tab.file_name>.
  • This script will try to correct them by renaming to the corresponding edm_file_tab.file_name value.
IFS Middleware Server must be up and running before executing the script. There should be at least one FTP repository defined in DOCMAN.   POST_DOCMAN_App8_RepairFtpNullPathProblem.sql
This script will try to correct them by renaming to the corresponding edm_file_tab.file_name value.
No Execute the script as IFS Application Owner. No No Cannot Predict  
DOCMAN All N/A N/A N/A Post - Anytime No Assign responsible person to documents that do not have an owner During an upgrade to IFS Applications 8, the Responsible Person field (doc_resp_sign in the database) changed meaning to the “owner” of the document and is populated with the person ID connected to the creator of the document. However, some of these creators has no person ID connected and hence this field becomes empty. This means that some documents have no proper owner. None Some documents will remain without owners. POST_DOCMAN_App8_UpdateDocResponsiblePerson.sql Yes Execute the script as IFS Application Owner. Yes No Short  
DOCMAN All All RTM - UPD5 N/A Post - Immediate No Repair Key Ref of missing Voucher Type Some of the object connections done prior to IFS Applications 75 SP3 thorough the windows Query Voucher Detail or Query Voucher Detail – GL were created with wrong KeyRef values where the keyref value could sometimes be missing the value of the VOUCHER_TYPE of the Voucher or the GL Voucher to which the object is connected. The purpose of this manual script is to handle those missing entries.     POST_DOCMAN_App9_RepairKeyRefOfMissingVoucherType.sql
This script writes all the object connections whose keyrefs are erroneous. i.e. the keyrefs that do not have Accounting_Year and Voucher_Type.
  This script writes all the object connections whose keyrefs are erroneous. i.e. the keyrefs that do not have Accounting_Year and Voucher_Type. Since its not possible to find the missing voucher type based on the available data (i.e. Company, Voucher_no and row_no) those erroneous keyrefs are inserted to a table called MISSING_VOU_DOC_CONN_TEMP_TAB and the user will have to find the missing voucher_types manually.

This table contains columns for
  1. The type of object connection missing.
  2. The lu_name for which the object is connected.
  3. The company fetched from the keyref
  4. The voucher_no fetched from the keyref
  5. The row_no fetched from the keyref
  6. The voucher_type into which the user must enter the missing voucher_type manually

After running this script once, it will fetch all the erroneous records and insert them into MISSING_VOU_DOC_CONN_TEMP_TAB

Then the user must fill in the voucher_type column with the correct voucher type by searching in the database or the application to find the correct voucher or voucher row to which the object should be attached. After that the user must run this script again to fix those object connections.

User may run this script multiple times until all the connections are fixed. After all the connections are fixed MISSING_VOU_DOC_CONN_TEMP_TAB will be dropped by this script.

Yes No Cannot Predict  
DOCMAN All All RTM - UPD3 N/A Post - Immediate No Update DOCMAN tables with new keys for OSHA LUs Only if OSHA component is installed. Only if OSHA component is installed. Database will contain incorrect document reference values. POST_DOCMAN_App9_RepairKeyRefOfOshaLUs.sql No Execute the script as IFS Application Owner. No Yes Short  
DOCMAN All All RTM - UPD3 N/A Post - Immediate No Update DOCMAN tables with new keys for PERSON LUs Only if PERSON component is installed. Only if PERSON component is installed. Database will contain incorrect document reference values. POST_DOCMAN_App9_RepairKeyRefOfPersonLUs.sql No Execute the script as IFS Application Owner. No Yes Short  
DOCMAN All All RTM - UPD3 N/A Post - Immediate No Update DOCMAN tables with new keys for PRJREP LUs Only if PRJREP component is installed. Only if PRJREP component is installed. Database will contain incorrect document reference values. POST_DOCMAN_App9_RepairKeyRefOfPrjrepLUs.sql No Execute the script as IFS Application Owner. No Yes Short  
DOCMAN All All RTM - UPD3 N/A Post - Immediate No Update DOCMAN tables with new keys for RECRUIT LUs Only if RECRUIT component is installed. Only if RECRUIT component is installed. Database will contain incorrect document reference values. POST_DOCMAN_App9_RepairKeyRefOfRecruitLUs.sql No Execute the script as IFS Application Owner. No Yes Short  
DOCMAN All All RTM - UPD3 N/A Post - Immediate No Update DOCMAN tables with new keys for STRACO LUs Only if STRACO component is installed. Only if STRACO component is installed. Database will contain incorrect document reference values. POST_DOCMAN_App9_RepairKeyRefOfStracoLUs.sql No Execute the script as IFS Application Owner. No Yes Short  
DOCMAN All All RTM - UPD3 N/A Post - Immediate No Update DOCMAN tables with new keys for TRNADM LUs Only if TRNADM component is installed. Only if TRNADM component is installed. Database will contain incorrect document reference values. POST_DOCMAN_App9_RepairKeyRefOfTrnadmLUs.sql No Execute the script as IFS Application Owner. No Yes Short  
ENTERP All All All All Post - Anytime No Update existing Companies It is recommended to perform an update of existing companies after an Upgrade. The reason for this is to facilitate addition of new basic data that is required for new functionality. None New basic data will not be available in existing companies. N/A N/A Updated via RMB Update Company in Application Base Setup / Enterprise / Company / Company window. More information can be found in the Company Template Guideline. Yes N/A Cannot Predict Updating an existing company actually means that new basic data is added to a Logical Unit. It does not mean that existing basic data is modified.
ENTERP All All N/A N/A Pre - Anytime No Check whether all companies have a country code as well as a default language code defined.   None

During the upgrade the following will happen,

  1. For a company that has no Country defined
    1. The addresses for each company will be used to get hold of a country code for the company. Addresses are scanned with respect to the following address type order; DELIVERY, INVOICE, VISIT, PAY and then all other address types.
    2. If no country code is found among the addresses, the country code XX will be used.
    3. The company's country code is updated.
    4. The country code in the clients will be displayed as XXXXXXXXXX (corresponding to the database value XX)
  2. For a company that has no Default Language defined, the language code en will be defined.
  3. Each Site will get a Country defined according to the country code of the associated company
N/A N/A Check the following forms to make sure that the country as well as the default language are correctly defined
  1. Company window, General tab (IFS EE address=ifsapf:frmCompany)
    1. Check value of Country field
    2. Check value of default language
  2. Sites window (IFS EE address=ifsapf:tbwCompanySite)
    1. Check value of Country column
  3. Taxation Liability Countries detail in Company / Invoice / Tax Information tab (IFS EE address=ifsapf:frmCompany)
    1. Check value of Country column
 
No N/A Short  
ENTERP All All N/A N/A Post - Anytime No Spool all the records to the file MismatchingFirstMiddleLastNamesOfPerson.log where concatenation of first, middle, last names not equals to the name value.   None There can be records exist in the Application where Full Name and the concatenation of First, Middle and Last names are not equal.
 
POST_Enterp_App9_MismatchingFirstMiddleLastNamesOfPerson.sql No
  1. Start the Command Prompt. Move to the directory where this file is located. Issue the command:
    sqlplus <appowner>/<appowner>@<database> @POST_Enterp_App9_MismatchingFirstMiddleLastNamesOfPerson.sql
  2. Go through the records in the created log file MismatchingFirstMiddleLastNamesOfPerson.log
  3. Update records via Application Base Setup/Enterprise/Person/Person form

 

Yes N/A Short  
ENTERP N/A N/A UPD10 RTM - UPD1 Post - Anytime Yes The Personal Data Management system is designed to help customers comply with personal data protection regulations. The purpose of this system is to remove or anonymize any personal data for which there is no valid legal basis for processing. Due to a few missing configuration entries in the Personal Data Management system, some personal address details could avoid anonymization despite the data clean-up.
The script shows the list of persons for whom there is a risk that their detailed personal address has not been successfully anonymized by the data cleanup procedure. In addition, if the RUN_CLEANUP is set to YES, the script will not only show the list of affected persons but also refresh the last update of data processing purposes and trigger a relevant cleanup action.
This script is only applicable if the Personal Data Management system is being used and the Detailed Address setting has been used in the Address Setup per Country window. Otherwise there is no need to run the script, unless the Data Protection Officer wants to ensure that there the is no unauthorized personal address information stored in the system. LCS Patch 141382 installed. If the script is not executed by the customer who is legally obligated (e.g. by GDPR) to dispose of personal data, there is a risk that the unauthorized details of person’s personal address will remain in the system violating the law. POST_Enterp_App9_PersonDetailedAddressCleanup.sql Yes To execute the script:
1. Locate the script and change the log file path to a preferred location.
2. Set RUN_CLEANUP to one of the following values:
- 'YES' - if you want to report inconsistency in personal address detailed and run the cleanup
- 'NO' - if you want to report inconsistency in personal address detailed and do not want to run the cleanup
2. Execute the script as Application User with sufficient access rights.
Yes N/A Cannot Predict  
ENTERP All All N/A N/A Pre - Anytime No In APP9, the Name of the Person is comprised of First name, Middle name and Last name. However in the earlier versions, there is no breakdown of First name, Middle name and Last name for the Person Name. Therefore, when the system is upgraded, Person Name is breakdown to First Name, Middle Name and Last Name This activity should be performed when Person Name is not aligned with the format First name, Middle name and Last name.
Scenario 1:
The Name of the Person is entered in the APP75 environment is: Alain Pascal Prost
Alain is the First Name
Pascal is the Middle Name
Prost is the Last Name
Before you upgrade to APP9 or later versions, you have to make sure the Name should in the format of First Name, Middle Name and Last Name.
So in the above scenario, no change needed since the Name of the Person is in the correct format of First Name, Middle Name and Last Name.

Scenario 2:
The Name of the Person is entered in the APP75 environment is: Mansel Nigel Ernest
Nigel is the First Name
Ernest is the Middle Name
Mansel is the Last Name
Before you upgrade to APP9 or later versions, you have to make sure the Name should in the format of First Name, Middle Name and Last Name.
So in the above scenario, the Name of the Person should be changed to the correct format of First Name, Middle Name and Last Name which would be Nigel Ernest Mansel.
None Person Name might not be aligned to the First name, Middle name and Last name. N/A N/A Go to Person Window and make sure the Name field is aligned with First name, Middle name and Last name Yes N/A Short  
FINCFA All All N/A N/A Post - Immediate Yes In table cfa_manual_cash_flow_tab will only records with a manually defined cash flow source and a manually defined cash flow type be handled automatically in the upgrade. For other records (with a predefined cash flow source and/or a predefined cash flow type) the cash flow source and cash flow type need to be changed manually after the upgrade.

This is only applicable for customers who have set up Manual Cash Flows (meaning having information in windows Manual Cash Flow - Single and/or Manual Cash Flow – Repetitive) with predefined cash flow source and/or predefined cash flow type. Meaning if source_id in table cfa_manual_cash_flow_tab is having the values ('CUSTOMER ORDER','PURCHASE ORDER','PAYMENT') or cash_flow_type_id in table cfa_manual_cash_flow_tab is having the values
('IFS_CUSINV','IFS_CUSTORD','IFS_CUSONA','IFS_SUPINV','IFS_PURORD',
'IFS_SUPONA','IFS_FINPAY','IFS_FXFORWARD','IFS_FX','IFS_VAT',
'IFS_OTHER_PAYMENTS','IFS_SALARIES','IFS_TAXES','IFS_CUSBOE',
'IFS_SUPBOE','IFS_CUSCHK','IFS_SUPCHK','IFS_BADDEBT','IFS_CUSVAL').
 

None Data inconsistency in Cash Flow Analysis N/A N/A
  1. Use Manual Cash Flow - Single and Manual Cash Flow - Repetitive windows to find entries which meets the functional condition for execution.
  2. Change all cash flow sources under this category to 'MANUAL' (which is IFS system defined manual cash flow source). Alternatively define a new cash flow source and change all cash flow sources to newly created cash flow source. Affects column source_id in table cfa_manual_cash_flow_tab.
  3. Change all cash flow types under this category to one of the system defined cash flow types ('IFS_FINPAY','IFS_FXFORWARD','IFS_FX','IFS_OTHER_PAYMENTS','IFS_SALARIES', 'IFS_TAXES'). Alternatively define a new cash flow type and change all cash flow types to newly created cash flow type. Affects column cash_flow_type_id in table cfa_manual_cash_flow_tab.
Yes N/A Cannot Predict From this upgrade it has introduced a parent child relationship between cash flow sources and cash flow types, and improved validations in the logic
FINCFA All All N/A N/A Post - Immediate Yes Order cash flow data after the upgrade before ordering Cash Flow reports   None Data inconsistency in Cash Flow Analysis N/A N/A
  1. Navigate to Cash Flow Analysis Snapshot window.
  2. RMB on selected Cash Flow Analysis ID and select Analysis Details Cash Flow Source...
  3. Select desired Cash Flow Source ID’s to order Cash Flow Analysis Snapshot.
  4. Check Include in Cash Flow Analysis check box for selected entries and save.
  5. RMB on Analysis Details Cash Flow Source window header and select Order.
Yes N/A Cannot Predict  
FNDBAS All N/A N/A N/A Post - Anytime No Clean Language_Sys_Tab by deleting Centura Client (SO) and Rich Web Client (RWC) attributes. This is only applicatble if the Centura Client has been used None Obsolete data in Language_Sys_Tab POST_FNDBAS_APP8_Clean_LanguageSysTab.sql No   No Yes Short  
FNDBAS All N/A N/A N/A Post - Anytime No This script will delete all old Centura profile values in all user profiles. This is only applicatble if the Centura Client has been used None Old Centura profile values in all user profiles POST_FNDBAS_APP8_DeleteCenturaProfileValues.sql No Consider migrating Saved Queries to Saved Searches using Migrate Saved Queries window in IFS Enterprise Explorer before executing this script. No Yes Short  
FNDBAS All All N/A N/A Post - Anytime No This script will delete old Database Alert Log Categories: 'IFS Sessions', 'Sessions' and 'Intrusions'. If there is no need to keep the old records, Alert Log Categories: 'IFS Sessions', 'Sessions' and 'Intrusions'. None Old Database Alert Log Categories: 'IFS Sessions', 'Sessions' and 'Intrusions'. POST_FNDBAS_APP9_RemoveOldServerLogs.sql No   No Yes Short  
FNDBAS All All RTM Only N/A Post - Anytime No This script will delete Event Actions which uses the following obsolete action types:‘SMS_Message','Shell Command'. If action trypes: SMS Message and Shell Command are used None Obsolete action types:‘SMS_Message','Shell Command'. POST_FNDBAS_APP9_RemoveOldEventActions.sql No   No Yes Short  
FNDBAS All All N/A N/A Post - Anytime No This script will change module name values with 'Temporary Description' and ' name' to correct values. Translated name values for modules shown as 'Temporary Description' None Module name values with 'Temporary Description' and ' name' to correct values. POST_FNDBAS_FixModuleBasicDataTranslations.sql No   No Yes Short  
FNDBAS All All N/A N/A Pre - Anytime Yes This script provides a list of Oracle Users in the database that are not connected with the Fnd User of the same name. These Oracle Users will be connected with their respective Fnd Users during the upgrade. To find Oracle users in the database who are not connected with the Fnd User of the same name. None Oracle Users who are not connected with the Fnd User of the same name will be connected with their respective Fnd Users during the upgrade. PRE_FNDBAS_App9_ListUnconnectedOracleUsers.sql No If a particular Oracle User in this list should not be connected with the respective Fnd User you have three options:
1. Delete the Oracle Account but keep the Fnd User: A fresh Oracle Account will then be created during the upgrade.
2. Delete the Fnd User but keep the Oracle Account: The Oracle Account will not be affected by the upgrade.
3. Delete both
No Yes Short  
FNDBAS All All N/A N/A Post - Immediate No This will move obsolete personal messages into tasks.

Note:
- Event actions rules for personal messages are not migrated, only already processed messages are.
- Messages with the obsolete persons will be deleted.

This is only applicatble if obsolete personal messages exist None Personal messages related to users will be not shown POST_FNDBAS_APP9_MovePersonalMessages.sql No   No Yes Short  
FNDBAS All N/A N/A N/A Pre - Anytime No This will update rowkey columns with data. Follow this link for more details. Please follow this link Please follow this link Please follow this link PRE_FNDBAS_UpdateRowkeyColumns.sql No Please follow this link No No    
FNDBAS N/A N/A N/A UPD8 - Any Post - Anytime No This will list the currently defined Object Connections that require manual reconfiguration due to using the now obsolete service_list = *.
Please follow this link None Improved performance in Aurena pages (initial load time) that uses the connected Object Connection entity (Logical Unit) as data source. POST_FNDBAS_APP10_ListIllegalObjectConnections.sql No To execute the script follow the steps below:
  1. Login to the Oracle Database as IFSAPP
  2. Execute the POST_FNDBAS_APP10_ListIllegalObjectConnections.sql file located at ..\fndbas\manualdeploy\database\fndbas\
  3. The script, once executed, will list all Object Connections entries thare all invalid and that require re-configuration. The re-configuration done by redefining the service_list = * with proper service name(s), separated with ^
Yes No Short Each service name will require processing time when corresponding Aurena page is loaded and its data is fetched, for why defining the service_list with only the needed and valid service names is of importance.
Only connect service names that have a certain purpose and adds value to the existing Business Logic.
FNDMIG All All N/A N/A Post - Anytime No The Quick_Report_OUT Procedure is obsolete. It is recommended to use the built in Import/Export functionality in Quick Report. This script will remove all data related to any FNDMIG Quick Report Out Job. This is only applicatble if FNDMIG Quick Report Out is used. None Obsolete data related to FNDMIG Quick Report Out Job. POST_FNDMIG_APP9_RemoveProcQuickReportOut.sql No   No Yes Short  
FNDMIG All All N/A N/A Post - Anytime No Corrects the execution plan on scheduled migration jobs which had an invalid date time format. Applicable only if the Customer has a local which uses “.” instead of “:” as time separators (i.e time is displayed as 12.00 instead of 12:00). None Incorrect time formats. This can cause issues when populating the Scheduled Database Task window in Solution Manager. POST_FNDMIG_App9_Repair_Currupted_Schedules.sql No After executing the script review and re-enable scheduled task listed in ChangedSchedulesLog.log. No Yes Short  
GENLED All All N/A N/A Pre - Immediate Yes Before upgrading, check whether there is any remaining parallel currency balance in the General Ledger, i.e. the debit balance in parallel currency for all accounts does not match the credit balance in parallel currency for all accounts. This is only applicable if your company/companies use Parallel Currency functionality. None Imbalance in Parallel Currency , hence cannot run Year End functionality. N/A N/A Make a note of the balance in Parallel Currency so that this could be compared with the balances after the upgrade. Yes N/A Cannot Predict  
GENLED All All N/A N/A Post - Immediate Yes Resolve imbalance in Parallel Currency found in Pre - Immediate step. This is only applicable if your company/companies use Parallel Currency functionality. As mentioned in the pre step, if there is any remaining parallel currency balance in the General Ledger, i.e. the debit balance in parallel currency for all accounts does not match the credit balance in parallel currency for all accounts, this must be adjusted. As this imbalance has been accumulated over the years, it is impossible to sort out where it originates from, so we assume that the Income Statement is correct None Imbalance in Parallel Currency , hence cannot run Year End functionality. N/A N/A
  1. Calculate the current difference in parallel currency in the Income Statement by comparing revenue accounts with cost accounts (= current profit/loss)
  2. Calculate the current difference in parallel currency in the Balance Sheet by comparing asset accounts with liability accounts.
  3. Deduct the Income Statement difference from the Balance Sheet difference. The remaining amount should correspond to the total debit/credit difference in parallel currency for all accounts.
  4. Using a new Asset or Liability account (depending on the sign of the difference), post the difference in parallel currency only in a manual voucher. Counter post the amount to a new account of logical account type Statistics.
  5. Update the General Ledger

The total balance in parallel currency for all accounts except the statistical account should now be zero, i.e. debit and credit balance should be equal. Also, The difference between all assets and liability accounts should be equal to the difference between all revenue and cost accounts, but with different sign (= current profit/loss).

Yes N/A Cannot Predict  
INTLED All All All All Pre - Immediate Yes Update vouchers in Internal Ledger hold table to Internal Ledger None None Inconsistent data in the Internal Ledger. This will affect Balances as well. N/A N/A Before upgrading Intled make sure that all vouchers in the Internal Ledger hold tables, i.e. tables internal_hold_voucher_tab and internal_hold_voucher_row_tab, are updated to the Internal Ledger. Yes N/A Cannot Predict  
INTLED All All N/A N/A Pre - Immediate Yes Before upgrading, check whether there is any remaining parallel currency balance in the Internal Ledger(s), i.e. the debit balance in parallel currency for all accounts does not match the credit balance in parallel currency for all accounts. This is only applicable if your company/companies use Parallel Currency functionality. None Imbalance in Parallel Currency , hence cannot run Year End functionality. N/A N/A   Yes N/A Cannot Predict  
INTLED All All N/A N/A Post - Immediate Yes Resolve Currency imbalance found in Pre - Immediate step. This is only applicable if your company/companies use Parallel Currency functionality. As mentioned in the pre step, if there is any remaining parallel currency balance in the Internal Ledger, i.e. the debit balance in parallel currency for all accounts does not match the credit balance in parallel currency for all accounts, this must be adjusted. As this imbalance has been accumulated over the years, it is impossible to sort out where it originates from, so we assume that the Income Statement is correct None Imbalance in Parallel Currency , hence cannot run Year End functionality. N/A N/A Follow these steps for each Internal Ledger
  1. Calculate the current difference in parallel currency in the Income Statement by comparing revenue accounts with cost accounts (= current profit/loss)
  2. Calculate the current difference in parallel currency in the Balance Sheet by comparing asset accounts with liability accounts.
  3. Deduct the Income Statement difference from the Balance Sheet difference. The remaining amount should correspond to the total debit/credit difference in parallel currency for all accounts.
  4. Using a new Asset or Liability account (depending on the sign of the difference), post the difference in parallel currency only in a manual voucher. Counter post the amount to a new account of logical account type Statistics.
  5. Update the Internal Ledger

The total balance in parallel currency for all accounts except the statistical account should now be zero, i.e. debit and credit balance should be equal. Also, The difference between all assets and liability accounts should be equal to the difference between all revenue and cost accounts, but with different sign (= current profit/loss).

Yes N/A Cannot Predict  
INVENT All N/A N/A N/A Pre - Immediate and
Post - Immediate
Yes Move records in 'Standard Classification' into 'Classification Standard' with a valid Classification unit of measure Only applicable for customers who want to carry forward the Standard Classification data stored in Assortment window in App75, with Classification Standard functionality introduced in App8. None The data in ‘Standard Classification’ field of Assortment window in App75 will be obsolete after the upgrade. N/A N/A In Assortment window (frmAssortmentStructure), 'Node Information' tab, 'Standard Classification' field is not available from APP8 onwards. Therefore, if there are records existing in 'Standard Classification' field in APP7.5 (Pre - Immediate), you should manually update them to the new field 'Classification Standard' with a valid Classification unit of measure (Post - Immediate). Otherwise, records in the 'Standard Classification' field will obsolete. Yes Yes Short A valid 'Classification Standard' should be connected to the Assortment header. According to the 'Classification Standard' you can enter Classification part number & Classification unit of measure to the connected parts in the assortment.
INVOIC All All All N/A Post - Immediate No Enable Surcharge functionality This is applicable only for customers who are using surcharge functionality None Surcharge functionality cannot be used N/A N/A
  1. Run following query to find the surcharge customers after the upgrade

    SELECT *
    FROM customer_delivery_tax_info_tab cd
    WHERE cd.tax_liability IN (SELECT liability_type
                               FROM tax_liability_tab
                               WHERE taxable = 'RDE')

  2. Run following query to find surcharge tax codes after the upgrade.

    SELECT d.company, d.att_fee_code, d.fee_code
    FROM statutory_fee_detail_1000 d, statutory_fee_tab s
    WHERE d.company = s.company
    AND d.att_fee_code = s.fee_code
    AND s.fee_type_temp = 'RDE'
  3. Insert above tax codes to Customer/Address/Delivery Tax Information/Supply Country/Taxes tab (meaning table customer_delivery_fee_code_tab) to enable surcharge functionality
Yes N/A Cannot Predict  
ORDER All All N/A N/A Pre - Immediate Yes For future reference, extract information of return material authorization lines where the parts have been reported as arrived but have not yet been moved to inventory or scrapped. Only applicable if backup is needed for return material authorization lines where the parts have been reported as arrived but have not yet been moved to inventory or scrapped to be able to physically identify such quantity. None

There can be physically received quantity that exists in unknown locations, that have not been moved to inventory locations or scrapped, and such quantity will not be possible to identify after the upgrade.

N/A N/A

In order to backup of such Return Martial Authorization lines, it is advisable to run the below advanced query before the upgrade.

  1. Connect all sites to gather all the RMA data that is expected by running this advanced query.

  2. Go to the Return Material Authorization Lines window, (IFS Enterprise Explorer address= ifsapf:tbwReturnMaterialOverview). Use Search, Advanced, SQL and use the following text to populate data.

    (NVL(QTY_RECEIVED,0) * CONV_FACTOR / INVERTED_CONV_FACTOR) > NVL(QTY_RETURNED_INV, 0) + NVL(QTY_SCRAPPED, 0)
    AND PART_NO IS NOT NULL

  3. After populating, data can be exported for future reference.

No Yes Short Before APP9, for inventory parts it was possible to receive quantity without moving to inventory or performing scrap. This means the particular quantity had physically arrived, but had not yet been moved to inventory or scrapped. If such quantity has arrived then the Total Qty Received field on the RMA line had been updated but the Returned Inv Qty and Scrapped Qty had not been updated since no quantity had been moved to inventory or scrapped physically.
After upgrade the Total Qty Received will be equal to Returned Inv Qty + Scrapped Qty. Therefore any quantity that had arrived but had not yet been moved to inventory or scrapped will not be shown in the Total Qty Received field.
The extracted information will be used for reference purpose to know if there is any discrepancy of quantity arrived but have not yet been moved to inventory or scrapped so such discrepancy should be physically identified.
If the RMA line is customer order connected, then the returned quantity on customer order line has to be manually set on the customer_order_line_tab to be equal to Total Qty Received field value of all the connected RMA lines.
ORDER All N/A N/A N/A Post - Immediate Yes

Update the weight unit of measure (Weight UoM) not expressed in (“kg” or "lb" for U.S.) in the system after the upgrade. The customers who use ‘kg’ as the weight UoM will have no discrepancy in their data after the upgrade. If other weight UoM is used throughout the application, correct the weight UoM.

Only applicable:
1. If weight unit of measure (Weight UoM) not expressed in “kg” in package type and Pallet type
2. If there were different weights for a particular sales part in different sites,
None Incorrect weight unit of measure (Weight UoM) after the upgrade. But, for those who use ‘kg’ as the weight UoM will have no discrepancy. N/A N/A
  1. Since the weight in Applications 7.5 does not refer to any UoM, it was assumed that it was expressed in "kg". If this is not the case (e.g. the weight was assumed to be in lb(U.S.) before the upgrade), the weight UoM needs to be updated manually after the upgrade.
  2. If there were different weights for a particular sales part in different sites, the maximum value was used as the weight in part catalog. In such sales part records exist the gross weight will have to be manually verified after the upgrade.
Yes Yes Cannot Predict  
ORDER All N/A N/A N/A Post - Immediate Yes List of Charge type posting control setup for the control types C62 and C74 that needs to be re-setup in Posting Control Details, Posting Control Combination Details, Posting Control Details Specification and Posting Control Combination Details Specification. Only applicable when the using the charge type posting control types C62 and C74 have been used prior to the upgrade. None If posting control data is not re-setup, it will result in a posting error in the customer order flow when a customer invoice is posted. E.g. “Value is missing or has an invalid time interval for posting type M68 control type C62 code part x”. Use the generated list and re-setup the posting control for the affected data in IFS Applications in Posting Control Details, Posting Control Combination Details, Posting Control Details Specification and Posting Control Combination Details Specification. POST_ORDER_App8_AffectedChargeTypeDataList.sql No
  1. Execute the script as IFS Application Owner.
  2.  Check the log file,  POST_ORDER_APP8_AffectedChargeTypeDataList.log for affected data.
  3. Re-setup the posting control data in Posting Control Details, Posting Control Combination Details, Posting Control Details Specification and Posting Control Combination Details Specification.
Yes Yes Short The purpose of the manual script is to list the charge type posting control setup for the control types C62 and C74 that needs to be re-setup in Posting Control Details, Posting Control Combination Details, Posting Control Details Specification and Posting Control Combination Details Specification. Check the log file POST_ORDER_APP8_AffectedChargeTypeDataList.log for the affected data.
ORDER All N/A N/A N/A Post - Immediate Yes Update Currency rate for existing Customer Order Charges, Sales Quotation Charges and RMA charges Only applicable when below error message is raised when executing Automatic Post file: POST_ORDER_V1400_UpdateChargesCurrencyRate.sql

"The currency code ZZZ is not valid in the currency rates for company XX and currency type YY"
None Invalid Currency rates for existing Customer Order Charges, Sales Quotation Charges and RMA Charges. N/A N/A
  1. Check error message "The currency code ZZZ is not valid in the currency rates for company XX and currency type YY" is raised when executing Automatic Post file POST_ORDER_V1400_UpdateChargesCurrencyRate.sql
  2. Define currency rates correctly in IFS Applications/Accounting Rules for the currency rate type given in the error message in the given company.
  3. Re-run the above script
Yes Yes Short

This script deploys automatically during the installation and. In 1400.upg the currency rate column will be added to the Customer_Order_Charge_Tab, Order_Quotation_Charge_Tab and Return_Material_Charge_Tab as mandatory columns with the value of "-1" The purpose of this script is to replace above dummy value with a valid currency rate fetched from Accounting Rules. A valid currency rate is fetched based on the currency rate types defined for the company (or default for the customer) and the currency code on the relevant customer order, sales quotation or RMA headers. However, in case the system fails to retrieve a proper currency rate (maybe due to deleted or missing currency types/rates for a date), as a result earlier mention error message is raised.

ORDER All N/A N/A N/A Post-Any Yes This is regarding as a part of the implementation done to remove the requirement that the user should be connected to all companies when aggregating customer order statistics. With this new implementation, the aggregations will be defined per company. The aggregations existed before the upgrade were created per company. Only the aggregated results of aggregations where Company, Site or RMA No defined as dimensions were distributed among the newly created aggregations per company. The remaining aggregated results and their logs were moved into temporary tables.
When you have created customer order data aggregations in App75. None Created statistics/aggregations could not be used for further analysis/development. N/A N/A We’ve created some temporary tables to support the data upgrade, How they can be used to update the real data, how to drop them if they are no longer needed and how to recover old data if no such data upgrade is done based on the data exists in the temporary tables are explained below.

In order to support the CO Statistics Aggregation at company level, the company was defined as a part of the primary key in ord_agg_stat_tab, ord_agg_stat_dimension_tab, ord_agg_stat_column_tab, cust_ord_invo_stat_agg_tab, delivery_quality_stat_agg_tab and ord_agg_stat_log_tab. In tables cust_ord_invo_stat_agg_tab and delivery_quality_stat_agg_tab, a value for company could be found for the aggregated results, (if company was defined as a dimension in the aggregation. OR if the contract or return_no was defined as dimensions, a value for company could be retrieved.)

For the other aggregations, the data in tables cust_ord_invo_stat_agg_tab, delivery_quality_stat_agg_tab were moved into the temporary tables cust_ord_invo_stat_agg_tmp_tab, delivery_qty_stat_agg_tmp_tab and deleted from the original tables to make the company a key in these tables.
Also the log records for these aggregations were moved into the temporary table ord_agg_stat_log_tmp_tab and deleted from the original table to make company a key.

You might be able to insert data into the original tables using the data exists in the temporary tables. When doing such upgrade, it should be always possible to find a value for company for all the records belonging to a specific aggregation.If that can be done; the log record should also be inserted into the original table for a specific company, aggregate_id combination by using the details of the log records in the temporary table for a specific aggregation where status is COMPLETE.

If no such upgrade is done, in order to recover the old data for the aggregations where company, contract or return_no not defined as dimensions, you should run the statistics aggregation process in the application for a specific company, aggregate_id combination. Then the aggregations will be generated based on the data exists in detail statistics tables. If these temporary tables are no longer needed you can use the code exists in Ordercl.sql to drop them.
Yes Yes Cannot Predict  
ORDER All All All N/A Post - Immediate Yes The post script POST_Order_ConvertOrderQuotationProspect.sql creates “Prospect” type customers with customer related detail entered in prospect Sales Quotations. The address detail entered in the ‘Customer Address’ of the Sales window will be transferred as delivery and document addresses of the new prospect customers for valid addresses. After the upgrade, the table quote_prospect_customer_1410 will have two columns invalid_del_addr_upg and invalid_doc_addr_upp with the value ‘TRUE’, for addresses that were NOT transferred because they were invalid as per the ‘Address Setup per Country’ window. Before Application 9, Prospect sales quotations were created without a customer. The address detail of the customer was saved in QUOTE_PROSPECT_CUSTOMER_TAB and before App8, these addresses were not validated against "Address Setup per Country" entries per country. With this script, when upgrade to Application 9, a customer of Prospect category is created and connected to the sales quotation. When customer addresses are created with old data, address validation errors are fired if a particular country need validation as per Address Setup per Country window, but old sales quotation has invalid address data. None A prospect with an incomplete address will not have the address created after the upgrade. The address needs to be entered again if the intention is to use it. N/A N/A
  1. After the upgrade, the table quote_prospect_customer_1410 will have two columns invalid_del_addr_upg and invalid_doc_addr_upg with values ‘TRUE’ or ‘FALSE’. Therefore, the customers created without the address detail from prospect sales quotations can be quarried  with the following SQL statement:
    SELECT q.customer_no, q.quotation_no, 'Delivery Address' error_occured_in, p.del_name name, p.del_country_code country_code, p.del_address1 address1, p.del_address2 address2, p.del_zip_code zip_code, p.del_city city, p.del_county county, p.del_state state
      FROM order_quotation_tab q, quote_prospect_customer_1410 p
    WHERE p.invalid_del_addr_upg = 'TRUE'
      AND p.quotation_no = q.quotation_no
    UNION
    SELECT q.customer_no, q.quotation_no, 'Document Address' error_occured_in, p.doc_name name, p.doc_country_code country_code, p.doc_address1 address1, p.doc_address2 address2, p.doc_zip_code zip_code, p.doc_city city, p.doc_county county, p.doc_state state
      FROM order_quotation_tab q, quote_prospect_customer_1410 p
    WHERE p.invalid_doc_addr_upg = 'TRUE'
      AND p.quotation_no = q.quotation_no;
  2. The results from this query for the quotation address data that are invalid must be inspected and decide what action is needed. i.e. Either to enter addresses for a newly created prospect customers (fetched in customer_no column), with the old data fetched in rest of the columns, or ignore if any address data is no more required.
Yes Yes Short This enhancement is done in LCS Bug 136492.
PARTCA All N/A N/A N/A Post - Immediate Yes Analysis of net weight discrepancies between different sites for part numbers. Only applicable if a certain part numbers might have had different net weights on different sites. This script helps to find out about that so that the correct weight can be set on the Master Part. None No awareness about net weight discrepancy between different sites. POST_PARTCA_App8_PromptDifferntNetWeights.sql No
  1. Execute the script as IFS Application Owner.
  2. Check the spool file, PromptDifferntNetWeights.log for the affected data.
Yes Yes Short The column WEIGHT_NET in the PART_CATALOG_TAB was introduced by the APP8 release and in the 1300.upg the column WEIGHT_NET is updated with the maximum net weight value from the INVENTORY_PART_TAB with respective to the PART_NO regardless of the site, which means there can be situations where the same PART_NO can have different net weight amounts. Therefore users can use this script to get the details of the inventory parts having different net weights in different sites.
PAYLED All All All All Pre - Immediate Yes Check whether all the necessary payment related transactions are completed   None Inconsistency in Payment data and might cause installation errors during the Upgrade N/A N/A
  1. Reminders – Before upgrading Payled please make sure that all reminder proposals are fully processed or removed from the application, i.e. tables REMINDER_PROPOSAL_TAB and REMINDER_ITEMS_TAB are empty.
  2. External Payments – Before upgrading Payled please make sure that all external payments are fully processed, i.e. All records in table Ext_Payment_Head_Tab should have the rowstate = 'Used'. (SQL to list external payments which are not fully processed: SELECT * from Ext_Payment_Head_Tab where rowstate <> 'Used'). You can also use the External Payments window (IFS EE address=ifsapf:tbwExtPaymentHead) to check the external payments. This preparation is needed because the new field payment method of external payments cannot be updated if the external file has been removed from the application or if external payments were created manually without file import.
  3. Mixed Payments – Before upgrading Payled please make sure that all mixed payments are fully processed, i.e. the table Mixed_Payment_Tab should not contain any record with rowstate = 'NotApproved'.(SQL to list mixed payments which are not fully processed: SELECT * from Mixed_Payment_Tab where rowstate = 'NotApproved'). You can also use the Mixed Payments Analysis window (IFS EE address= ifsapf:tbwOverviewMixedPayment) to check the mixed payments.
Yes No Cannot Predict  
PCMSTD All All All N/A Pre - Anytime No Update existing Material and/or Tool Facility lines that are not connected to an Operation Upgrading to IFS Applications 10 requires all Material and Tool Facility lines to be connected to an operation in Standard Job. This is because Material and Tool Facility (as a Resource) will always be created under a Work List in IFS Applications 10.

In case there are unconnected Material and Tool Facility lines, the upgrade will create an extra Work List line to connect all those Material and Tool Facility records. Exception; if there is only one Work List available, then the upgrade will connect all Material and Tool Facility to that Work List.

If this is not what you want and you need all Material and Tool Facility to be connected to a specific Work List then you need to connect all Material and Tool Facility to an operation line before the upgrade.
None Upgrade will create an extra Work List line to connect all unconnected Material and Tool Facility records. N/A N/A Query for the relevant records and perform the necessary data updates. No No Cannot Predict  
PCMSTD All All All N/A Post - Immediate Yes Update Resource Group Column if NULL values are found There may be records created without a resource group in Task Template/Work List/Resources tab. You are advised to update the Resource Group column if null values are found. None If records are not updated, errors will be raised when a PM or WO is generated using these task templates. POST_PCMSTD_App10_TaskTempResourceDemandsWithoutGroup.sql No Use the SQL query provided in the script to find such task templates that require modification.

Note: The script is for querying purposes only and does not modify data.

No Yes Short  
PDBCW N/A N/A N/A N/A Post - Anytime No Insert Optional Basic Data related to NORSOK Standards Optional basic data to be included when PDBCW is installed. None   POST_Pdbcw_App9_PlantDesignInsertOptionalBasicData.sql No Execute the script as IFS Application Owner. No No Short  
PERSON N/A N/A N/A RTM-UPD4 Post - Anytime No Inserting missing default jobs for the positions.

More Info: during upgrade to App10, if one of versions RTM-Upd4 was used, default jobs for positions were not migrated to their new table (job_position_tab).
This scripts moves data from obsolete job_id_700 column to its target location.
None None Default jobs for the positions will not be migrated from the database which was upgraded to App10. POST_Person_App10_DefaultJobPosition.sql No To execute the script follow the steps below:
1.Login to the Oracle Database as IFS Application Owner
2.Execute the POST_Person_App10_DefaultJobPosition.sql file located at ..\person\manualdeploy\database\person\.
3. Read the result of the script execution.
No No Short If the clear script had been executed this script will not migrate default jobs. The clear script removes job_id_700 column which contains necessary data. In this case the only way to migrate default jobs is to move them manually from environment which was not yet upgraded.
PLADES RTM - SP4 N/A N/A N/A Post - Anytime No Create data in ERMPL. i.e. insert Demands for all Design Objects connected to a project activity is inserted into ERMPL, together with Planned Cost Basic data for Project Cost Elements must be set up before executing this script. None   POST_PLADES_App8_CreateDataInERMPL.sql No To execute the script:
  1. Make sure basic Data is set up for Project Cost Elements.
  2. Execute the script as IFS Application Owner.
No No Cannot Predict  
PLADES RTM - SP4 N/A N/A N/A Post - Immediate Yes Remove duplicate objects with same plt_sq, object_revision, and keya combination and convert all keya fields to uppercase where it contains lowercase values.

More info:  This manual script will modify the keya value of the duplicate objects to make the users aware about them. The script may ignore some objects with restrictions on modifying their keyas. (Eg.:- Objects in completed state). Those objects can be identified by executing the queries in get_duplicate_objects_cur and get_objects_cur in this script.
None None POST_PLADES_App8_RemoveDuplicateObjects.sql No
  1. Execute the script as IFS Application Owner.
  2. To create the unique index after removing the duplicates, the commented code that appear at the end of the manual script can be executed.
No No Cannot Predict
PM All All All N/A Pre - Anytime No Update existing Material and/or Tool Facility lines that are not connected to an Operation Upgrading to IFS Applications 10 requires all Material and Tool Facility lines to be connected to an operation in PM Action. This is because Material and Tool Facility (as a Resource) will always be created under a Work List in IFS Applications 10.

In case there are unconnected Material and Tool Facility lines, the upgrade will create an extra Work List line to connect all those Material and Tool Facility records. Exception; if there is only one Work List available, then the upgrade will connect all Material and Tool Facility to that Work List.

If this is not what you want and you need all Material and Tool Facility to be connected to a specific Work List then you need to connect all Material and Tool Facility to an operation line before the upgrade.
None Upgrade will create an extra Work List line to connect all unconnected Material and Tool Facility records. N/A N/A Query for the relevant records and perform the necessary data updates. No No Cannot Predict  
PM RTM - SP7 N/A N/A N/A Post - Anytime No Remove criterias of child PM Actions

  If criteria are not removed from applicable child PM actions, a proper WO structure would not be generated. POST_PM_App8_RemovePMCriteria.sql No Execute the script as IFS Application Owner.        
PM All All All N/A Post - Immediate Yes Update Resource Group Column if NULL values are found There may be records created without a resource group in PM Action/Work List/Resources tab. You are advised to update the Resource Group column if null values are found.   If records are not updated, errors will be raised when a WO is generated using these PM actions. POST_PM_App10_PMResourceDemandsWithoutGroup.sql   Use the SQL query provided in the script to find such task templates that require modification.

Note: The script is for querying purposes only and does not modify data.

       
PROJ All N/A N/A N/A Post - Immediate Yes Link here describe manual configuration that need to be done before running  post scripts in PROJ component. Perform the instruction in the page connected to link. Customer upgrading from App75 should perform this   Post scripts in project may not run properly N/A Yes N/A Yes N/A Short N/A
PROJ All All N/A N/A Post - Immediate Yes Replace old control categories that existed in versions earlier than IFS Applications 8 with new user defined cost elements     Old control categories exist to continue as cost elements without meaningful names. POST_Proj_App9_ReplaceControlCategories.sql Yes
  1. Execute this script as IFS Application Owner.
  2. The script will accept the cost elements to be mapped to old 1 (Material), 2 (Work), 3 (Misc) and 4 (Hours) control categories from the user
  3. Decide whether to update history records as well (This will takes a long time)
No Yes Short  If these cost elements does not exist in the project company, the script will create the cost elements for the relevant companies. Then the script will replace 1, 2, 3 and 4 control categories in all relevant project connected objects, project connection details (which include baseline records) and history loggings as well. If the user does not enter cost elements manually, the script will use default mapped cost elements as before (1 to MATERIALS, 2 to LABOUR, 3 to EXPENSES and 4 to HOURS). If the user entered the same cost element twice or more, the script will stop, raising an error.
PROJ All All N/A N/A Post - Immediate No Reset the activity progress to 100% for activities in closed projects     It may be possible to exist closed activity with activity progress less than100% POST_Proj_App9_ManualActivityProgressUpdate.sql
 
Yes
  1. Execute this script as IFS Application Owner.
  2. Enter the Project ID or click enter for all projects

 

No Yes Cannot Predict

 

Activity progress will be reset to 100% by setting the activity progress method to manual and activity manual progress to 100%.The script by default executes for projects in Closed state. This script can be run either for a single project, set of projects in Closed state or for all projects in Closed state.
PROJ All All N/A  N/A Post - Immediate No Change the Work Day to hours conversion     No consequence POST_Proj_App9_ManualWorkDayToHoursConvUpdate.sql
 
Yes
  1. Execute this script as IFS Application Owner.
  2. Enter the Work_Day_to_hours_conv value. default is 8

 

Yes Yes Long

 

After upgrading to IFS Applications 10, If you wish to change the Work Day to Hours Conv, this script will first update the default value for the Work Day to Hours Conv in System Definition window. Then, this will update the Work Day to Hours Conv parameter in all the Projects and the total work days and baseline total work days in all the activities since total work days and baseline total work days in the activities are calculated based on this value. IF you wish to keep the default value for the Work Day to Hours Conv, this script will only update the total work days and baseline total work days in all the activities. When Work Day to Hours Conv is changed, Early Start and Early Finish will remain the same.
PROJ All All N/A N/A Post - Immediate No Generate spreading for all activities which do not have spreading for its resource planning lines If customer need resource spreading information to be shown for activities after upgrade, this should be run

 

Resource spreading information will not be shown after upgrade POST_Proj_App9_GenerateActivityResourceSpreading.sql
 
Yes Since this might take a long time to complete, Oracle parallel execution is used within the script to speedup execution. Hence to obtain the full benefits of parallel execution and to allow the script to complete in a timely fashion this should be deployed in the following manner:

 

  1. Before deploying, the job_queue_processes system parameter should be set to 25. This can be achieved through the following steps
  2. Obtain the current value of this parameter by executing "select value from v$parameter where name = 'job_queue_processes';" statement and note the result.
  3. If it is less than 25, execute "alter system set job_queue_processes = 25;" and change it to 25.
  4. Deploy the script using the Application Owner user.
  5. Once the script is finished executing, reset the job_queue_processes parameter to the original value by executing "alter system set job_queue_processes = <original value>;".
Yes N/A Long  
PROJ All All N/A N/A Post - Immediate Yes Remove unwanted project connections those were left out during the upgrade.     No issues for customers upgrading from App8 and App9. for others, there might be bit more project connections but should not affect costs, hours or revenue. POST_Proj_App9_RemoveProjectConnections.sql No
  1. Execute this script as IFS Application Owner.
No No Long  
PROJ All All All N/A Post - Immediate Yes Find Primary Parents for Vouchers and Update Project Connections     The purpose of the script is to establish the relationship between vouchers and their parent object. It WILL NOT be possible to view the connected vouchers in the client if this background job is not executed Run the database task Find Primary Parents For Vouchers and Update Project Connections No Visit the datbase tasks and see more information on how to run the task        
PROJBF All N/A N/A N/A Post - Immediate Yes This script will upgrade Project Cost Element Code Part information for upgraded projects. If the upgrade is being done from App75 and bug 99177  is not installed, then run it, Script POST_Proj_App9_ReplaceControlCategories.sql should have been already run prior to this. Project Forecast line can't be created.

POST_Projbf_App9_UpgradePCECodePart.sql

No
  1. Execute this script as IFS Application Owner.
 
No Yes Cannot Predict   
PRJREP All All All N/A Post - Immediate No Regenerate posting for project transactions if posting setup or cost element is changed. When the posting setup is changed manually for PRJIT% and if we need to get the planned revenue through new cost elements.   It will keep existing preliminary postings & planned cost as it is and not reflecting new posting changes Post_Prjrep_App9_RecreatePostings.sql Yes
  1. Execute this script as IFS Application Owner.
  2. If the user wants to include closed projects, enter TRUE
  3. If the user wants to include closed activities enter TRUE

 

Yes Yes Long  
PRJREP N/A All All N/A Post - Immediate No Regenerate the preliminary revenue postings of project transaction and invoicing plan according to the latest posting setup and cost element setup and tax regime. Can be run in fallowing scenarios
  • If the posting setup is changed manually for PRJI1,PRJ2 and if we need to get the planned revenue through new cost elements.
  • In application 10, the functionality of the tax regime has been changed. As a result of this posting type of the preliminary postings can be changed. If we need to regenerate the postings and fetch the planned revenue according to the tax regime modifications then this need to be executed.

     
This will initiate a background job It will keep existing preliminary postings & planned revenue as it is and not reflecting new posting changes Post_Prjrep_App10_UpdateProjectRevenuePostings.sql Yes
  1. Execute this script as IFS Application Owner.
  2. Enter connection object type PTR or IP. default is both types.
  3. if the user wants to include closed projects, enter TRUE
 
Yes Yes Long  
PURCH All N/A N/A N/A Post - Immediate Yes Update values in column purch_ord_invoice_charge_tab.series id with correct values from invoice_tab, invoice_item_tab and posting_proposal_tab. The user will be prompted with the message when unable to update the purchase order invoice charge line with series id if multiple invoices are found. Only applicable for customers who uses Purchase Order Charges None Incorrect values in series id field in purch_ord_invoice_charge_tab POST_PURCH_APP8_UpdateSeriesId.sql No
  1. Execute this script as IFS Application Owner.
  2. Verify the generated spool file update_purch_ord_invoice_charge_tab.txt
  3. Manually handle data according to this spool file (ie: purchase order invoice charge line with invoicing supplier if multiple invoices are found)

Yes Yes Cannot Predict  
PURCH All N/A N/A N/A Post - Immediate Yes Update values in field purch_ord_invoice_charge_tab.invoicing_supplier with correct values fetched from invoice_tab, invoice_item_tab and posting_proposal_tab. The user will be prompted with the message when unable to update the purchase order invoice charge line with series id if multiple invoices are found. Only applicable for customers who uses Purchase Order Charges Dependant on values purch_ord_invoice_charge_tab.series_id. Hence, this script should be run after executing POST_PURCH_V1400_UpdateSeriesId.sql and correcting the data manually according to the spool file generated. Incorrect values in column purch_ord_invoice_charge_tab.invoicing_supplier POST_PURCH_App8_UpdateInvoicingSupplier.sql No
  1. Execute this script as IFS Application Owner.
  2. Verify the generated spool file update_invoicing_supplier.log
  3. Manually handle data according to this spool file (ie: purchase order invoice charge line with series id if multiple invoices are found)

Yes Yes - If Dependency Met Cannot Predict  
PURCH All N/A N/A N/A Post - Immediate Yes Update invoice_id and invoice_company fields in purch_ord_invoice_charge_tab and invoice_id field in purchase_order_invoice_tab with correct values fetched from invoice_tab, invoice_item_tab and posting_proposal_tab. The user will be prompted with the message when unable to update the Purchase Order Invoice Charge Line(purch_ord_invoice_charge_tab) either with invoice_id or invoice_company if multiple invoices are found. Similarly, it will be prompted with the message when unable to update the Purchase Order Invoice Line (Purchase_Order_Invoice_Tab) with invoice_id if multiple invoices are found.   Dependant on column series_id. Hence this script should be run after the POST_PURCH_APP8_UpdateSeriesId.sql. Incorrect values in columns invoice_id and invoice_company in purch_ord_invoice_charge_tab/purchase_order_invoice_tab POST_PURCH_App8_UpdateInvoiceIdAndInvoiceCompany.sql No
  1. Execute this script as IFS Application Owner.
  2.  Verify the generated spool file update_invoice_id_and_invoice_company.txt
  3. Manually handle data according to this spool file (ie: Purchase Order Invoice Charge Line(purch_ord_invoice_charge_tab) either with invoice_id or invoice_company if multiple invoices are found OR Purchase Order Invoice Line (Purchase_Order_Invoice_Tab) with invoice_id if multiple invoices are found)

Yes Yes - If Dependency Met Cannot Predict  
PURCH All N/A N/A N/A Post - Immediate Yes Update ap_invoice_no and series_id in Purchase_Receipt_Charge_Tab with correct values fetched from purch_ord_invoice_charge_tab. The user will be prompted with the message when unable to update ap_invoice_no and series_id if multiple invoices are found. Only applicable for customers who uses Purchase Order Charges Dependent on updating invoice_no, series_id , Invoice_id, and Invoice_company in Purch_Ord_Invoice_Charge_Tab in POST_PURCH_APP8_UpdateInvoiceIdAndInvoiceCompany.sql.. Hence, this must be run after executing the above script as well as after correcting the data Incorrect values in column ap_invoice_no and series_id in Purchase_Receipt_Charge_Tab POST_PURCH_App8_UpdateInvoiceInfoInChargeReceipt.sql No
  1. Execute this script as IFS Application Owner.
  2. Verify the generated spool file UpdateInvoiceInfoInChargeReceipt.log
  3. Manually handle data according to this spool file (ie: message when unable to update ap_invoice_no and series_id if multiple invoices are found)

Yes Yes - If Dependency Met Cannot Predict In 1400.upg has the logic to update ap_invoice_no and series_id in Purchase_Receipt_Charge_Tab with the default value '*'. This script is used to update above values with actual values fetched from purch_ord_invoice_charge_tab.
PURCH All All RTM-UPD1 N/A Pre - Anytime Yes Delivery Patterns and Customer Order Route (if ORDER component is installed) will be obsolete from App9-UPD1 onwards and existing records in Delivery Patterns and Customer Order Route will be copied to Delivery Route (which will be newly introduced to the system from App9-UPD1).    Only applicable for customers who uses both Delivery Patterns and Customer Order Route Only applicable if ORDER component is installed. If user fail to do so Delivery Pattern IDs that are similar to Route IDs in Customer Order Route will not be copied to Delivery Route. N/A N/A
  1. Appowner or a user who has permission to access the below windows should be logged on to the application.
  2. Use below statement in Search, Advanced, SQL of the Procurement Basic Data (ifsapf:frmPurBasic)-> Delivery Patterns (frmDeliveryPattern) tab.
    (DELIVERY_PATTERN_ID in (select ROUTE_ID from &AO.CUSTOMER_ORDER_ROUTE))

    Or below query can be used in the database instead.

    SELECT  *
    FROM   purch_delivery_pattern_tab
    WHERE  (delivery_pattern_id IN (SELECT route_id FROM customer_order_route_tab));

  3. Users will get records, comprising of Delivery Pattern IDs that are similar to existing Route IDs in the Customer Order Route. Then, users can duplicate the patterns with different IDs and update the delivery pattern in the Supplier for Purchase Part window with the new entry accordingly.

Yes Yes Short After App9-UPD1, Delivery Route will be used as the delivery pattern and customer order route in respective areas in the application. When we do the copying, we might have delivery pattern IDs that are similar to route IDs in customer order routes. This would create problems when both data ends up in the same location (Delivery Route) after the upgrade. In order to facilitate copying those data to Delivery Route, new patterns will have to be manually created using different IDs. Then only the dissimilar patterns to the customer order routes will be copied to the Delivery Route using an AUTO post script in PURCH module (POST_Purch_CopyDeliveryPatternToDeliveryRoute.sql).
RCEIPT All All All N/A Pre - Immediate and
Post - Immediate
Yes The structure of the Dispatch Advice message (DESADV) has been changed in APP10. If the message is already sent before the upgrade but not received yet, such a message will not be possible to receive after the upgrade to APP10.   Only applicable if you have Dispatch Advice messages (DESADV) in the queue that are sent but still not received through the Connectivity before the upgrade. None

Will have to re-send such DESADV messages after the upgrade.

N/A N/A
  1. Check whether there exists any Dispatch Advice messages (DESADV) that has been sent already; but, still not received.
  2. Process (Send & Receive) such messages through Connectivity "before" the upgrade
  3. Or otherwise, re-send such messages "after" the upgrade
Yes Yes Short  
SHPMNT All All All N/A Pre - Immediate preferrably and
Post - Immediate
Yes The structure of the Dispatch Advice message (DESADV) has been changed in APP10. If the message is already sent before the upgrade but not received yet, such a message will not be possible to receive after the upgrade to APP10.   Only applicable if you have Dispatch Advice messages (DESADV) in the queue that are sent but still not received through the Connectivity before the upgrade. None

Will have to re-send such DESADV messages after the upgrade.

N/A N/A
  1. Check whether there exists any Dispatch Advice messages (DESADV) that has been sent already; but, still not received.
  2. Process (Send & Receive) such messages through Connectivity "before" the upgrade
  3. Or otherwise, re-send such messages "after" the upgrade
Yes Yes Short  
SRVQUO All All All All Post - Immediate Yes Update the Price Source columns with the correct values in the ser_quote_mo_price_details_tab table. If VIM is installed None The discount and price details on the Maitenance Order can be wrongly fetched, due to incorrect Price Source values. POST_SRVQUO_App10_UpdatePriceSourceValues.sql No       Short  
TAXLED All All All All Pre - Immediate Yes Check whether all the tax transactions are fetched before the Upgrade.i.e. Column fetched in tax_ledger_item_tab has value TRUE for all the records   None Inconsistent data in Tax Ledger N/A N/A
  1. Make sure all the tax transactions are updated to GL
  2. Run Fetch Tax ledger
Yes N/A Cannot Predict  In case you are not using tax ledger functionality run: UPDATE tax_ledger_item_tab SET fetched = 'TRUE'
TIMREP All All All All Post-Anytime No

The script should be used to bulk recalculate Time and Attendance results after change of "RESULTS IN 10 DEC" property in System Definitions/Object Properties window.
The change of configuration will affect only results calculated after that change. Previously calculated results need to be recalculated using this script or via IFS Applications with the recalculate option for the required days.
The script will recalculate the previously entered results except the ones with day status Authorized, Transferred and Manual (Calc Status field in Time Card Day window) and these days need to be corrected manually.

The script should be used after change of configuration of "RESULTS IN 10 DEC" property in System Definitions/Object Properties window. The change of the configuration is not done automatically in any situation (especially it is not done during upgrade). It could be done only manually by end user. None

The days which are not recalculated will remain with number of decimals as the configuration used before the change and there will be difference between number of decimal places in the results between results created before and after change of the configuration.

POST_Timrep_App10_RecalculateTimeAndAttendance.sql Yes
  1. Decide if script execution is needed.
  2. Enter parameters inside the script. They are descibed in the script.
  3. Execute the script as application owner (IFSAPP) via e.g. sqlplus.
  4.  Correct manually via IFS Applications results with day status Authorized, Transferred and Manual (Calc Status field in Time Card Day window). They are not corrected by the script.  
Yes No Cannot Predict  
TRVEXP N/A N/A N/A Yes Post - Immediate Yes In App9 it was possible to modify the "deductible %" for the tax code in expense_code_tax_lines_tab in SALES TAX companies, which led to an inconsistency between the "dedcutible %" in expense_code_tax_lines_tab and statutory_fee_tab. This script will list such tax codes with different "deductible %".
An Application Consultant should analyze and address all discrepancies reported by the script.
  None Inconsistency between the "dedcutible %" in expense_code_tax_lines_tab and statutory_fee_tab. POST_Trvexp_App10_TaxCodesWithDifferentDeductible.sql No
  1.  Execute the script as application owner (IFSAPP) via e.g. sqlplus.
  2.  An Application Consultant should analyze and address all discrepancies reported by the script.
Yes No Cannot Predict  
WO All All All N/A Pre - Immediate Yes Create and transfer all Css Transactions before upgrading to IFS Applications 10 Only applicable if your company/companies are using IFS Service Management and Cost of Sold Services functionality to carry out a financial analysis on Costs vs. Sales in IFS/General Ledger. None During upgrade to IFS Applications 10, only Css Postings that are transferred to finance will be upgraded to the new Task framework. So failing to transfer all Css Postings before the upgrade will result in Css records not been upgraded to the new Task Framework. N/A N/A
  1. Navigate to Create CSS Postings window.
  2. Generate CSS Transactions for all sites.
  3. Navigate to Transfer CSS Transactions window.
  4. Transfer CSS Transactions to Finance for all sites.

Note: In order to create CSS postings:
-Vouchers should be created for the relevant work order posting line (Booking Status of the WO posting line = Transferred, and the transaction has a voucher number)
-The CSS Type of the work order posting line should be Not Posted or Partly Posted.
-The work order posting line should be transferred to IFS/Customer Order and;
-The status of the customer order should be Delivered or above OR the status of the work order posting line should be set to Not Invoiceable and the work order completed.

Once created, the CSS postings can be viewed in CSS Postings Analysis. Next step is to transfer them to IFS/Accounting Rules before further transferring them to IFS/General Ledger.

Yes No Cannot Predict  
WO All All All N/A Post - Anytime No Clean up unwanted records in several tables in WO There maybe incorrect records in the WORK_ORDER_PLANNING_TAB where work order planning lines are not connected to an operation or work order. After upgrading to IFS Applications 10 such wo planning lines will not be connected to a work task and should ideally be deleted from the database. None Incorrect records may show up in the application. POST_WO_App10_PrepareCleanUpEmptyData.sql No Decide if the relevant records should be deleted from the database. If you choose to delete execute the script as IFS Application Owner. No No Short  
WOCFG N/A N/A All All Post - Immediate Yes This data upgrade script for update surveys for existing mwo customers in App9 and App10. Existing data in previous version needed for migration. None No records visible from previous versions. POST_Wocfg_Mobile_Survey.sql No Purpose: This data upgrade script for update surveys for existing mwo customers in App9 and App10.
This will upgrade surveys excluding connected filters and access. After upgrade, these surveys can be connected to workflow in Aurena client and complete the set up.
Yes Yes Short  
WOCFG N/A N/A All All Post - Immediate Yes This data upgrade script for update workflow configuraion data for existing mwo customers in App9 and App10. Existing data in previous version needed for migration. None No records visible from previous versions. POST_Wocfg_Mobile_Workflow.sql No Purpose: This data upgrade script for update workflow configuraion data for existing mwo customers in App9 and App10.
After upgrade, workflow set up can be finalised in Aurena client.
Yes Yes Short  
WADACO All All All N/A Post - Immediate Yes If WADACO component is installed later as a "separate" FRESH installation\delivery, then data capture processes related POST files in already installed components must be re-deployed "manually" to install Wadaco specific data capture processes. No
  1. This activity is ONLY valid If WADACO component is installed later as a "separate" fresh installation\delivery.
  2. The relevant file deployment should be done in component dependency order. E.g. POST files in component INVENT should be deployed before any POST files from other components.
Wadaco specific data capture processes will not be installed correctly. N/A N/A

The existing POST files in already installed components (see below for list of related components) must be re-deployed "manually" to install Wadaco specific data capture processes.

  1. Files with naming convention  POST_<Component>_DataCa<process_name>.sql in components INVENT, ORDER, RCEIPT, SHPMNT and WO (e.g.: POST_INVENT_DataCaptureMovePart.sql)
  2. Files with naming convention DataCapt<process_name>.ins in component SHPORD and KANBAN. (e.g.: DataCaptManIssueSo.ins)
No Yes Short
  1. This manual file deployment is needed since files for already installed components mentioned above need to be re-deployed as a post action if the Wadaco component is installed as a separate fresh installation.
  2. These post files reside in Checkout location "<Component>\source\<Component>\database" or in Build location "database\<Component>".