IFS Connector Minimum Version Matrix
- IFS Energy and Resources (Deactivated)
- Dustin Smith (Unlicensed)
- IFS Energy & Resources (Deactivated)
Back to Configure IFS Connector Back to IFS BOLO and IFS Land Tips and Tricks Back to IFS Connector Home Back to IFS Enterprise Upstream/IFS ProCount Troubleshooting
IFS Connector is designed to support backwards compatibility so that clients do not have to upgrade all components at the same time. This Matrix identifies the major changes that have been added for each version level. Therefore, a client may go live on an older version of a product recognizing that there may be some later fixes that they do not have access to and development will not backport these fixes.
IFS iLandMan and IFS Land | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
|---|---|---|---|
Feb 21, 2020 | IFS iLandMan 2.10 | IFS Land 5.13
| Base version support for Leases and Contracts from IFS iLandMan to IFS Land Lease Acquisition Queue, Name and Address Reference from IFS Land to IFS iLandMan, Leases and Contracts Integration Reference from IFS Land to IFS iLandMan. |
Aug 3, 2020 | IFS iLandMan Current Version | IFS Land 5.14 | The IFS iLandMan to IFS Land integration establishes a real-time link between IFS iLandMan and IFS Land to provide a new Lease Acquisition solution that enables the transfer of Lease data with their Contacts from IFS iLandMan into IFS Land. Additional improvements to this feature include:
|
Oct 26, 2020 | IFS iLandMan Current Version | IFS Land 5.15 | The IFS Land to IFS iLandMan integration for Lease Acquisition was enhanced to:
|
Oct 26, 2020 | IFS iLandMan Current Version | IFS Land 5.14 | Issue: Assignments from IFS iLandMan with "Do Not Expire" option or null expiration date were not able to integrate into IFS Land. Resolution: Modified the application so that the assignments with "Do Not Expire" option or null expiration date are staged without an expiration date and can be integrated without errors. Issue: Unable to Integrate Assignments from IFS iLandMan to IFS Land due to Participant Interests summing up to greater than 1. Resolution: Modified the application so that the participant list coming from IFS iLandMan for Assignments to IFS Land will be a distinct list of owners and interest types with zero interests. Issue: When the integration route and contract route are set at very close frequencies, data overlap causes the "Send To P2Land" Flag on Rejected and Deleted Files to get updated to False by the integration route before they are picked by the contract route. This caused the Rejected and Deleted Files to get missed and not sent to IFS Land. Resolution: Modified the application so that regardless of the frequency set up for rejection and deletion routes, there is no overlap in the data updated on a file coming from IFS iLandMan. Issue: The IFS Connector Suspense route was not populating the GL Account and Suspense GL Account attributes properly upon integration into IFS Excalibur from IFS Land. Resolution: Modified the mapping within the IFS Connector Suspense route to populate the attributes so that glAccount and suspenseGIAccount are sent from IFS Land to IFS Excalibur. |
Jan 29, 2021 | IFS iLandMan | IFS Land 5.16 | Issue: The Connector for IFS iLandMan to IFS Land integration would only accept LSE, LND, and DEE group codes from IFS iLandMan. Resolution: The Connector for IFS iLandMan to IFS Land integration will now accept all group codes belonging to LSE, COL and AGM application codes. |
IFS BOLO and IFS Merrick | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
| IFS BOLO 13. 4 | IFS Merrick 3. 4 | Base version support for Wells, Operator /Purchaser, Monthly Volumes, Well Status. |
May 8, 2018 | IFS BOLO 13.6 | IFS Merrick 3.7 | IFS Merrick added a notification feature to IFS ProCount services to send notices of deleted or zeroed-out records when there are changes to the gathering system or there were connection changes that were previously sent after locking the gathering system. |
May 8, 2018 | IFS BOLO 13. 6 | IFS Merrick 3. 7 | Allocated monthly volumes of components (C2, C3, C5, IC4, NC4) can now be configured to integrate with IFS BOLO Financial System. |
March 5, 2019 | IFS BOLO 13.8. 0 | IFS Merrick 3.7 | Issue: The user was not able to capture volumes for individual plant products as allocated in IFS ProCount. The application was not adding volumes from multiple sales points but was replacing or overriding volumes from multiple sales points. Resolution: The user is now able to capture volumes for individual plant products in IFS BOLO's Monthly Production file (PROD.MO) as allocated in IFS ProCount. |
Aug 27, 2019 | IFS BOLO 13.8.7 | IFS Merrick 3.7 | Issue: Production Monthly Disposition Volumes integrated from IFS ProCount were being incorrectly totaled for Production and Output volumes in IFS BOLO. Resolution: Corrected IFS BOLO’s totaling logic for Production and Output volumes integrated via the Monthly Disposition Volumes route from IFS ProCount. |
Feb 20, 2020 | IFS BOLO 13.8.14 | IFS Merrick 3.7 | Issue: The completion type flowing from IFS BOLO to IFS Merrick through the Wells and Completions route was not being populated correctly and was always populated with a W. Resolution: Modified the IFS BOLO application to populate the completion type using the PROP.TYPE from WELL.INFO instead of the CC.TYPE . |
June 18, 2021 | IFS BOLO 13.8.14 | IFS Merrick 4.1.0.1 | Issue: The default interop metadata was missing the Meter TMP field on the Meter Basic screen. This is a display issue and only impacts customers using IFS ProCount interoperability with IFS Enterprise Upstream and IFS BOLO. Resolution: Added the Meter TMP field to the default interop metadata. |
Dec 3, 2021 | IFS BOLO 13.911.0 | IFS Merrick 4.1.0.1 | Issue: When IFS ProCount InterOp with IFS BOLO was enabled (INT1201), a user was able to send a Well from IFS BOLO to IFS ProCount. When the Completion Date was blank or /null/, an error occurred within IFS ProCount. The missing Completion Date caused an error in building a Completion record in IFS ProCount. Resolution: IFS BOLO now confirms all required attributes on a Well when the IFS ProCount InterOp is enabled. Required attributes for the base application are (Screen prompt label (file attribute name)):
Required attributes when IFS ProCount InterOp is enabled are:
Note: This prompt required updating the Status Effective Date and the Property Type (SWD, O, G, etc.) in the Well Type/Status button in the General Information tab.
|
Dec 28, 2021 | IFS BOLO 13.9.12.0 | IFS Merrick 4.1.0.1 | Background: Users executing the IFS ProCount/IFS BOLO InterOp were still required to update the Well Status (PRD1305) through the PRD2311 Upload of Well Count and Well Status. Aligning the Wells that require an update and researching production data to identify the well status was very time-consuming and error-prone. Enhancement: When users execute the IFS ProCount/ IFS BOLO InterOp, the Well Status used within Accounting is now updated through the Monthly Volume Web Service. The calculation of Well Status is:
In the past, the attribute updated in IFS BOLO was a separate attribute within the WELL.COUNT file called P2PRODUCTION. The Well Count and Well Status attributes in the WELLCOUNT table remained unchanged. With this modification, WELL.COUNT (PRD1405) updates include:
With this modification, WELL.INFO (PRD1210) updates include:
Benefits of this Enhancement:
|
April 14, 2022 | IFS BOLO 13.9.15.0 | IFS Merrick 4.1.0.0 | Issue: When integrating Monthly Disposition Volumes from ProCount to IFS BOLO, new logic checks WELL.INFO Well Status & Effective Dates for the relevant Well records. If the Date of the Monthly Disposition Volumes does exist, then the system will throw an error stating that "Well Status Eff Date 'XX/XX/XX' already exists in '=XXX'" (XXX is Well ID) This is a problem for customers who integrate multiple product Monthly Disposition volumes from ProCount to IFS BOLO for the same Well records. Resolution: When integrating Monthly Disposition Volumes from ProCount: Business Rules for Well Status in ProCount InterOp within Volume Web Service • The Well Status value is based on the number of DAYS.ON for the Well within ProCount 1. If the Well has DAYS.ON of 1-31, the InterOp updates the MERRICK.STATUS in the WELL.COUNT file with "PR" (Producing) 2. If the Well has DAYS.ON of 0 (zero), the InterOp updates the MERRICK.STATUS in the WELL.COUNT file with "SI" (Producing) 3. If the Well has DAYS.ON of blank or negative, the InterOp does NOT update the MERRICK.STATUS in the WELL.COUNT file and an error is reported within ProCount. The allocated Well record is corrected in ProCount and a valid number of DAYS.ON is then sent in the InterOp to BOLO • The WELL.COUNT file continues to be updated to include the end of month Well Status from ProCount 1. OLD Update: The MERRICK.STATUS display-only attribute was updated during the Volume Web Service with either PR (Producing) or Shut-in (SI) Problem: When viewing the Well Status record on PRD1305, the Accounting Well Status could be different since the value was either manually entered or created through the PRD2311 Upload. 2. NEW Update: The MERRICK.STATUS display-only attribute was updated during the Volume Web Service with either PR (Producing) or Shut-in (SI) o The WELL.STATUS attribute, prompt label on PRD1305 is 'Accounting Well Status' is updated directly from Procount with the Well Status defined by the business rules outlined above. In IFS BOLO, each Well Status record required a Well Count. o The Well Count from the previous record is copied into the NEW Well Count record during the ProCount InterOp. |
Oct 20, 2022 | IFS BOLO 13.9.15.0 | IFS Merrick 4.8.0 | Added a new Integration Status screen in ProCount to view the monthly integration status between ProCount and the financial system (EU/BOLO) for records from the CompletionMonthlyDispSt table with a status of 'E,' 'T,' 'W.'
|
Sep 9, 2022 | IFS BOLO 13.9.19.0 | IFS Merrick 4.8.0 | Issue: Completion Date (mm/dd/yyyy) requirement within BOLO caused the START.ACTIVE.DATE in ProCount to update |
IFS BOLO and IFS Land | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
| IFS BOLO 13.5 | IFS Land 5.5 | Base version support for Names, Withholding, Leases, Check /AP Detail, Void Checks, and Invoice /AR Detail. |
April 11, 2018 | IFS BOLO 13.5.2 | IFS Land 5.5 | Issue: If IFS Land sent a Name record to IFS BOLO that did not have a state, IFS BOLO would populate the state attribute with a randomly selected state. Resolution: Modified the Name service for the IFS Land interop so that if a Name record is sent to IFS BOLO from IFS Land without a state, IFS BOLO will not populate the state attribute. |
May 7, 2018 | IFS BOLO 13.6 | IFS L and 5.5 | Issue: When viewing a parent name record that had originated in IFS Land and populated in IFS BOLO via the webservice, that parent name record could be deleted in COM1201 without issue. Resolution: Modified COM1201 so that parent or base name record transferred from IFS Land to IFS BOLO cannot be deleted within IFS BOLO. The parent or base name record can also be modified within IFS BOLO to support core accounting processing. |
Aug 29, 2018 | IFS BOLO 13.6.5 | IFS Land 5.5 | Issue: When exporting the Well data from IFS BOLO and into IFS Land, the Well Number or the IFS BOLO Well File – SHADOW.KEY – was not transferred into IFS Land on export. The Record Id that was created in IFS Land should be the IFS BOLO well SHADOW.KEY or Well Number. Resolution: Modified the application to successfully export Well data from IFS BOLO and import into IFS Land. The Record Id created in IFS Land is now the IFS BOLO well SHADOW.KEY or Well Number. |
Jul 21, 2019 | IFS BOLO 13.6.5
| IFS Land 5.10.0.0 | Issue: Users were able to save a manual invoice without a Payment Due Date, which is a required field for the MIDCAP interop. Resolution: Modified the application to make the Payment Due Date field a requirement on manual invoices when CHECK_INVOICE_INTERFACE_SYSTEM is set to MIDCAP. |
Aug 31, 2020 | IFS BOLO 13.8.18
| IFS Land 5.10.0.0 | Issue: Within IFS BOLO, processing is controlled through a posting process which is referenced as the POSTQ. The POSTQ fails to perform properly when integrating a Land Lease record through the InterOp from IFS Land or IFS iLandMan. The processing fails when the Lease Cost Center record is updated in the Cost Center file and the Lease Cost Center Type (L) is part of a reporting hierarchy as defined in GL1212.
Resolution: The POSTQ no longer fails or "halts" when a lease Cost Center Type (L), as defined within a reporting hierarchy, is posted to the Cost Center file as part of the Land Lease InterOp integration with IFS Land or IFS iLandMan. |
Oct 20, 2021 | IFS BOLO 13.9.4.0 | IFS Land 5.10.0.0 | Issue: The user was prompted for a date when exporting IFS BOLO Land data into IFS GIS reporting layer. The export did not provide a default option, and the User was not able to enter any data. Resolution: Export to IFS GIS now suppresses or bypasses the date prompt. The export does not require User intervention which avoids an abort and enables the export of core data into IFS GIS business reporting layer. |
Oct 20, 2021 | IFS BOLO 13.9.8.0 | IFS Land 5.10.0.0 | Issue: IFS BOLO users with the IFS Land Interop functional were not allowed to update owners/vendors in COM1201. Resolution: IFS BOLO users with the IFS Land Interop functional now have the option to edit owners/vendors in COM1201. In INT1201 select Y for the new field BOLO Source of Name Record. This will give a IFS BOLO user the ability to make changes to owners/vendors that are also using IFS Land. We recommend that the client have audit logging enabled in the WELLCORE.INT.CTL table. If prompt security is enabled, the client will need to enable prompt security for INT1201 BOLO.SOURCE.NAME attribute. |
April 14, 2022 | IFS BOLO 13.9.15.0 | IFS Land 5.10.0.0 | Issue: When Lease Cost Center was created in IFS BOLO through Land InterOp, and Asset Tracking for Lease cost center types were enabled, the AT.ASSET table was not updated with the Lease Cost Center. Resolution: When Asset Tracking is enabled, the User is required to ensure the setup is accurate. When the InterOp from the IFS Land applications is executed, the Lease records are created in the AT.ASSET table.
|
April 14, 2022 | IFS BOLO 13.9.15.0 | IFS Land 5.10.0.0 | Issue: User receives an abort message when selecting OK after INT2401 processes Saved List file. Resolution: Use now returns to INT2401 screen without receiving an abort message after Saved List is processed. |
July 22, 2022 | IFS BOLO 13.9.18.0 | IFS Land 5.10.0.0 | Issue: Triggers are utilized within BOLO to effectively manage the processing within specific applications. The Triggers associated with multiple processes were not included in the upgrade and new install scripting executed by Managed Services.
Update and Delete Triggers are automatically managed with the Upgrade and New Install for:
|
April 10, 2023 | IFS BOLO 13.9.24 | IFS Land 5.10.0.0 | Issue: When User has two accounts eligible for Land Payments, the System Setup screen for Land Integration did not allow User to define two or more Bank Account Codes for the same Company. Resolution: Users are now able to build the INT1201 - System Setup configuration for Land with two or more Bank Account Codes for the same Company ID. |
Feb 17, 2023 | IFS BOLO 13.9.23.0 | IFS Land 5.10.0.0 | Issue: When Users reference a Default Bank Account for Accounts Payable (AP1201), the same Account ID or Account Code could not be referenced within the InterOp Settings (INT1201) setup screens.
|
IFS BOLO and IFS iLandMan | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
| IFS BOLO 13.8 | IFS iLandMan Current Version | Base version support for Names, Withholding, Leases, Checks /AP Detail, Void Checks, Invoice/AR Detail. |
Nov 11, 2019 | IFS BOLO 13.8.10.0 | IFS iLandMan Current Version | Issue: Users were unable to transfer a Name record from IFS iLandMan with the Vendor or Customer designation required in IFS BOLO. A Vendor designation is required to build Accounts Payable records transferred from IFS iLandMan to IFS BOLO through the Payable Web Service. The Vendor designation was manually created in IFS BOLO through an additional step. A Customer designation is required to build Accounts Receivable or TRANS records transferred from IFS iLandMan to IFS BOLO through the Receivable Web Service. The Customer designation was manually created in IFS BOLO through an additional step. Resolution: The transfer of data from IFS iLandMan to IFS BOLO is now supported by an additional Web Service route. Users will be required to install IFS MidCap Web Services version 2.7.0.0 and configure the Route 91 with the desired frequency of transfer. |
Aug 7, 2020 | IFS BOLO 13.8.17 | IFS iLandMan Current Version | Issue: Contact information in IFS BOLO was always being IFS iLandMan: Contact replaced by contact information sent by the IFS iLandMan Details Not Handled By integration when names were sent to IFS BOLO. Interop Resolution: Contact information flows from the IFS iLandMan integration into IFS BOLO only when the record does not yet exist in IFS BOLO. If a NAME record exists in IFS BOLO, contact information is not updated. |
Feb 20, 2020 | IFS BOLO 13.8.14 | IFS iLandMan Current Version | Issue: Users were unable to resolve duplicate name records in IFS iLandMan when attempting to integrate the record into IFS BOLO. The possible duplicate records were not being returned to IFS iLandMan. Resolution: Modified the linking logic in IFS BOLO that determines possible duplicate records so that they can be resolved correctly in IFS iLandMan. Issue: Sites originating in IFS iLandMan were not populated with the correct AP or AR usage codes for vendors and customers when populating the NAME record in IFS BOLO. Resolution: Modified the site creation logic to populate the AP or AR usage codes as necessary when the incoming record is a vendor or customer. |
Aug 7, 2020 | IFS BOLO 13.8.17 | IFS iLandMan Current Version | Issue: Contact information in IFS BOLO was always being replaced by contact information sent by the IFS iLandMan integration when names were sent to IFS BOLO. Resolution: Contact information flows from the IFS iLandMan integration into IFS BOLO only when the record does not yet exist in IFS BOLO. If a NAME record exists in IFS BOLO, Contact information is not updated. |
Aug 7, 2020 | IFS BOLO 13.8.17 | IFS iLandMan Current Version | Issue: When a NAME record in IFS BOLO has a Foreign System defined already, and that record is linked to via the IFS iLandMan integration, the record in COM1201 is not locked as appropriate. Resolution: When the IFS iLandMan integration links a IFS iLandMan name to a BOLO NAME that contains a Foreign System already, the records in COM1201 lock appropriately. |
Aug 31, 2020 | IFS BOLO 13.8.18 | IFS iLandMan Current Version | Issue: Within IFS BOLO, processing is Controlled through a posting process which is referenced as the POSTQ. The POSTQ fails to perform properly when integrating a Land Lease record through the InterOp from IFS Land or IFS iLandMan. The processing fails when the Lease Cost Center record is updated in the Cost.Center file and the Lease Cost Center Type (L) is part of a reporting hierarchy as defined in GL1212.
Resolution: The POSTQ no longer fails or 'halts' when a Lease Cost Center Type (L), as defined within a reporting hierarchy, is posted to the Cost.Center file as part of the Land Lease InterOp integration with IFS Land or IFS iLandMan. |
April 14, 2022 | IFS BOLO 13.9.15.0 | IFS iLandMan Current Version | Issue: When two or more records were created in iLandMan for a payment, the Approval record in BOLO remained LOCKED which prevented further processing. Resolution: During the process of creating payment records from iLandMan and IFS BOLO, there are several records created to manage and retain the integrity of the unique record IDs. In the past, the Voucher ID was created and the LOCKS were released automatically as validation for the Voucher was completed. During the same InterOp, the Approval record was created (PAPPR); however, the LOCKs were not immediately released. The Approval records are now created and released as part of the automation and validation of records received from iLandMan, and the same was confirmed with manually entered or uploaded records. |
July 22, 2022 | IFS BOLO 13.9.18.0 | IFS iLandMan Current Version | Issue: Triggers are utilized within BOLO to effectively manage the processing within specific applications. The Triggers associated with multiple processes were not included in the upgrade and new install scripting executed by Managed Services.
Update and Delete Triggers are automatically managed with the Upgrade and New Install for:
|
Feb 17, 2023 | IFS BOLO 13.9.23.0 | IFS iLandman Current Version | Issue: When Users reference a Default Bank Account for Accounts Payable (AP1201), the same Account ID or Account Code could not be referenced within the InterOp Settings (INT1201) setup screens.
|
IFS BOLO and IFS AFE | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
March 5, 2019 | IFS BOLO 13.8 | IFS AFE 7.4 | Base version support for Vendors, Participants, AFE Actual, AFE Profile, Chart of Accounts, Division of Interest, Wells, AFE header, AFE Budget and Non-well Cost Centers. |
March 19, 2019 | IFS BOLO 13.8.1 | IFS AFE 7.4 | Issue: When the Well from the WELL.INFO was transferred successfully to IFS AFE, the County ID and the County Name were not displaying the correct attributes within the IFS AFE application. Resolution: Modified the IFS BOLO application to correct the mapping within IFS BOLO to the JSON attributes for countyParishID and countyParish. |
Aug 27, 2019 | IFS BOLO 13.8.7.0 | IFS AFE 7.4 | Issue: When the region settings on the Webservices server were not set to United States, the Webservices would fail to convert the accountingDate on the afe-actuals route. Resolution: Corrected accounting date to send the internal date to Webservices to allow proper conversion when the webservices server has non-US region settings. |
Aug 31, 2020 | IFS BOLO 13.8.18 | IFS AFE 7.4 | Issue: When integrating an AFE Profile from IFS BOLO into IFS AFE, the AFE Type being populated in IFS AFE was incorrectly populated with an account designation. Resolution: Corrected the AFE Profile sent from IFS BOLO to include the actual AFE Type so it populates correctly in IFS AFE. |
Aug 31, 2020 | IFS BOLO 13.8.18 | IFS AFE 7.4 | Issue: When integrating an AFE Profile from IFS BOLO into IFS AFE, the AFE Type being populated in IFS AFE was incorrectly populated with an account designation. Resolution: Modified the AFE Profile sent from IFS BOLO to include the actual AFE Type so it populates correctly in IFS AFE. |
Feb 20, 2020 | IFS BOLO 13.8.14 | IFS AFE 7.4 | Issue: When attempting to integrate Well records from IFS BOLO in a IFS BOLO/IFSAFE integration, IFS BOLO was incorrectly creating WEBSERVICEQUEUE records with an invalid WELL.INFO.eu*... prefix. Resolution: Modified logic for Well records being integrated from IFS BOLO to IFS AFE such that WEBSERVICEQUEUE records are created only with a valid WELL.INFO*... prefix. |
Feb 20, 2020 | IFS BOLO 13.8.14 | IFS AFE 7.4 | Issue: The IFS BOLO system was not correctly sending the appropriate accounts for an AFE template when:
Resolution: Modified the account population logic for AFE templates:
The contents of the accounts in the AFE template now match the source data in IFS BOLO. |
Apr 6, 2020 | IFS BOLO 13.8.16.0 | IFS AFE 7.4 | Issue: Saved List option for WELL.INFO records was not working in INT2301. WEBSERVICEQUEUE Resolution: When a user creates a saved list with WELL.INFO records and uses the INT2301 screen, those records are now being correctly sent to the webservicequeue. Records in webservicequeue are picked up by the interop to be sent over to another application like IFS AFE. |
May 20, 2020 | IFS BOLO 13.8 | IFS AFE 20.2 | Issue: When integrating a Well Header to IFS AFE, if a County Name was entered with a County ID that was longer than 10 characters and did not exist in IFS AFE, a generic error in the Interop History was returned. This issue was specific to IFS BOLO, IFS Excalibur, and IFS Enterprise Upstream integrations. Resolution: When integrating a Well Header to IFS AFE, if a County Name is entered with a County ID that is longer than 10 characters and does not exist in IFS AFE, the following error message is received when sending the data to the interop:
|
Aug 19, 2020 | IFS BOLO 13.8 | IFS AFE 20.3 | Issue: Creating an AFE without Site information caused setup and invoicing issues in the Financial System integrated with AFE. This affected integrations with IFS Enterprise Upstream, IFS BOLO, or IFS Excalibur. Resolution: The new AFE Configuration for Required Site, when set to YES for IFS Enterprise Upstream, IFS BOLO, or IFS Excalibur, will create an error message if site information is not entered on the AFE. |
Aug 19, 2020 | IFS BOLO 13.8 | IFS AFE 20.3 | Issue: When creating an AFE that contained an AFE Objective greater than the length permitted by the Financial System, the AFE failed to integrate fully with the Financial System. Resolution: When creating an AFE, IFS AFE validates the Objective field to ensure the description is within the maximum length permitted by the Financial System (Qbyte Financial, IFS Excalibur, IFS Enterprise Upstream, or IFS BOLO). If the description length exceeds the maximum, an error message is received: Unable to save changes due to the following errors - AFE Objective should be a maximum of ## characters. |
Aug 19, 2020 | IFS BOLO 13.8 | IFS AFE 20.3 | Issue: When integrating an AFE with a Financial System that contains an AFE Number greater than 10 characters, the AFE did not interop and the following error message was displayed: ORA-20000: ERROR in afes_api.insert_afe(): ORA-06502: PL/SQL: numeric or value error: character string buffer too small. Resolution: When creating an AFE that contains an AFE Number greater than 10 characters that will be integrated with a Financial System (Qbyte Financial, IFS Excalibur, IFS Enterprise Upstream, or IFS BOLO) an error message is displayed: Unable to save changes due to the following errors: AFE Number should be a maximum of 10 Characters. This validation will not apply to auto-generated AFE numbers. |
April 1, 2021 | IFS BOLO 13.8.24.0 | IFS AFE 20.3 | Issue: User was not able to complete InterOp for NonOperated Wells. InterOp failed with an error message indicating conflicts with Customer and Operator Usage Index codes. Resolution: The user is able to successfully complete the InterOp for Operated and Non-Operated Wells. Name record with Customer and Operator successfully merged to IFS AFE with Participant Web Service. No change to Online Documentation or Wiki Pages. Name and Address Maintenance within IFS BOLO remains unchanged. Name record must reference business role as "OP"erator to associate Name to Well record. Well continues to denote whether record is for an Operated or Non-Operated property. |
April 1, 2021 | IFS BOLO 13.8.25.0 | IFS AFE 20.3 | Issue: When there were multiple transactions with AFEs whose source was IFS AFE with the same accounting period in the Webservice Queue table, the transactions would integrate to IFS AFE with the incorrect accounts and amounts. Resolution: Now when the user stages multiple transactions with different AFEs, the transactions will pull the correct accounts and amounts from the TRANS table and integrate those transactions to the correct AFEs in the IFS AFE application via the ACTUALS route. |
Oct 20, 2021 | IFS BOLO 13.9.1.0 | IFS AFE 20.3 | Issue: User was not able to complete InterOp for NonOperated Wells. InterOp failed with an error message indicating conflicts with Customer and Operator Usage Index codes. Resolution: The user is able to successfully complete the InterOp for Operated and Non-Operated Wells. Name record with Customer and Operator successfully merged to IFS AFE with Participant Web Service. |
Oct 20, 2021 | IFS BOLO 13.9.2.0 | IFS AFE 20.3 | Issue: When there were multiple transactions with AFEs whose source was IFS AFE with the multiple accounting periods in the Webservice Queue table, the transactions would integrate to IFS AFE with the incorrect accounting periods. Resolution: Now when the user stages multiple transactions with different AFEs and different accounting periods, the transactions will be pulled with the correct accounting periods from the TRANS table and integrate those transactions to IFS AFE application via the ACTUALS route. |
Oct 20, 2021 | IFS BOLO 13.9.2.0 | IFS AFE 20.3 | Issue: When there were multiple transactions with AFEs whose source was IFS AFE with the same accounting period in the Webservice Queue table, the transactions would integrate to IFS AFE with the incorrect accounts and amounts. Resolution: Now when the user stages multiple transactions with different AFEs, the transactions will pull the correct accounts and amounts from the TRANS table and integrate those transactions to the correct AFEs in the IFS AFE application via the ACTUALS route. |
July 22, 2022 | IFS BOLO 13.9.18.0 | IFS AFE 20.3 | Issue: Triggers are utilized within BOLO to effectively manage the processing within specific applications. The Triggers associated with multiple processes were not included in the upgrade and new install scripting executed by Managed Services.
Update and Delete Triggers are automatically managed with the Upgrade and New Install for:
|
IFS Excalibur and IFS Land | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
Sep 6, 2019 | IFS Excalibur 8.3.7.1 | IFS Land 5.5.0.0 | Base version support for Leases, Check AP/Detail, Void Check, Invoice AR/Detail, Payee Suspense. |
June 3, 2019 | IFS Excalibur 9.0.5.0 | IFS Land 5.5.0.0
| Issue: When IFS Excalibur was consuming a IFS Land lease that did not belong to a specific company (Company value was null), IFS Excalibur did not build the Lease ID correctly in accordance with the default company setup in IO295 for the IFS Land integration. Resolution: Modified the P2API.LEASE subroutine to correctly create a Lease ID for leases that come from IFS Land without a specific company. The default company in IO295 for the IFS Land integration will be the Company value in the Lease ID for leases consumed that do not contain a Company. |
Sep 6, 2019 | IFS Excalibur 8.3.7.1 | IFS Land 5.5.0.0 | Issue: The Invoices Route was failing with the error message "IFS Land is set to NOT process receivable invoices." when the "Print Checks and JIB Invoices from Accounting" configuration is selected in IO295. Resolution: The error messaging in the IFS Connector has now been updated to the following: "Receivable Web Service is NOT required. Customer Billing Invoices will be generated through standard Excalibur JIB Processing." This properly communicates there is no need to run the Receivables Route for IFS Land if "Print Checks and JIB Invoices from Accounting" is selected in IO295. |
Oct 28, 2019 | IFS Excalibur 9.0.17.0 | IFS Land 5. 11.0.0 | Issue: The Invoices Route is failing with the error message "IFS Land is set to NOT process receivable invoices." when the " Pr i nt Checks and JIB Invoices from Accounting " configuration was selected in IO295 . Resolution: The error messaging in the IFS Connector has now been updated to the following: "Receivable Web Service is NOT required. Customer Billing Invoices will be generated through standard Excalibur JIB Processing." This properly communicates there is no need to run the Receivables Route for IFS Land, if " Print Checks and JIB Invoices from Accounting" is selected in IO295 . |
Jul 2, 2020 | IFS Excalibur 9.0.27.0 | IFS Land 5.13.0.0 | Issue: Updates to Leases already interoped to IFS Excalibur from IFS Land were overwriting LEASE_DETAIL data. Resolution: The Lease interoperability has been modified to no longer overwrite existing LEASE_DETAIL records. |
Oct 22, 2020 | IFS Excalibur 9.0.29.0 | IFS Land 5.9 | Issue: When IFS Land Interoperability was active in IO295, the Return Receipt option was not available in AP255. Resolution: This has been corrected to always allow the Return Receipt report as a printing option in AP255. |
Oct 22, 2020 | IFS Excalibur 9.0.29.0 | IFS Land 5.9 | Issue: The standard GL annotation for IFS Land Check Payments was IFS Land Delay Rental. Some transactions tied to IFS Land Checks are not Delay Rental payments. Resolution: The standard GL annotation has been updated to IFS Land Payment. |
Oct 22, 2020 | IFS Excalibur 9.0.29.0 | IFS Land 5.9 | Issue: GL transactions generated from void checks interoped from IFS Land were not referencing the Lease ID tied to the transaction. Resolution: Void related GL transactions now carry a reference to the Lease ID. |
Oct 22, 2020 | IFS Excalibur 9.0.29.0 | IFS Land 5.9 | Issue: IFS Excalibur was incorrectly consuming checks belonging to expired vendors. Resolution: Modified the P2API.INVOICEPAYABLES program to validate incoming checks for expired vendors. IFS Excalibur will no longer accept checks that belong to vendors that are expired. |
Nov 20, 2020 | IFS Excalibur 9.0.30.0 | IFS Land 5.9.0.0 | Issue: When Certex printing was active for IFS Land checks, the Certex print language was not appearing on the LRCHK check file. Further, the Lease ID suffix was being truncated on the report. Resolution: The LRCHK check print file now properly contains the Certex print language when Certex printing is active for Land checks in COM294. The full Lease ID also displays on the check. |
Feb 22, 2021 | IFS Excalibur 9.0.32.0 | IFS Land 5.16.0.1 | Issue: Release of Suspense and subsequent check payment of the released amount could not properly be tracked via the Checks & Invoices API Service from IFS Land to IFS Excalibur. The required GL entries and GL entry detail were not being generated as needed when Suspended payments were released and paid/re-issued. Resolution: Two new data elements have been added to the Checks & Invoices API Service, suspenseReleaseFlag and suspenseGlAccountId. A check entry with the suspenseReleaseFlag set to "Y" and an assigned account value in suspenseGlAccountId will now be recognized as a release of suspense equal to the amount of the check payment. The Suspense Account for the applicable Land Payment issued will be debited for the amount of the payment, and the Accounts Payable Trade account will be credited. The GL entries created will reference the release of suspense and the lease associated with the payment. When the check is printed in AP255, the same Accounts Payable Trade account will be debited, along with a credit entry to the cash account assigned for the payment type. Additions to Suspense from IFS Land to IFS Excalibur are still handled through the Suspense Maintenance API Service. |
July 23, 2021 | IFS Excalibur 9.0.35.0 | IFS Land 5.16.01 | Issue: Programmatic references to data items and code tied to the now obsolete IFS Land Broker / Excalibur Interop were causing some IFS Excalibur processes to fail, particularly EDI jobs referencing the AP.SHLD program. Resolution: All references to the IFS Land Broker Interop code and data elements have been removed from the base IFS Excalibur releases. |
July 23, 2021 | IFS Excalibur 9.0.35.0 | IFS Land 5.16.01 | Issue: When a check record from IFS Land containing more than one line of detail in the JSON is sent to IFS Excalibur, the multiple detail information is being concatenated into a single data element. These then do not validate properly against the data setups in IFS Excalibur, and the interop is failing with 400 data validation errors. Resolution: Modified Web Services to correctly pass multiple details lines as multi-value lines instead of multi-sub-value lines. |
July 23, 2021 | IFS Excalibur 9.0.38.0 | IFS Land 5.16.0.1 | Issue: The entry to clear the suspense account created via the IFS Land to IFS Excalibur Payables interop did not contain a JIB_TRANSFER_DATE. This was causing the entry to get selected for JIB Distribution (JIB210). These entries should not be part of JIB Distribution and will cause an abort of JIB210. Resolution: The suspense clearing entry now is created with a JIB_TRANSFER_DATE equal to the date the Payables interop was processed. |
July 23, 2021 | IFS Excalibur 9.8.38.0 | IFS Land 5.16.0.1 | Issue: The UTM entry to the 8/8ths billing account created by the P2API.INVOICEPAYABLES API contains a default JIB_TRANSFER_DATE value. This entry should not have a JIB_TRANSFER_DATE populated as it needs to be processed through JIB Distribution. Resolution: The UTM entry tied to the 8/8ths GL billing account is now created without a JIB_TRANSFER_DATE populated. |
July 23, 2021 | IFS Excalibur 9.8.38.0 | IFS Land 5.16.0.1 | Issue: The IFS Land to IFS Excalibur Suspense API subroutine was erroneously populating a JIB_TRANSFER_DATE on the UNPOSTED_TRANSACTION_MASTER record for the 8/8ths billing account. Resolution: Modified to properly leave the JIB_TRASFER_DATE null on all UTM entries containing a billable JIB GL account. |
Oct 6, 2021 | IFS Excalibur 9.0.39.0 | IFS Land 5.16.0.1 | Issue: AP255 Check Printing for IFS Land is not handling the Legal Description portion of the P2LAND_REMARKS taken from the APCR file. The Legal Description content is being accumulated on each successive check printed on the LRCHK and LLRCPT reports. Resolution: Each check on the report now only shows the Legal Descriptions tied to that particular payment. |
IFS Excalibur and IFS AFE | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
Jan 17, 2020 | IFS Excalibur 9.0.16.2 | IFS AFE 7.4.0.0 | Base version support for Vendors, Participants, AFE Actual, AFE Profile, Chart of Accounts , Division of Interest , Wells, AFE Header, AFE Budget and Non-well Cost C enters . Note: We do not support REST services for IFS AFE on any version prior to IFS Excalibur 9.0.16.2. No IFS Excalibur 8.3 client can implement IFS AFE without upgrading to IFS Excalibur 9. |
Jan 9, 2020 | IFS Excalibur 9.0.1 9.01 | IFS AFE 7.4 | Issue: The API program in IFS Excalibur to create AFE Header records from IFS AFE was creating "shell" AFE records when the interop would fail due to a data validation issue. Data validations should result in no data being created in IFS Excalibur. Resolution: The API program has been corrected to not create any records until full data validations have taken place. Further error messaging has been updated to clearly reflect the error condition. |
Jan 22, 2020 | IFS Excalibur 9.0.19.2 | IFS AFE 7.4.0.0 | Issue: The API program in IFS Excalibur to create AFE Header records from IFS AFE was creating "shell" AFE records when the interop would fail due to a data validation issue. Data validations should result in no data being created in IFS Excalibur. Resolution: The API program has been corrected to not create any records until full data validations have taken place. Further error messaging has been updated to clearly reflect the error condition. |
Feb 20, 2020 | IFS Excalibur 9.0.22.1 | IFS AFE 7.4 .0.0 | Issue: The selection of WSQ items for processing by the API programs was limiting the batch size to 10 records. This caused severe processing delays when executing routes through the IFS Connector for the processing of master record items over to IFS AFE. Resolution: The batch selection size in the API programs has been updated to 1000 records. Issue: WSQ items that did not validate correctly in IFS AFE from IFS Excalibur were not getting cleared from the WSQ after initial processing. WSEQ items were being created correctly. The WSQ items need to be cleared in all instances. Improperly validated records can be analyzed via the WSEQ data, corrected, and then re-staged to the WSQ. Resolution: WSQ items are now cleared in all instances after they are processed by their respective IFS API programs. |
Mar 16, 2020 | IFS Excalibur 9.0.22.0 | IFS AFE 7.4 .0.0 | Issue: The auto-generation of AFE IDs can be set on the IFS AFE side, and IDs with lengths of at least 10 characters are supported. The client expectation is that this character limit will work within IFS Excalibur for AFE IDs and associated Cost Center Master IDs. IFS Excalibur supports IDs of up to 14 characters in length for these records; however, the IFS Excalibur AFE Header API has logic to add a company prefix and a trailing A to the Cost Center ID being passed back to IFS Excalibur. This addition is resulting in ID length validation errors when these AFE/Cost Center Master IDs from the API exceed 14 characters. Resolution: The AFE Header route now only validates against the AFE ID limitation, which is 10 characters. The Cost Center Master ID created now matches the AFE Master ID. Issue: API Programs sending data from IFS Excalibur to IFS AFE were not functioning as expected when one record did not pass validation against existing IFS AFE data. For example, AFE Actuals from IFS Excalibur that did not have a corresponding AFE record in IFS AFE would error as expected, but all subsequent valid records would not be allowed to interop successfully. Resolution: Error handling logic in the Well Header, Participants, COA, Vendors, DOI, and Actuals API programs has been updated to not stop the passing of staged data just because one record fails validation. Validation errors will still communicate properly for failed records in IFS AFE, IFS Connector, and IFS Excalibur. |
Apr 6, 2020 | IFS Excalibur 9.0.23.0 | IFS AFE 7.4 | Issue: The IFS Excalibur Interop of Customers (Participants) to IFS AFE required a Participant Detail record to be set up in LLR167, along with a Customer Detail record setup in CUS500. Only a Customer Detail record should be required for the interop of Customers (Participants) to IFS AFE. Resolution: The IFS Excalibur Participants API no longer validates against an existing PARTICIPANT_DETAIL record. Only a valid NAM_ADDRESS_MASTER and CUSTOMER_DETAIL record is required to successfully interop with IFS AFE. Issue: When a successful interop of a Well Header record took place, IFS AFE was sending back the IFS AFE XPRIME ID as the record ID to clear the corresponding Web Service Queue (WSQ) item. The IFS Excalibur API program was expecting the Well ID and not the IFS AFE XPRIME ID. When these values differed, IFS Excalibur was not properly clearing the WSQ item, which resulted in a 400 error communicated through the IFS Connector. Resolution: IFS Excalibur now validates the incoming WSQ clearing message from IFS AFE against the XPRIME value on the associated WELL_MASTER file. This ensures the records will properly clear each time they are successfully processed. Issue: The AFE Header Interop from IFS AFE to IFS Excalibur was failing for AFE Master records referencing a non-well cost center. This was due to the IFS Excalibur API program requiring a valid Well ID on all AFE Header records coming from IFS AFE. IFS AFE and IFS Excalibur both allow AFE Header records to be set up with well cost center, non-well cost center, and no cost center references. Resolution: AFE Header items associated with non-well cost centers now successfully interop to IFS Excalibur. In addition, the existing non-well cost center is properly added to the AFE Master as the cost center reference. Issue: WSQ items that did not validate correctly in IFS AFE from IFS Excalibur were not getting cleared from the WSQ after initial processing. WSEQ items were being created correctly. The WSQ items need to be cleared in all instances. Improperly validated records can be analyzed via the WSEQ data, corrected, and then re-staged to the WSQ. Resolution: WSQ items are now cleared in all instances after they are processed by their respective IFS API programs. |
Jun 16, 2020 | IFS Excalibur 9.0.26.0 | IFS AFE 7.4 | Issue: When Budget Estimates data is sent from IFS AFE to IFS Excalibur for an AFE record that does not yet exist in IFS Excalibur, incorrect error messaging was being received in IFS AFE, IFS Connect, and IFS Excalibur. Additionally, a "shell" AFE_MASTER record was being erroneously created in IFS Excalibur. Resolution: When Estimates are sent over for a non-existent AFE, error messaging has been updated to clearly communicate this condition. Further, the "shell" AFE_MASTER record is no longer being created when the Estimates route fails under this scenario. |
Feb 22, 2021 | IFS Excalibur 9.0.32.0 | IFS AFE 7.4.0.0 | The IFS AFE to IFS Excalibur AFE Header Interop program will now do a validation to confirm if the well associated with the incoming AFE has an existing and active JIB deck. If no JIB deck or no active JIB deck is found for the incoming AFE's associated well, a warning message will be communicated in the IFS Excalibur WSEQ file, the IFS AFE Interop Queue and Interop History, and the IFS Connector Log. The AFE Header will still be created in IFS Excalibur, but the warning condition will be communicated on all three applications tied to the interop. |
May 20, 2020 | IFS Excalibur 9.0.27 | IFS AFE 20.2 | Issue: When integrating a Well Header to IFS AFE, if a County Name was entered with a County ID that was longer than 10 characters and did not exist in IFS AFE, a generic error in the Interop History was returned. This issue was specific to IFS BOLO, IFS Excalibur, and IFS Enterprise Upstream integrations. Resolution: When integrating a Well Header to IFS AFE, if a County Name is entered with a County ID that is longer than 10 characters and does not exist in IFS AFE, the following error message is received when sending the data to the interop: County Parish Id' must be between 0 and 10 characters. |
Aug 19, 2020 | IFS Excalibur 9.0.27 | IFS AFE 20.3 | Issue: Creating an AFE without Site information caused setup and invoicing issues in the Financial System integrated with AFE. This affected integrations with IFS Enterprise Upstream, IFS BOLO, or IFS Excalibur. Resolution: The new AFE Configuration for Required Site, when set to YES for IFS Enterprise Upstream, IFS BOLO, or IFS Excalibur, will create an error message if site information is not entered on the AFE. |
Aug 19, 2020 | IFS Excalibur 9.0.27 | IFS AFE 20.3 | Issue: When creating an AFE that contained an AFE Objective greater than the length permitted by the Financial System, the AFE failed to integrate fully with the Financial System. Resolution: When creating an AFE, IFS AFE validates the Objective field to ensure the description is within the maximum length permitted by the Financial System (Qbyte Financial, IFS Excalibur, IFS Enterprise Upstream, or IFS BOLO). If the description length exceeds the maximum, an error message is received: Unable to save changes due to the following errors - AFE Objective should be a maximum of ## characters. This validation will not apply to auto-generated AFE numbers. |
Aug 20, 2020 | IFS Excalibur 9.0.28 | IFS AFE 7.4 | Issue: When a supplemental AFE was approved in IFS AFE, the update to IFS Excalibur was not taking place. Further, if two or more supplements were sent to IFS Excalibur on the same day, the previous supplement is getting overwritten. Resolution: Supplemental approval in IFS AFE now properly updates the supplemental detail in AFE100F with an approval date. This prevents submission of a 2nd supplemental with the same date from overwriting the previous supplemental amounts. |
April 5, 2021 | IFS Excalibur 9.0.34.0 | IFS AFE 21.2 | Unapproved AFEs deleted in IFS AFE will now trigger an Interop record to IFS Excalibur. A new IFS Connector route (AFEHeaderDelete) will process this new Interop record into IFS Excalibur. The AFE Master record in IFS Excalibur will be updated with a Closed Date matching the deletion date of the record in IFS AFE. A comment will also be added to the IFS Excalibur AFE Master indicating the AFE was deleted in IFS AFE and the date of the occurrence. If the Cost Center Master associated with the AFE is an AFE Type, it will be deleted. If the Cost Center is not directly tied to the AFE Master record, it will not be deleted, but its association to the AFE Master record will be removed. |
July 23, 2021 | IFS Excalibur 9.0.38.0 | IFS AFE 21.2 | Issue: The AFE Header route process to interop a Close Date to IFS Excalibur was failing due to a bad date format error. Resolution: The formatting error has been corrected. The AFE Header route to IFS Excalibur will now properly update the AFE Master with a Closed Date when the Closed Date is included as part of the AFE Header record update. |
July 23, 2021 | IFS Excalibur 9.0.38.0 | IFS AFE 21.2 | Issue: When AFE Master records are created via the IFS AFE to IFS Excalibur Interop, the Net Decimal value in IFS Excalibur is set to 1.00000000. Manual update of this value to accurately reflect the true insider Net Value was getting overwritten back to 1.00000000 in the IFS AFE / IFS Excalibur Workflow when the AFE Approval interop occurred. Resolution: AFE Header interop from IFS AFE to IFS Excalibur will no longer overwrite a Net Decimal value other than 1.00000000 when it is present on the AFE_MASTER in IFS Excalibur. |
July 23, 2021 | IFS Excalibur 9.0.38.0 | IFS AFE 21.2 | Issue: IFS AFE has added configuration which will allow an AFE to be closed regardless of status. IFS Excalibur currently will only allow an AFE to be closed via the interop if it is in an approved status, with all associated supplemental budgets also in an approved status. Resolution: Functionality specific to the IFS AFE / IFS Excalibur interop ONLY has been added to allow the IFS Excalibur AFE_MASTER to be updated with a CLOSE_DATE if the AFE Closure has been initiated from the IFS AFE application, regardless of the AFE status in IFS Excalibur. AFE closure functionality outside of the IFS AFE / IFS Excalibur interop has not been changed. Adding a CLOSE_DATE to an AFE_MASTER from within the IFS Excalibur application is still subject to the same validations as before. |
Nov 11, 2021 | IFS Excalibur 9.0.38.0 | IFS AFE 21.4 | When IFS AFE integrates with IFS Excalibur, you can cancel an AFE in IFS AFE and send the cancellation as a Closed AFE to IFS Excalibur. When canceling an AFE, you can write a reason for cancellation that is appended to the Justification field. Also, the Cancelled status can be seen in the filter criteria of reports in IFS AFE. The AFE List report also displays the Reason for cancellation as well as the Cancelled status. The Cancellation functionality can only take place if the Cancel/Close AFE by Owner is set to Yes on the AFE Configuration page. |
Feb 1, 2022 | IFS Excalibur 9.0.40.0 | IFS AFE 21.4 | Issue: COAM records triggered to the WSQ for interop to IFS AFE from IFS Excalibur were being staged with the company prefix as part of the COAM ID. IFS AFE already has the logic to determine the company ID based on the default company setups with the application. As a result, this value was being duplicated when the AFE Budgets were sent back to IFS Excalibur via the Estimates route.
Resolution: The COAM-triggered record to the WSQ in IFS Excalibur will now only contain the value for the major/minor account code and will exclude any company prefix. |
Feb 1, 2022 | IFS Excalibur 9.0.43.0 | IFS AFE 21.4 | Issue: EDI Jobs processing against the SHLD.AFE program were experiencing index array errors that would abort a user’s session. Resolution: SHLD.AFE has been updated to prevent these index array errors when certain EDI jobs are processed. |
Oct 31, 2022 | IFS Excalibur 9.0.49.0 | IFS AFE 21.4 | Issue: Subsequent processing of the IFS AFE Header API to IFS Excalibur was causing AFE_DETAIL amounts to double for the records tied to cutback (net) accounts. Resolution: Updates have been made to the SHLD.AFE program to correct this issue when the IFS AFE Header API is processed more than once against an AFE with Budget Detail. |
Jan 18, 2023 | IFS Excalibur 9.0.51.0 | IFS AFE 21.4 | Issue: A well change on an unapproved AFE was not allowed via the IFS AFE to Excalibur Interop. Resolution: Well changes can now be made against unapproved AFEs in IFS AFE and successfully updated in Excalibur via the IFS AFE Header API. |
IFS Enterprise Upstream and IFS AFE | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
| IFS Enterprise Upstream 13.03.00 /12.49.00 | IFS AFE 7.4 | Base version support for Vendors, Participants, AFE Actual, AFE Profile, Chart of Accounts, Division of Interest, Wells, AFE Header, AFE Budget, Field Estimates and Non-Well Cost Centers. |
May 20, 2020 | IFS Enterprise Upstream 13.04.00 /12.50.00 | IFS AFE 20.2 | Issue: When integrating a Well Header to IFS AFE, if a County Name was entered with a County ID that was longer than 10 characters and did not exist in IFS AFE, a generic error in the Interop History was returned. This issue was specific to IFS BOLO, IFS Excalibur, and IFS Enterprise Upstream integrations. Resolution: When integrating a Well Header to IFS AFE, if a County Name is entered with a County ID that is longer than 10 characters and does not exist in IFS AFE, the following error message is received when sending the data to the interop:
|
Aug 19, 2020 | IFS Enterprise Upstream 13.04.02 /12.50.02 | IFS AFE 20.3 | Issue: Creating an AFE without Site information caused setup and invoicing issues in the Financial System integrated with AFE. This affected integrations with IFS Enterprise Upstream, IFS BOLO, or IFS Excalibur. Resolution: The new AFE Configuration for Required Site when set to YES for IFS Enterprise Upstream, IFS BOLO, or IFS Excalibur will create an error message if site information is not entered on the AFE. |
Aug 19, 2020 | IFS Enterprise Upstream 13.04.02 /12.50.02 | IFS AFE 20.3 | Issue: When creating an AFE that contained an AFE Objective greater than the length permitted by the Financial System, the AFE failed to integrate fully with the Financial System. Resolution: When creating an AFE, IFS AFE validates the Objective field to ensure the description is within the maximum length permitted by the Financial System (Qbyte Financial, IFS Excalibur, IFS Enterprise Upstream, or IFS BOLO). If the description length exceeds the maximum, an error message is received: Unable to save changes due to the following errors - AFE Objective should be a maximum of ## characters. |
Aug 19, 2020 | IFS Enterprise Upstream 13.04.02 /12.50.02 | IFS AFE 20.3 | Issue: When integrating an AFE with a Financial System that contains an AFE Number greater than 10 characters, the AFE did not interop and the following error message was displayed: ORA-20000: ERROR in afes_api.insert_afe(): ORA-06502: PL/SQL: numeric or value error: character string buffer too small. Resolution: When creating an AFE that contains an AFE Number greater than 10 characters that will be integrated with a Financial System (Qbyte Financial, IFS Excalibur, IFS Enterprise Upstream, or IFS BOLO) an error message is displayed: Unable to save changes due to the following errors: AFE Number should be a maximum of 10 Characters. This validation will not apply to auto-generated AFE numbers. |
Feb 2, 2021 | IFS Enterprise Upstream 13.04.02 /12.50.02 | IFS AFE 21.1.0.0 | Actuals report was not displaying balances correctly when negative amounts were sent from the Financial System. |
IFS Enterprise Upstream and IFS Merrick | |||
Date | Minimum Version | Minimum Version | Details/Enhancements Impacting Integration |
| IFS Enterprise Upstream 13.03.00 /12.49.00 | IFS Merrick 3.8 | Base version support for Wells, Well Status, Operator/Purchaser, Daily Volumes, Summarized Daily Volumes, Monthly Volumes and Used by Accounting. |
Aug 16, 2019 | IFS Enterprise Upstream 13.03.01 /12.49.01 | IFS Merrick 3.11 | Issue: Duplicate records were being created in the completion monthly staging tables when a Gathering system was unlocked, then locked, and saved. Resolution: Before records are inserted into the monthly staging tables, any existing records will be deleted to prevent duplicate records from being created. |
Nov 4, 2020 | IFS Enterprise Upstream 13.04.04 /12.50.04 | IFS Merrick 3.8 | Issue: Error when creating PPA's from Merrick. Resolution: Modified the APT API to handle PPA's from Merrick. |
June 18, 2021 | IFS Enterprise Upstream 13.04.01/12.50.01 | IFS Merrick 4.1.0.1 | Issue: The default interop metadata was missing the Meter TMP field on the Meter Basic screen. This is a display issue and only impacts customers using IFS ProCount interoperability with IFS Enterprise Upstream and IFS BOLO. Resolution: Added the Meter TMP field to the default interop metadata. |
Feb 9, 2022 | IFS Enterprise Upstream 13.04.01/12.50.01 | IFS Merrick 4.6 | Issue: Interop trigger, tr_CompletionDailyDispTb, caused deadlocks during the Auto Allocations process. Resolution: Removed interop trigger, tr_CompletionDailyDispTb, on CompletionDailyDispTb, and replaced the trigger functionality with code. |
Feb 9, 2022 | IFS Enterprise Upstream 13.04.01/12.50.01 | IFS Merrick 4.7 | Issue: The plant gas dispositions from a gathering system with plant inlet meters did not get staged to IFS ProCount's CompletionDailyDispSt staging table after locking the gathering system. This issue caused the ProCount-EU interop daily route to leave out the necessary plant gas dispositions integration from IFS ProCount into IFS Enterprise Upstream. Resolution: Modified IFS ProCount to stage the plant gas dispositions to CompletionDailyDispSt when locking the corresponding gathering system. |
Feb 9, 2022 | IFS Enterprise Upstream 13.04.01/12.50.01 | IFS Merrick 4.7 | Issue: The monthly volumes for some gathering systems were not inserted into the expected staging tables, CompletionMonthlySt and CompletionMonthlyDispSt. https://ifsenr.atlassian.net/wiki/pages/editpage.action?pageId=86638914This issue only occurred on a gathering system's first lock. Subsequent locks yield desired results. Resolution: Modified IFS ProCount Interop Monthly Volume Trigger so that the monthly disposition records associated with the locked gathering system are staged to CompletionMonthlySt and CompletionMonthlyDispSt. |
January 19, 2022 | IFS Enterprise Upstream 13.05.05/12.51.05 | IFS Merrick 4.7 | Issue: For clients using Merrick Production, the Accrual Estimated Daily Volumes Extraction Process (Report Set) was not creating accrual volumes when processing at the Other RC level. It was only working when processing at the TMP level. Resolution: Modified the Accrual Estimated Daily Volumes Extraction Process (Report Set) to pull in accrual volumes for both Other RC Level (ie completion) and TMP. This is for both regular dailies and summarized dailies. |
Oct 20, 2022 | IFS Enterprise Upstream 13.05.05/12.51.05 | IFS Merrick 4.8 | Added a new Integration Status screen in ProCount to view the monthly integration status between ProCount and the financial system (EU/BOLO) for records from the CompletionMonthlyDispSt table with a status of 'E,' 'T,' 'W.'
|
May 19, 2023 | IFS Enterprise Upstream 13.05.05/12.51.05 | IFS Merrick 4.11.0.0 | Issue: When an allocation meter is placed between the LACT and the tank, the meter became the new source. As the meter lacks a LACT ticket, the Interop failed to pass the start and end dates, leading to EU validation errors. Resolution: Modified ProCount to improve data handling and prevent EU validation errors by implementing the following changes:
|
Copyright© 2024 IFS AB. Copying prohibited. All rights reserved.