Skip to content

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

Column Name Description Values
Component IFS Business Component short name.  
Upgrading From
The IFS Application version a customer is upgrading from, for which the manual action is valid. The valid upgrade versions are [APP8 Upgrade], [APP9 Upgrade] and [APP10 Upgrade].

Format:
<Valid_From SP/UPD> - <Valid_To SP/UPD>






Example values and how to interpret:
[APP9 Upgrade] = RTM - UPD3
means this action is only valid if a customer is upgrading from APP9 RTM, UPD1, UPD2, or UPD3 .

[APP8 Upgrade] = SP1 - SP2
means this action is only valid if a customer is upgrading from APP8 SP1 and SP2.

[APP8 Upgrade] = UPD4 - Any
means this action is only valid if a customer is upgrading from APP9 UPD4 or above.
Installation Step When (during the upgrade) should the manual step be executed, i.e., Pre- or Post- installation step. Pre - Immediate: The action should be executed immediately before the upgrade.
Pre - Anytime: The action can be executed as required, e.g., a few days or a month before the upgrade.
Post - Immediate: The action should be exeuted immediately after the upgrade, before the application can be used.
Post - Anytime: The action can be made after the upgrade as required.
Mandatory Action Is this a required manual action. Yes/No
Activity Description Short description of the manual action.  
Functional Conditions Conditions when the manual action is applicable. The conditions may depend on the data or specific customer requirements.  
Techincal Dependencies For example, should manual scripts be executed in a specific order.  
Consequences What is the impact of not executing the manual action, i.e., would it impact the use of a certain functionality etc.  
Script Name The file name of the script that should be executed if applicable. Manual scripts are located in ..\<component>\manualdeploy\database\<component>\  
Script Requires User Input? Does the manual script require user input. Yes/No
Steps Detailed steps on how to execute the manual action.  
Functional Assistance Needed? Would a technician require the assistance of a functional expert in order to execute the manual action. Yes/No/Recommended
Parallel Execution Can a manual script be executed parallely. Yes/Yes - If Dependency Met/No
Estimated Duration Estimated duration it would take to execute a manual action. NOTE: The duration provided are guesstimates and is provided only as a guide. Actual duration in an installation can vary greatly based on the amount of data in the customer's database, hardware/software resources, and other factors. Long (Over 1 hour)
Short   (Below 1 hour)
Cannot Predict
Additional Information Additional information not covered by the other columns.  

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

Component
Upgrade from
APP8
Upgrade from
APP9
Upgrade from
APP10
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 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 UPD1 - Any   Post - Immediate No Update Deductible% in the Tax Code page Only applicable for customers who want to update the Deductible % on the Tax Code page 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 <br/>    company_ VARCHAR2(20)         := '10';<br/>    tax_code_ VARCHAR2(20)        := '1'; <br/>    deductible_percentage_ NUMBER:= 40;<br/> <br/> BEGIN <br/>    UPDATE statutory_fee_tab <br/>    SET deductible = deductible_percentage_<br/>    WHERE company = company_ <br/>    AND fee_code = tax_code_; <br/>    COMMIT; <br/> END;<br/> /
Yes N/A Short  
BACLI N/A N/A All Pre - Anytime Yes Upgrade IFS Business Reporter Reports using Upgrade Utility; the 'Enable compression of result set' option needs to be checked for all the reports in order to execute the reports without any issue's. None Reports can not be executed without getting errors
N/A No N/A Short
BACLI All All N/A 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.
COST 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 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 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 Cloud" (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 Cloud 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 Cloud" (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  
DOCMAN 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 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 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 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
DOCMAN 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_typecolumn 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_TABwill be dropped by this script.
Yes No Cannot Predict  
DOCMAN 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 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 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 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 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 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 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 using command  Update Company inApplication Base Setup / Enterprise / Company / Company page. 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 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 page, General information
    1. Check value of Country field
    2. Check value of default language
  2. Sites page
    1. Check value of Country column
  3. Taxation Liability Countries Company / Tax Control / Invoice tab
    1. Check value of Country column
 
No N/A Short  
ENTERP 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 page

Yes N/A Short  
ENTERP 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 page. 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 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 page and make sure the Name field is aligned with First name, Middle name and Last name Yes N/A Short  
FINCFA 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 pages 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 pages 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 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 page.
  2. Use command Analysis Details Cash Flow Source on selected Cash Flow Analysis ID.
  3. Put Yes in column Include in Cash Flow Analysis for selected entries and save.
  4. Select Command Update Analyse Online to execute online or select command Update Analyse in Background to execute in background.
Yes N/A Cannot Predict  
FNDBAS 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 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 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 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 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 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 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.
GENLED 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 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 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 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 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  
INVOIC 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 upgradeSELECT *
    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  
KPISVR N/A N/A All Pre - Immediate Yes Do not run the drop script for KPISVR if you want to keep the KPI calculations as a reference. None None
KPI calculations will not be available as references any more <build_home>\manualdeploy\database\prodifsapplications\KPISVRdr.sql N/A Do not run the the drop script N/A Short
ORDER 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 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.
PAYLED 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 page 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 page to check the mixed payments.
Yes No Cannot Predict  
PCMSTD 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 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  
PERSON 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.
PM 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 N/A All All Post - Immediate No Update Planned Start, Finish dates and Earlier Start Finish dates in PM Maintenance Plan. Issue: After the upgrade some PM Actions Maintenance Plan does not have a value in Planned Start/Planned Finish/Earliest Start/Latest Finish dates. As a result work orders will be generated without planned start and finish dates from these PM actions.
This script will update Planned Start, Finish dates and Earlier Start Finish dates in PM Maintenance Plan.
Script will also update the 'Date To' date in PM Action Calendar Operation and in Activities.
Script can be run for a given site, several given sites or for all sites.
  As a result work orders will be generated without planned start and finish dates from these PM actions. POST_PM_App10_UpdatePmCalendarPlanDates.sql Yes Execute the script as IFS Application Owner.

If you wish to run this script for a single site, enter the desired site and press ENTER.
If you want run this script ONLY for a set of sites please enter the desired sites seperated by a '^' sign on the prompt and press ENTER.
If you wish to run this script for ALL sites, enter '%' AND press ENTER.
Yes   Cannot Predict If you run this script for ALL sites, it will be TIME consuming.
PM 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 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 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 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 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 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 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 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        
PRJREP 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 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 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 Routewill 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 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 N/A Pre - Immediate preferably 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  
TAXLED 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 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 Cloud 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 Cloud 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 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 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  
WOCFG 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 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