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) |
|
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:
|
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
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:
|
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:
|
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
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 | 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,
|
N/A | N/A | Check the following forms to make sure that the country as well as the default language are correctly defined
|
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 |
|
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 |
|
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 |
|
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:
|
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 |
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
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 |
|
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.
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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:
|
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 |
|
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 |
|
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
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
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 | 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 | 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 |