10.2 resolved issues

Issue: After Curtailment tables are purged, performance degradation is observed in the Interval Billing processing (4 times slower). This is because 1 of the procedures always attempts to build the map tables when there is no data in the Curtail Event table.

Resolution: The procedure's logic has been corrected. Once the map tables have been built, even when there is no data in the Curtail Event table, it will no longer tries to build the map tables again. In the scenario above, the performance degradation is no longer observed.

Issue: The HVBE Entity Purge stored procedure, which is part of the AMI Billing Export task adapter, fails due to deadlock almost every day.

Resolution: The HVBE Entity Purge stored procedure has been corrected for both Oracle and SQL Server database environments. To avoid deadlock, records from the HVBERequest table are deleted based on the content of the chunk table.

Issue: On Oracle based systems using a rolling demand billing aggregation calculation, when max demand is found in the last interval of a TOU period the max demand could be included in the rolling average in the adjacent TOU period.

Resolution: Modifications were made to eliminate any average of rolling demand across TOU boundaries.

Issue: On an Oracle based system that uses a rolling demand billing calculation, the rolling demand is sometimes calculated incorrectly. This is because when there are multiple versions of the read, ABE does not pick the latest read to calculate the rolling demand. This issue only occurs on Oracle database environments.

Resolution: The code has been corrected. In this scenario, ABE now picks the latest read and calculates the rolling demand correctly.

Issue: When certain fields included in the AMI Billing Export screen do not contain data the Diagnostics screen would fail to respond.

Resolution: Changes were made to the ABE Diagnostics User Interface logic when evaluating the results from the database and handled scenarios of missing values or configuration information. This results in the UI responding in a timely fashion and allowing user to proceed with ABE diagnostics review.

Issue: Within the Rate Schedule user interface users can model the calculation of rates by performing a "Rate Analysis", in situations where the register and interval channel had the exact Unit of Measure the tool would reading data for both channels but the tool is intended only for interval-based calculations. The result would cause an error in the UI and not return expected determinants.

Resolution: We modified the logic when retrieving readings, if no interval channel is found with the correct UOM then we check for the channel with a complimentary UOM and limit results for the analysis tool to interval readings.

Issue: Due to an inefficient join statement, slow performance has been observed on the AMI Billing Determinant aggregation procedure for Oracle. This issue only affects Oracle environments.

Resolution: The join statement in the procedure has been corrected to use a subset of readings from temp table, and an index has been added on the temp table. The slow performance is no longer observed.

Issue: Loading the diagnostics screen in the AMI Data Export queue fails to respond when the MDM system contains hundreds of thousands of service points. The impact to the user was the screen would timeout and the application would become unresponsive.

Resolution: Changes were made to the User Interface logic when evaluating the results from the database and handled scenarios of missing values or configuration information. This results in the UI responding in a timely fashion and allowing user to proceed with ADE diagnostics.

Issue: The Stale Data Export (SDE) process triggered AMI Data Export (ADE) requests with an incorrect start date, which was before the service point's oldest readings in the database. This caused an excessive amount of exports because th start date was earlier than readings stored in the system.

Resolution: The SDE logic was corrected to trigger ADE using the correct start date and the ADE logic only exports back to the earliest stored readings.

Issue: On the AMI > Monitoring > ARI Dashboard screen, select Detail View. On the Detail View dialog that shows, the File Summary panel at the top shows there were reading files processed, but the Performance panel at the bottom does not show any readings. This is because the performance summary data is stored in Data Collection Window (DCW) time zone, while the UI fetches the information using UTC time zone and therefore is unable to find the data.

Resolution: The ARI Dashboard has been corrected to fetch performance summary data in DCW time zone. In the scenario above, the information is now shown in the Performance panel of the Detail View dialog.

Issue: When ARI operates, it creates Estimation Log and Estimation Log Detail file types. When these files contain duplicate rows, upon import to the database, a primary key constraint error occurs and the ARI task ends with error.

Resolution: The import process has been corrected to handle duplicate entries in the files. In this scenario, ARI import now runs successfully.

Issue: IEE is unable to transfer ARI clean reading files via SFTP to a Unix server. It could not connect via SFTP because the required Renci.SshNet.dll that was provided as a hot fix for v8.2 was not included in a later IEE version.

Resolution: The Renci.SshNet.dll has been added so that IEE can connect via SFTP. It is now available under the “C:\Program Files\Itron\Enterprise Edition\bin” folder.

Issue: ARI cleanup task was consuming resources and taking longer than expected.

Resolution: Due to a change in "clean reading" file formats in the past two file types "*.etf and *.etg" were removed from being generated during ARI processing. However, the ARI cleanup task was still looking for those file types when removing historical clean reading files. These file type checks were removed from the ARI cleanup process to avoid the overhead.

Issue: After changing the meter & service point link on the Configuration Maintenance UI, the UI froze (not responding) when clicking the Save button. This occurred when the service point configuration consists of more than 50 accounts in the history as the configuration update goes through the entire hierarchy in the history.

Resolution: The code has been corrected. It now only goes through the required node links instead of the entire configuration hierarchy. The configuration update is now completed successfully in seconds.

Issue: When decommissioning a meter, the system throws a Unique Constraint Violation when the Reading_PurgeByDate_SPC is called. This occurs when there are multiple reading groups with the same reading group alternate key, service point channel and start time, but with a different end time.

Resolution: The code has been corrected. In this scenario, the meter is now decommissioned successfully.

Issue: When a meter has multiple versions and a Configuration Export is requested with "Include All Versions" = false (to request only the latest version), the export fails with a null reference exception.

Resolution: The code has been corrected. In this scenario, the latest meter version is now exported successfully.

Issue: When changing a service point from one program to another, the channel sets were not correctly updated when a meter program change occurs on the same day as a removal is performed. The logic incorrectly applied the previous program's channel sets to the current program's channel sets during the reprogramming. This may prevent or delay billing.

Resolution: The logic was changed to update the current program channel sets.

Issue: A service point has channels that are linked to multiple meters, with the validation set assigned to the service point program. When one meter is exchanged with a new validation set, this new validation set is correctly assigned to the relevant channels. However, the validation set on the other channels are incorrectly end dated, resulting in missing reads not being validated after this date.

Resolution: The configuration logic has been corrected. In this scenario, validation set assignments are now as expected for all channels.

Issue: When entering GIS latitude/longitude values in the IEE GIS coordinates fields, if the location required a negative value to express the location the IEE user interface would not permit entry of the "-" negative sign by the user, however if entered via API call the database would store those values correctly. Examples include:

• Negative latitude coordinates lie South of the equator.

• Negative longitude is west of the prime meridian (a north-south line that runs through a point in England).

Resolution: The user interface control for entry of GIS coordinates was modified to allow for negative value entries.

Issue: A meter has been detached from a service point several years ago. When attempting to attach the same meter to another service point, this attempt fails with the following error: A recorded conversion error prevented a MeterChange. This is because the logic incorrectly attempts to update the original service point.

Resolution: The meter change logic has been corrected. It now refers to the correct service point, and the scenario above is now successful.

Issue: The IEE purge process would encounter an error attempting to purge readings that were previously deleted as part of an interval length change due to the setting which allows for removing data prohibiting a configuration change. This setting is: Purge Readings to Allow Interval Length Change set to the value of: "Logical delete". All other existing purging continued as normal.

Resolution: The purge process was modified to handle the situations where readings were logically deleted previously.

Issue: In the following scenario, • Export a service point configuration to XML • Update the configuration XML by adding a service point version • Import the updated configuration XML the configuration import fails with "Invalid End Date" error. This is due to incorrect validation set assignment to the different service point versions.

Resolution: The configuration import has been corrected. In the scenario above, the validation set is assigned correctly to multiple versions, and the configuration import is successful.

Issue: When a meter channel that was mapped to one service point channel later moved to another service point channel, any configuration updates that follow would fail with a "recorded conversion error" exception.

Resolution: The code has been corrected. This scenario is now handled correctly, and the configuration updates are now successful.

Issue: Audit log interface shows an error when log entries are related to a curtailment program, this prohibits the user from seeing the audit log entries.

Resolution: Logic was updated to handle curtailment program related entities in the audit log interface so the entries will be visible.

Issue: ORACLE DB: For customers using Oracle and confirmed billing ID's when fetching data from the ADEREQUEST and HVBEENTITY tables performance can be impacted in those ADE and ABE export processes.

Resolution: Database indexes were placed on the CORRELATIONID field in the ADEREQUEST and HVZBEENTITY tables to improve query performance.

Issue: The Reading Purge by Partition procedure truncated the main partitioned table was incorrectly such that the corresponding periods in their dependent non-partitioned tables were not deleted. It also updated the ReadingPeriodWithStatusID (RPWSID) table with an incorrect status ID = 3.

Resolution: The Reading Purge by Partition procedure has been corrected. Data from all partitioned tables and their dependent non-partitioned tables is now purged correctly according to the purge settings, and the RPWSID table is updated with the correct empty status ID.

Issue: Historical purge process was not stopping processing even when the "End Time" was met, this results in the process taking more time and running longer than planned.

Resolution: The historical purge script was updated to capture the correct start time and evaluate the end time against that every time the process runs thereby limiting the run time to planned start and end time schedules.

Issue: The Reading Purge by Date SPC procedure fails with a unique constraint error (ITRONEE.PK_READINGGROUPSPC). This scenario occurs when multiple interval billing requests were submitted with the same start date but with different end dates in the same request file.

Resolution: The Reading Purge by Date SPC procedure was corrected to handle this scenario by comparing service point channels instead of the ReadingGroupAlternateKey.

Issue: To function as expected, IEE rich client needs to be run with local administrative privileges. This level of privilege is excessive.

Resolution: IEE rich client has been updated to support non-admin users.

Issue: IEE is shipped with a default account used by IEE rich client to connect to the database. This default account is expected to be changed with another database user which has the appropriate privileges for using the application. However, this instruction is not present in the documentation.

Resolution: IEE Configuration Guide has been updated. It now clarifies the need to change the default account and provides the instruction on how to do it.

Issue: Slow performance was observed in the updated ReadingPurgeByPartition procedure since IEE 10.1 and 9.0.23 release, taking hours longer than expected to complete.

Resolution: The ReadingPurgeByPartition procedure has been corrected and optimized. The purge now completes within the expected time.

Issue: Following IEE 10.1 upgrade, several test script entries (such as Julia test) are added to the SharedResource table.

Resolution: The issue has been corrected in IEE 10.2. The upgrade no longer adds test script entries to the SharedResource table.

Issue: When running Historical Purge the process was taking longer than needed when running against the ValidationLogHistory table due to processing that evaluated all partitions even those that did not contain candidate records for purging.

Resolution: The Validation Log History purge was updated only to evaluate those partitions which contained candidate data for purging. This improved the duration and overhead of the process.

Issue: The REFRESHREADINGPERIODWITHSTATUS procedure is incorrectly updating the MAXREADINGGROUPALTKEY. When running this procedure, the same MAXREADINGGROUPALTKEY value is used for all reading groups that have the same status for a given service point channel, with the potential of performance and billing impact.

Resolution: The procedure has been corrected. The MAXREADINGGROUPALTKEY is now updated correctly for all reading groups for a given service point channel, regardless of whether they share the same status or not.

Issue: Due to an error in the Reading_PurgeByDate_SPC stored procedure, an exception occurred when removing a meter. If the purge time period overlaps with or is a subset of the reading group's time period, the stored procedure did not update the reading group's start/end time correctly.

Resolution: The Reading_PurgeByDate_SPC stored procedure has been corrected. It now updates the start/end time correctly based on the purge time period. The configuration exception no longer occurs.

Issue: When the execution of Reading Purge by Partition task is completed, rows in the ReadingPeriodWithStatusId (RPWSID) table are updated with DELETED status ID (as expected). However, the Max Reading Group Alt Key on these rows are not updated and still show the old value. This causes a confusion as it appears that the reading groups still exist for the purged periods.

Resolution: Reading Purge by Partition has been corrected. The rows in the ReadingPeriodWithStatusId (RPWSID) table that are purged are now correctly updated with Max Reading Group Alt Key = 0.

Issue: When running IEE historical purge, files that should have been deleted were remaining in the system hours longer than the period defined by the system setting, this was due to using the server time on the database server as opposed to the UTC time zone.

Resolution: The IEE historical purge 'DELETEOLDERTHAN' variable is now based on the UTC time zone.

Issue: When issuing a contingency read as data was correctly received and imported from the Openway headend the detailed service logs would show a reference of "Object reference not set to an instance of an object", however the reads imported and the task was successful.

Resolution: Changes were made to the contingency read utility to improve logging and include the web service thread ID within the public web log details. The following is an example of the output in the logs: Itron.EE.Facade.Common.MeterDataCache:0 Add TaskID: 123345- Thread #13- added 5604 byte envelope header to the cache. Total cache size is now 329 bytes.

Issue: Openway device event mapping scripts IEE did not contain new events generated by Intelis gas meters, if one of those events was generated the event was banked at IEE.

Resolution: We added 46 new Intelis gas device events to the Openway event mapping script along with new core meter events in IEE. See Device Events and Mapping Changes.

Issue: Event mapping for "Temperature Returned From Above Threshold 1 to Normal" was missing in IEE.

Resolution: A new event mapping has been added. This event is mapped to the following existing event code: 18939 and event description: "Temperature Above Threshold 1 Restored to Normal". See Device Events and Mapping Changes.

Issue: When receiving device events from OpenWay head end through the Data Subscriber service, the historical events were incorrectly imported as alarms.

Resolution: The code has been corrected. Historical events and alarms are both imported correctly to IEE.

Issue: Event mappings did not exist for UIQ Riva meter events in IEE.

Resolution: Riva meter events added to IEE mapped to UIQ event ID's for UIQ customer implementations. See Device Events and Mapping Changes.

Issue: UOM and Device Event Mapping scripts for Openway contained ANSI encoded characters( “ , Â) which could cause problems in certain database deployments when running the installation of those scripts.

Resolution: The hidden characters were removed from all scripts.

Issue: 10.0 Data Dictionary for SQL server was missing updates on some field definitions related to timestamp formats and new 10.0, 10.1, and 10.2 tables.

Resolution: An updated database definition with all 10.2 (and previous) schema definitions was created and incorporated into the IEE 10.2 Data dictionary user guide.

Issue: The following issues were observed on the Edit Register Reads screen.

• When displaying a meter that has been installed at multiple service points, the Edit Register Reads screen lists all service points irrespective of the selected time period.

• When displaying a service point that has had multiple meter installations, the Edit Register Reads screen only includes the oldest/earliest meter in the selected time period.

Resolution: The Edit Register Reads screen has been corrected. The screen now works as expected in these scenarios.

Issue: The Two Week Like-Day Estimation statuses are not automatically marked on the intervals, so there is no way to know which estimation routine was used: 2 weeks or 52 weeks when looking at the readings in the database.

Resolution: The Two-Week Like Day Historical estimation routine was modified to mark estimated intervals with EST2WKLIKEDAY or EST52WKLIKEDAY depending upon the estimation set configuration.

Issue: The following fault was observed on the Manual Estimation's graph. Load a reading group for service point A from a few days ago on the Manual Estimation screen. After that, extend the End Date to the current date. Then load a reading group for service point B from a few days ago. Instead of applying the reading group's time range, the graph shows readings up until the current date. When changing the End Date to the current date, the graph then shows readings from 12/31/1899.

Resolution: The Manual Estimation's graph has been corrected. It now displays readings' time span correctly.

Issue: The Two-Week Like Day Historical estimation did not find eligible data when the like day was a holiday.

Resolution: The Two-Week Like Day Historical estimation routine extended the number of days to look back from 7 to 14 days.

Issue: For several Australian customers (on Oracle) who use custom Two Weeks Like Days Historical estimation and perform estimation for a gap, when TYPE59 status appears, the ESTIMATED status and GAP status are not present after estimation. This is because ESTIMATED status was included in the Status to Mark list (ESTIMATED, TYPE51). When marking alternate status, the ESTIMATED status was removed and the read was treated as actual.

Resolution: From the IEE 10.2 release package, navigate to ManualScripts folder. A new manual script is provided for Oracle (Update_EstimationParamet_Datavalue.pls) to remove the ESTIMATED status from the Status to Mark list. In the scenario above, this issue is no longer observed.

Issue: After a Peak Time Rebate (PTR) curtailment event is called, the Like Day Algorithm (LDA) ETL fails, leading to insufficient like days needed for PTR billing determinants calculation for the curtailment event participants. This issue only affects Oracle environments.

Resolution: The LDA logic has been corrected. The LDA now runs successfully and PTR billing determinants for the curtailment event participants can be calculated.

Issue: When data is imported with a routing program that exports the data immediately, the reading timestamps do not have any time zone indication (yyyy-mm-ddThh:mm:ss).

Resolution: The code has been corrected. The reading timestamps in the immediate export are in UTC with the correct date format (yyyy-mm-ddThh:mm:ssZ).

Issue: When performing installations in the following order:

• IEE 10.0

• IEE 10.0.3 service pack

• ISAIM 2.0

• Client Update Server

The Client Update installer removes evidence of ISAIM and IEE service pack installations from the installed programs list in Control Panel. There is no impact in functionality as the installed binaries remain in place.

Resolution: The installer has been corrected in IEE 10.2. The scenario above is no longer observed.

Issue: In the following scenario,

• A system has IEE 9.x or 10.x with ISAIM installed

• Upgrade the application server by install IEE 10.2 but do not install ISAIM

• Schedule a remote integration call

the AMI Remote Interrogation task fails with the following error: "Unable to find class File not found in IEESAPIntegration.Service.dll" even though the task does not require ISAIM binaries. This is because references to ISAIM binaries are still left in the database, resulting in the error.

Resolution: When installing IEE 10.2 application server, references to ISAIM binaries are removed. In this scenario, the error is no longer observed.

Issue: In circumstances where a webservice was called and the request was unable to be fulfilled for legitimate reasons, the fault was not handled properly and resulted in a generic response to the calling service with "HTTP status 500, indicating there is a server-side error". Circumstances of unhandled exceptions are as follows:

• When the user doesn't have permission for the service methods

• When the user is not part authorized in IEE and tries to invoke services

• When data elements are malformed and the Microsoft xml parsing method could not de-serialize the data

• With other invalid requests SOAP requests

Resolution: The errors are captured by our service and provided back in a readable format rather than the generic HTTP 500 error.

Issue: The Audit Log user interface shows all entries relevant to the selected object in the Audit Log Entry Details. However, for all entries, the Entity column shows the same label (i.e., object type such as Meter). This gives the impression to the user that what are shown are duplicate entries, even though there are no duplicate audit log entries in the database.

Resolution: The Audit Log Entry Details user interface has been enhanced to display additional information in the Entity column (e.g., effective date range, channel number), so that it is clear to the user that these are not duplicate entries.

Issue: When navigating away from the AMI Interactive Communications user interface, the following error is displayed: An error occurred fetching the settings: AMI Settings from database is null or invalid. Click OK to remove the error and continue.

Resolution: The issue has been corrected. In this scenario, the error is no longer observed.

Issue: Variations of KVA, KVAR, and KW delivered and received phase UOM's were not available in the IEE UOM maintenance. Resolution: Specific A,B,C phase version were added for KVA DEL and REC, KVAR DEL and REC, and KW DEL and REC. Refer to UOM Changes.

Issue: The following new UOM codes are needed for Riva meters.

• PF_DEL_ELE_MIN

• PF_DEL_ELE_MIN_A

• PF_DEL_ELE_MIN_B

• PF_DEL_ELE_MIN_C

• PF_DEL_ELE_MIN_D

• PF_DEL_ELE_MIN_E

• PF_DEL_ELE_MIN_F

• PF_DEL_ELE_MIN_G

• PF_DEL_ELE_MIN_H

• PF_REC_ELE_MIN

• PF_REC_ELE_MIN_A

• PF_REC_ELE_MIN_B

• PF_REC_ELE_MIN_C

• PF_REC_ELE_MIN_D

• PF_REC_ELE_MIN_E

• PF_REC_ELE_MIN_F

• PF_REC_ELE_MIN_G

• PF_REC_ELE_MIN_H

Resolution: The Add_UOMs script now includes the new UOM codes. Refer to UOM Changes.

Issue: Using the Customer Configuration API with the following scenario,

• Import meter configuration with Date Initialized specified

• Update & re-import the meter configuration, this time without Date Initialized results in the meter's Date Initialized value updated to beginning of time (BOT).

Resolution: The Customer Configuration logic has been corrected. In the scenario above, the meter's original Date Initialized value will be retained.

Issue: When using Advanced Configuration, the Service Point Channel Number field appeared to be editable but would not allow saving changes and resulted in an unhandled exception. Customers were not able to update the channel number value and save the change.

Resolution: The restriction on editing the channel number in the user interface was modified allowing the user to enter a new channel number in the Advanced Configuration Service Point Channel > Channel Number field and save the changes.

Issue: Starting in IEE 10, in System Admin > Preferred Reading Status List when selecting multiple reading statuses to make "preferred statuses", the IEE user interface "Save" button would not show as enabled, prohibiting changes to your preferred reading status selections.

Resolution: The component used for listing and selecting statuses was updated to allow multiple selection AND the UI control now allows for saving the changes.

Issue: In circumstances where a customer installed IEE using the ClickOnce client, if you use ClickOnce to launch from a different domain, such as remotely via VPN, IEE throws the following error as it does not recognize the domain you are logging in from: "Could not contact Login Service. this may be due to invalid endpoint configuration in client bootstrap or Login Service is not running". This is not a defect but a configuration change is required to enable cross domain authentication.

Resolution: The IEE configuration guide was updated to provide details on how to configure a custom binding for use by the ClickOnce client.

Issue: In circumstances where a webservice was called and the request was unable to be fulfilled because the user does not have permissions for the web service call the exception was unhandled resulting in HTTP 500 error. Examples include:

• When the user doesn't have permission for the service methods

• When the user is not part authorized in IEE and tries to invoke services

Resolution: The errors are captured by our service and provided back in a readable format rather than the generic HTTP 500 error, the response does not say that the user does not have permission.

Issue: Variations of KW and W delivered max cumulative UOM's were not available in IEE UOM maintenance.

Resolution: Versions of KW and W delivered max cumulative UOMs for phase A,B,C, and Previous billing were added to IEE UOM definitions. Refer to UOM Changes.

Issue: A corruption in the BillDetMap table leads to incorrect billing determinants. The calculated billing determinants are different from the values shown in the TOU report or Interactive Graphing. After a rebuild of the BillDetMap table, the billing determinants are correct.

Resolution: From the IEE 10.2 release package, navigate to ManualScripts folder. A new manual script is provided for both Oracle (Check_BillDetMap_Corruption.pls) and SQL Server environments (Check_BillDetMap_Corruption.sql).

• Run the Check_BillDetMap_Corruption script to detect discrepancies in billing determinants (Recommendation: run this prior to the billing cycle).

• If a corruption is identified (i.e., if the script indicates @MustRebuildMap = 1), run the rebuild stored procedure (HVBE_BillDet_Build in the IEE database) to rectify the issue.

Issue: The Stale Data Export is not exporting interval and register channels when there are more than one task templates defined. In this scenario, only one channel is exported.

Resolution: The Stale Data Export logic has been modified to export both interval and register channels regardless of the number of defined task templates.

Issue: Meter Reading Synchronizer (MRS) provides the timestamps for interval data in UTC date/time format (yyyy-mm-ddThh:mm:ssZ). But the timestamps for register data do not have any time zone indication (yyyy-mm-ddThh:mm:ss).

Resolution: The code has been corrected. The task template now has a new option to use UTC or service point time zone. In both cases, the timestamps for both interval and register data now have consistent date/time format. If UTC is selected, the date format is yyyy-mm-ddThh:mm:ssZ. If service point time zone is selected, the date format is yyyy-mm-ddThh:mm:ss with the time zone offset (+hh:mm or -hh:mm).

Issue: The task owner for MV90 Spreadsheet Export has been assigned to a workgroup with DDMMYYYY date format. However, the export produces a PRN file with MMDDYYYY date format. This is because during the export, the date format is incorrectly taken from the current user's workgroup which has MMDDYYYY date format.

Resolution: The logic has been corrected. The MV90 Spreadsheet Export now uses the date format defined in the task owner's workgroup.

Issue: When using Meter Reading Synchronizer (MRS) with AMI Reading Import, MRS exported an extra interval for every service point. For example, for a 24 hour period, it would export 97 intervals for a meter with 15 minute interval length, and 25 intervals for a meter with 60 minute interval length.

Resolution: The MRS logic has been corrected. It now no longer exports the extra interval.

Issue: The Stale Data Export (SDE) times out when attempting to populate several months’ worth of data into the temp table.

Resolution: The procedure that populates the data for SDE has been modified to use a new system setting: System Settings > AMI Billing Export > StaleDataExport Consider Reads Since. This setting defines the number of days that SDE should look back and include the readings. This period is applicable to both interval and register reads. The default value is 45 days. See also Reference 2437355 and 2438185.

Issue: When using SRI-E to import a reading XML file with several days of contiguous interval sets (without gaps) in the same file, the import creates multiple reading groups (one reading group per day).

Resolution: The import logic has been corrected.

• If the contiguous interval sets have no gap and there are no end reads, the import creates a single reading group.

• If the contiguous interval sets have gaps and/or there are end reads, the import creates multiple reading groups.

Issue: Stale Data Export procedure for Oracle takes hours to complete and may time out, because the procedure attempts to scan through data from the last several years. This issue is only observed in Oracle environments.

Resolution: The SDE procedure's logic has been corrected to limit the number of days up to 2 years and to fetch data with a better plan. In this scenario, the execution is now completed in minutes. See also Reference 2426911 and 2438185.

Issue: Running Stale Data Export (SDE) for around 100 meters took much longer to complete than expected (4 hours).

Resolution: To improve performance, the SDE logic has been corrected and index improvements have been introduced. In this particular scenario, SDE's processing time was improved from 4 hours down to 2 hours. See also Reference 2426911 and 2437355.

Issue: To fix issues in the ReadingPeriodWithStatusId (RPWSID) table, the following scripts were run: Fix_RPWSID_BeginningPeriod, Fix_RPWSID_Trailingperiod_post_upgrade, RefreshBadReadingPeriod. The first two scripts ran successfully, but the third script incorrectly deleted BOT entries, incorrectly updated the MaxReadingGroupAltKey, and ran for too long. The issue was caused by incorrect date comparison logic in the script.

Resolution: The script's logic has been corrected. The script now runs successfully.

Issue: Interactive Graphing Updates Resolution: Various enhancements were made to the interactive graphing controls to more easily illustrate and select channels and data when multiple channels are included in the graph. Changes include:

• When the user double clicks on the series legend (or somewhere on the series itself), the grid ss updated, and the color of the header becomes the same as the series that was double clicked

• If all series are visible (which is the default after the chart is displayed), and the user double clicks one - the others will be hidden, and their legends will become greyed out

• If the user double clicks the legend of a hidden series - it will become visible, and the others will be hidden

• If the user double clicks a visible series while others are hidden - all series will become visible again

Issue: The interactive Graphing screen did not allow the user to move the scroll bar to see all the readings when using some display resolutions, such as 1366x768, 1280x1024, and 1920x1080.

Resolution: The Interactive Graphing screen was enhanced to add a new splitter to allow the operator to see more of the chart or table.

Issue: For IEE Service mode customers while performing remote interrogations, when “Recorder not found” occurs in XI-comm, all of the recorders in the batch are retried instead of only the single recorder that did not respond.

Resolution: We changed the logic for the task rescheduling to only reschedule the specific recorder(s) that failed to respond instead of the entire batch.

Issue: Service mode cancelled tasks were not able to be cleaned up or deleted and therefore were being retried.

Resolution: When a user selects cancelled on a Remote Interrogation task the tasks are now deleted.

Issue: To capture "Loss Compensation Energy Registers" from EDMI Mark 6 meters, IEE needs to incorporate the new version of DCD_EDM6 TIM module (1.0.3.5) and add support for the new register decode tags.

Resolution: IEE now supports DCD_EDM6 TIM module version 1.0.3.5 and the new register decode tags for "Loss Compensation Energy Registers" from EDMI Mark 6 meters have been added.

Issue: When Service Mode is processing reading files in a batch, if a particular recorder does not exist in the database, the remaining files in the batch are not processed once this error occurs.

Resolution: Service Mode logic has been corrected. In this scenario, when a particular recorder does not exist, its reading file will be skipped and the remaining files in the batch will be processed successfully.

Issue: When validating UCE formulas that are written across multiple lines, an error message is displayed stating "The formula syntax is invalid. Syntax error in Calculation Engine formula..."

Resolution: The UCE (Universal Calculation Engine) parsing logic does not recognize a CR (Carriage Return) as whitespace. The UCE parsing logic has been enhanced to intercept CR and convert to whitespace. This allows formulas to be written across multiple lines.

Issue: The Send Settlement task can be scheduled on a recurring task schedule; however, there was no way to specific the date range that will be exported.

Resolution: The Send settlement task was enhanced to include an offset for both the start time and end time. For example, a recurring task is configured to start at 6AM each day but will send the settlements data from the previous day, from midnight to midnight, excluding the data from the midnight to 6AM.

Issue: The Settlement Code Types table does not allow spaces in the settlement point type ID field. The spaces need to align with existing ISO code types.

Resolution: The Settlement Code Types table and screens were enhanced to support spaces in the settlement point type ID field.

Issue: The Service Point Program (SPP) UDA default values do not propagate down to the Service Point instances that are created via a configuration API import file. The SPP UDA default values are propagating down to the Service point instances when the configuration change is initiated from the Configuration Maintenance UI. Although the instances can be manually updated, this workaround is not acceptable in the long run.

Resolution: The Configuration import logic was corrected so the SPP UDA default values are propagated to the Service Point instances. This only applies when the default values are included in the API file; otherwise, the specified UDA values are imported into the IEE system.

Issue: The initial Settlement Data Submission and Retrieval API was designed to only include readings end timestamps for consistency with our other readings APIs.

Resolution: Since our target markets require Start timestamps, we enhanced the Settlements REST API to include both Start and End timestamps for each reading.

Issue: The initial program-based configuration did not allow operators to decommission or correct existing Settlement Points.

Resolution: The program-based configuration API and User Interface were enhanced to allow operators to decommission, or end date, an existing STPT. Also, the changes allow operators to correct a Settlement Point ID.

Issue: The BestInterval UCE formula slows performance of aggregations when the formula includes invalid statuses in the UDA definitions. This may slow performance of graphing, refreshing a dashboard, etc.

Resolution: The BestInterval UCE logic was enhanced to ignore invalid interval statuses defined in the UDA definition and log a warning message. For example, the Interactive Graphing shows the message "Can't find Reading Status 'InvalidStatus' used in '@BestInterval' function, 'ExcludeStatuses' parameter for SPC 'SP111', the status will be ignored. When the formula is executed from a dashboard, the message is logged in the ItronEE_UIApplication log. When exporting using AMI Data Export, the message is logged in the ADE Task logs and can be seen in the Task Monitor.

Issue: The Settlements Dashboard was slow to refresh which delay the operators’ ability to perform their daily processes and submissions to the markets.

Resolution: During our investigations, we learned the primary cause was invalid Reading Statuses in some of the BestInterval Formulas defined on several Settlement Points. In issue 2443024, we enhanced the BestInterval UCE function to ignore invalid statuses and log warning messages to alert operators about the invalid status codes. We also optimized the Settlements Dashboard to reduce screen refresh time. We optimized the summary statistics calculation logic, and we no longer automatically load the Zone Settlements Summary > Monthly Settlements section. Finally, the operator must check the Monthly Settlements checkbox to populate the monthly settlements information.

Issue: The Send Settlement task was not processing the Selected Entity IDs correctly, which caused inaccurate or partial settlements data to be sent to the market.

Resolution: The issues were caused by errors in the Send Settlement Task Template UI. The flawed logic accidentally ignored some of the selected IDs. Also, there were bugs when creating a new template and editing the list of the IDs before saving it. The Send Settlement Task Template UI logic was corrected to select the proper IDs.

Issue: When modifying theDefaultServiceModeCleanUp task template, upon saving the changes, another task template with the same name is created in the Task Template drop down. This is because when checking if the task template already exists, the Task Template drop down's text is used instead of the Task Template's ID, so a new task template is created.

Resolution: The issue has been corrected. When a task template is modified, the changes are now correctly saved against the existing task template, and new task template is no longer created.

Issue: On the Recurring Schedule screen, the Sunday option is not shown under the Weekly Recurring parameter, so that the user is unable to set up a weekly recurring schedule every Sunday.

Resolution: The Recurring Schedule screen has been corrected. The Sunday option is now visible.

Issue: After upgrading to IEE v10.1, duplicate task templates are observed (Contingency Read, Move-In, Move-Out, and AMI Remote Interrogation task templates). This is because when checking if the task template already exists, the Task Template drop down's text is used instead of the Task Template's ID, so a new task template is created.

Resolution: The issue has been corrected. When a task template is modified, the changes are now correctly saved against the existing task template, and new task template is no longer created.

Issue: When exporting reading xml using the "Reading XML Export" task template via a Cycle Schedule, if the export fails when writing the file to the file system, the export is unable to be rescheduled due to the method of merging the files previously attempted.

Resolution: Changes were made to the process when exporting reading xml using the Cycle Scheduler to only update the cycle channel data end time and export history AFTER successfully writing to merging the export files this resulted in the tasks being able to be re-executed correctly.

Issue: When aggregating Service Points or Settlement Points for that contain legitimate empty contributors. For example, the BestInterval UCE function is likely to encounter missing data from some of the contributors. By design, the Best Interval should traverse the channels from the top to bottom and substitute zeros for empty contributors, instead of stopping the aggregation.

Resolution: The Aggregation task template has been enhanced to include two new settings: "Force Complete" and "Log Empty Contributors". See Parameters and Settings Changes for more details.

Issue: When using the "Validation Detection Process" task template to perform a scheduled validation the template did not contain appropriate time zone conversion settings resulting in validation of data based on UTC values rather than service point time zone.

Resolution: The validation detection process procedures were updated to respect time zone selected in the validation task template.

Issue: When creating a new estimation set with the Two-Week Like Day Historical estimation routine, the radio button selection on the UI shows three options: 2 Weeks, 2 Weeks Australian Rule, and 52 Weeks. However, the settings on the UI always default to 2 Weeks Australian Rule regardless of the radio button selection.

Resolution: The radio button selection on the UI has been corrected.

Issue: On the Validation Queue Assignment user interface, when the "Assign up to a maximum of" radio button is selected, the individual operator's checkbox and the Save button are disabled. This issue prevents assignment of queue items to team members.

Resolution: The Validation Queue Assignment UI has been corrected.

Issue: The Validation Queue is not updating items that recently had a meter swap. After the meter swap, if new readings are imported beyond the new meter's effective end date, the validation queue item is not shown in the queue. Note: this issue is only applicable to SQL Server environments; the Oracle environments are not affected.

Resolution: The SQL Server version of the Validation Queue procedure has been corrected to update queue items that include readings beyond the meter's effective end date.

Issue: When performing Bulk Validation for service points that do not have linked meters, the service throws the same error (Cannot Validate as meter is not linked) repeatedly for each validation and fails as it attempts to append the error repeatedly to the Notes.

Resolution: The logic has been corrected. In this scenario, the error is appended once to the Notes, and the Bulk Validation is now successful.

Issue: Register Gap Check: With SRI-E, register gap check is supposed to fail if an interval set covering the expected register time arrives without that register. In circumstances where readings in the same file and service point arrive with interval data that overlaps midnight or doesn't directly align with the corresponding registers the register Gap Check was triggering usage calculation as if the registers were missing.

Resolution: Logic was implemented to further distinguish between correlated intervals, the corresponding registers and timeframes to pass or fail the register gap check correctly.

Issue: The Register Change request from SAP to reprogram a meter fails, when both existing and new service point programs have TOUREAD channel set with different channel set IDs.

Resolution: The reprogramming logic has been corrected. The reprogramming scenario above is now applied successfully, whether it is performed through a Register Change request from SAP, or from the UI, or through the Program Based Configuration API.

Issue: During processing of bulkreplication ISAIM messages, i.e, those that contain a bulk set of configuration changes for various unrelated service points, if an error occurred with sub components of the bulk transaction, other than a database deadlock or timeout, no error messages were logged with details of the failure and the entire bulk transaction AND each sub transaction would stop with a failed task status. Advanced logging would need to be enabled and the transaction retried to troubleshoot the offending sub transaction.

Resolution: A change was released in the handling of ISAIM bulkreplication processing in which any individual sub transactions that cause an error are captured and the processing mode of the bulkreplication transaction switches to single mode processing, handling each sub task individually. In the event of this automated handling of the errors and exceptions this enhancement results in logging a WARNING in the task monitor about the bulk process status, and the individual sub transactions themselves will log any specific errors at the sub transaction level as an ERROR. The result is the overall bulktransaction can proceed for all unrelated sub transactions and the sub transaction configuration changes will error without stopping processing on unrelated items within the bulk process.

Issue: When Audit Logging Mode in IEE System Settings > General is set to "None" Or "Ignore API Inserts" customers using ISAIM were still seeing audit log entries when master data was updating the "CustomTemporalTable ". The "None" or "Ignore API Inserts" was only working for new data, not updates or deletes.

Resolution: The audit log setting table was updated for the CustomTemporalTable and NodeAttributeValue tables to respect the audit settings.

Issue: During processing of bulkreplication ISAIM messages, i.e, those that contain a bulk set of configuration changes for various unrelated service points, if an error occurred with subcomponents of the bulk transaction, other than a database deadlock or timeout, no error messages were logged with details of the failure and the entire bulk transaction AND each sub transaction would stop with a failed task status. Advanced logging would need to be enabled and the transaction retried to troubleshoot the offending sub transaction.

Resolution: A change was released in the handling of ISAIM bulkreplication processing in which any individual sub transactions that cause an error are captured and the processing mode of the bulkreplication transaction switches to single mode processing, handling each sub task individually. In the event of this automated handling of the errors and exceptions this enhancement results in logging a WARNING in the task monitor about the bulk process status, and the individual sub transactions themselves will log any specific errors at the sub transaction level as an ERROR. The result is the overall bulktransaction can proceed for all unrelated sub transactions and the sub transaction configuration changes will error without stopping processing on unrelated items within the bulk process.