Oracle Utilities Meter Data Management/Smart Grid Gateway

Business User Guide

Release 2.2.0

E80252-01

December 2016

Documentation build: 12.8.2016 13:25:19 [D1_1481221519000]

Copyright © 2010, 2016, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Overview

Next in This Section

- Functional Overview

- Glossary of Terms

- High Level Admin Areas

- Additional Resources

Functional Overview

Oracle Utilities Meter Data Management (MDM) provides functionality for handling large volumes of meter/device data to enable increased accuracy, flexibility, and scalability. Below is a list of the most crucial business processes that are enabled within the system:

- Defining meters, meter configurations, service points, and meter installations

- Loading of meter readings and interval data from a head-end system or other source

- Automatic validation, editing, and estimation of measurement data

- Robust editing capabilities for readings and interval data

- Calculation and publishing of bill determinants and other data from measurement data for use in external down-stream systems such as billing, pricing, etc.

Oracle Utilities Meter Data Management stores a lot of important data that varies from meters to service points to customer contacts and everything in between. The diagrams below provides an overview of the most crucial objects in the Oracle Utilities Meter Data Management data model:

Measurement, VEE, and Usage Calculation for Billing

A Device represents a physical meter, communication module, or some other device out in the field. A Service Point is the point at which service is delivered to a customer and a device can be installed. The Install Event is a record of a specific device installed at a Service Point. A Contact is the customer that should be contacted in association with the Usage Subscription.

In order to properly track the way in which a device is configured, the Device Configuration (add link) keeps a record of which types of data should be measured for the device. A Measuring Component (add link) represents a single channel of data for a device. For example, a device may have multiple measuring components: one that represents kWh interval data and another, another that represents kWh scalar readings, and a third that registers Voltage interval data.

Energy data received from meters is initially stored as Initial Measurement Data (IMD). Once the VEE process is executed, if the data passes then Measurements are created but if the data fails then VEE Exceptions are created.

A Usage Subscription tracks a set of usage calculations that should be performed for a Service Point or multiple Service Points. In order to perform calculation of usage (often referred to as bill determinants), a Usage Transaction is created through a request from the billing system. If any issues are encountered in the usage calculation process or from a usage transaction validation, then Usage Transaction Exceptions are created.

Service Orders and Remote Commands

An Activity in Oracle Utilities Meter Data Management is a very flexible object that is used for various processes. Two of the key processes handled by Activities are:

- Remote Commands involve communicating with a Head End to perform actions or retrieve data from a meter. Examples include remote connects, remote disconnects, on-demand reading, etc.

- Service Orders are methods through which work can be performed at a Service Point. Examples include enabling service, disabling service, meter exchanges, etc.

Oracle Utilities Meter Data Management includes the following functional areas:

- Device Management is used by analysts and administrators in managing and defining the devices used to record and capture meter data.

- Device Installation is used by analysts and administrators in managing the installation of devices, including defining markets and service providers, Service Points and contacts, and installation events.

- Measurement data is a normalized way of storing data from a meter that involves some form of measurement (i.e. kWh, CCF, etc.). Both interval data and scalar readings are held in this common storage location.

- Validation, Editing, and Estimation (VEE) is used by administrators to define validation, editing, and estimation (VEE) rules to be applied to measurement data. VEE Exceptions may result from validation or estimation failures and should be worked by analysts through the To Do process.

- 360 Degree Search and View is used by analysts and administrators to search and view data for devices, measuring components, Service Points, Usage Subscriptions, and contacts.

- Consumption Sync provides an automatic method to keep interval data and scalar readings in sync with one another.

- Usage Calculation is used by administrators to manage the calculation of usage data and to provide the results of those calculations (commonly referred to as bill determinants) to external systems and parties. Usage Groups and Rules define calculation rules to be applied to measurement data. Usage Transaction Exceptions may result from usage calculation and should be worked by analysts through the To Do process.

- Device Events provides a view of specific events that have occurred on a meter. These are often unexpected and can indicate an issue with the meter.

- Communication helps track the instances when communication occurs with external systems. This is heavily used for tracking remote commands against Head End systems.

- Aggregations are used by analysts and administrators to search, view and maintain aggregated measurements that represent a summarization of other measurements from a set of devices and/or measuring components.

- Master Data Sync defines the methods through which data is automatically synchronized to Oracle Utilities Meter Data Management from external sources (such as a CIS and/or Asset Management system).

- Outage Storm Mode is a way for Oracle Utilities Meter Data Management to detect widespread outages and suppress estimation for those meters until normal communication of data resumes.

- Dashboards provide high level metrics for Oracle Utilities Meter Data Management operators to monitor operational trends as well as overall system health.

- Service Issue Monitor can be setup by administrators to monitor various conditions within Oracle Utilities Meter Data Management and automatically create a Service Investigative Order if those conditions are met.

- Service Order Management provides a centralized program for managing the complex interactions required for Service Order processing. This area is especially valuable for managing service order processing that involves remote communication with a Head End for connects, disconnects, and on-demand readings.

- Information Lifecycle Management is an automated method that administrators can configure to prepare data for archiving or purging after a defined period of time for the record type.

Glossary of Terms

Below is a list of terms along with their definition to assist with understanding Oracle Utilities Meter Data Management:

Term

Definition

Base Time Zone

This is the time zone defined on the Installation Options - Framework. All date/times stored in the system are governed by this time zone. See also: Standard Time and Legal Time

Bill Determinants

Measurement data summarized for use by a billing application. Bill determinants can take the form of TOU-mapped interval consumption, scalar consumption, scalar readings, and/or interval consumption obtained via measurements. One good example of bill determinant is TOU-mapped interval consumption, which reduces a full month's worth of interval data into several buckets of consumption based on time of use.

CIS (Customer Information System)

A generic term for the system used to store customer and billing information at a utility.

Consumption

A measurement by a given device of the amount of energy, water, gas, etc. consumed over a given time period. Synonymous with the term "measurement".

Contact

A customer that should be contacted in association with a Service Point or Usage Subscription.

Customer Modification (CM)

This refers to code or configuration that's been added by your organization.

Device

A physical meter, communication module, or some other device out in the field.

Device Configuration

This keeps a record of which types of data should be measured for the device.

Device Event

An alarm or warning sent from a device that may indicate an issue with normal operations (examples: theft, memory failures, etc.).

Dynamic Option

Used to specify terms that override how usage is normally calculated - such as a critical peak period that affects the TOU mapping of interval consumption.

Factor

A centrally stored set of values for use in validation rules, bill determinants calculations, and other processes. A factor can have different values depending upon some definable attribute of a system object, such as customer size associated with a Service Point. The values are effective-dated so that changes over time are retained. Examples of factors can include minimum/maximum thresholds, loss factors, etc. Classes of factors are defined that can have numeric values (as in the above examples), or values pointing to profile measuring components or VEE groups.

Function - Measurement

An online-initiated action applied to measurement data, comprising one or more measurement services.

Initial Measurement Data (IMD)

The data measured on a device that is sent to Oracle Utilities Meter Data Management is stored in this initial record while it's being processed.

Install Event

An instance of a specific device installed at a Service Point. This also includes a record of any time the service was turned on or off.

Legal Time

This refers to a method of storing date/time information where there is an adjustment made to the date/time during periods where Daylight Savings Time (DST) is in effect. There are two offsets against Universal Coordinated Time (UTC): (1) when DST is in effect, (2) when DST is not in effect.

On the day that day that DST begins the clock moves forward by a period of time equal to the DST offset. For example, if DST takes effect at 2:00AM and the offset is one hour then the clock moves from 1:59:59AM to 3:00:00AM skipping 2:00:00AM - 2:59:59AM.

On the day that DST ends the clock is moved backwards thus recording a period of time equal to the DST offset twice, the first recording of that period is with the UTC offset for DST being in effect, the second recording of that period is with the UTC offset for DST not being in effect. For example, if DST ends at 2:00AM and the offset is one hour then the clock would repeat the hour from 1:00:00 to 1:59:59.

Manufacturer

The company that manufactured a device.

Measurement

This is the final, validated measurement information from a device. Measurement data is used in calculation of usage as part of the Usage Transaction process.

Measuring Component

A logical container for measurement data. These are often channels for physical devices but can also be aggregators, weather data, or any other form of measurements.

Out-of-the-box (OOTB)

This refers to code or configuration that's provided as part of the product delivered by Oracle (as opposed to a Customer Modification).

Profiling of Scalar Data

The process of applying an interval consumption "shape" to a scalar measurement, using an existing interval measuring component. The individual interval values are adjusted such that when totaled, they equal the value of the scalar measurement.

Service Point

A location at which a company supplies service. Used to store information describing the type of service and how it is measured.

Service Quantity Identifier (SQI)

Used to further distinguish between measured quantities that have identical UOM/TOU combinations (i.e. Generated, Consumed, etc.)

Service Type

The type of service being delivered at a Service Point (i.e. electric, gas, water).

Standard Time

This refers to a method of storing date/time information where there is no adjustment made for daylight savings time. A constant offset with Universal Coordinated Time (UTC) is maintained throughout the year.

Sub Usage Subscription

A "child" Usage Subscription that is subordinate to another Usage Subscription (such as when a utility is issuing a bill for a third party service).

Time Of Use (TOU)

A bucket of time throughout a day that's used for summarizing measurement data. These are often given a descriptive name as well (i.e. On Peak, Off Peak, etc.)

To Do

A work item that should be reviewed by a user. A To Do is related to data issues, incorrect processing, or other problems that occur within the system.

Unit Of Measure (UOM)

A metric of how measurement data is measured (i.e. kWh, kVARh, CCF, etc.)

Usage Group

A set of sequenced Usage Rules used to calculate usage for a Usage Subscription.

Usage Rule

Business rules / logic used to calculate usage (bill determinants), such as a TOU-mapped consumption calculation. Each rule is a modular unit that can be grouped together and sequenced within a calculation group.

Usage Rule Eligibility Criteria

User-definable conditions that could cause a given Usage Rule to be applied or skipped. This could involve the evaluation of some attribute of the device or measuring component, or some other important attribute.

Usage Subscription

A record of an ongoing request to send one or more Service Points' usage to one or more external systems (such as a billing application).

Usage Transaction

A record of bill determinant calculations for a Usage Subscription.

Usage Transaction Exception

An exception generated during the usage transaction process. Exceptions are assigned a severity that is used in determining whether or not the usage transaction should be transitioned into a requiring approval or resolution.

Validation, Estimation, and Editing (VEE)

The process by which initial measurement data is validated, estimated (if necessary) and edited (if necessary) based on a set of user-defined rules.

VEE Exception

An exception generated during Validation, Estimation and Editing (VEE) processing of initial measurement data. Exceptions are assigned a severity that is used in determining whether or not the initial measurement data should be transitioned into an exception state.

VEE Group

A collection of VEE Rules.

VEE Group Matrix (Factor)

A VEE Rule within a VEE group can be configured to pick from a list of VEE groups (referred to as a matrix) whose rules to execute next. This list of VEE groups is configured as the values of a factor. One example of its use could be to call geographically-specific VEE groups from within a larger-purpose group. A residential VEE group might contain

a rule that will pick the VEE group to execute based on Service Point location, where the VEE Group Matrix specifies:

Service Point in the North - VEE Group N

Service Point in the East - VEE Group E

Service Point in the South - VEE Group S

VEE Rule

Standard and custom Validation, Estimation and Editing (VEE) Rules that perform checking and/or manipulation of initial measurement data.

VEE Rule Eligibility Criteria

User-definable conditions that could cause a given VEE Rule to be applied or skipped. This could involve the evaluation of some attribute of the device or measuring component, or some other important attribute.

High Level Admin Areas

A high level overview of the administrative data used by Oracle Utilities Meter Data Management has been defined in the Overview section of the Oracle Utilities Meter Data Management / Smart Grid Gateway Administrative User Guide . The methods behind how Oracle Utilities Meter Data Management is configured may be worth reviewing at some point to provide more context to the Business User Guide.

Additional Resources

There are numerous ways to obtain additional information and resources to assist you when working with Oracle Utilities Meter Data Management. The list of these options are maintained in the Additional Resources section of the Oracle Utilities Meter Data Management / Smart Grid Gateway Administrative User Guide.

User Interface Standard Features

This section describes basic system concepts, features, and standards of the user interface.

Next in This Section

- System-Wide Standards

- Portal and Zone Features

System-Wide Standards

This document is the central reference to basic system concepts, features, and standards.

Next in This Section

- Page Components

- Maintenance Pages

- Query Pages

- Portals

- User Preferences

- Initiating Scripts

- Shortcut Key Summary

Page Components

Oracle Utilities Application Framework screens are comprised of the following main areas:

1. The Application Toolbar

2. The Page Title Area

3. The Object Display Area

4. The Dashboard Area

Note: The look and feel of the application may be modified after the product is installed. See Custom Look and Feel Options for customization information, including how to change colors, fonts, and other system features. The information provided in this document represents features and functionality available only in the delivered product.

Next in This Section

- The Application Toolbar

- Page Title Area

- Object Display Area

- Dashboard Area

- Script Area

The Application Toolbar

This section describes the features available on the application toolbar.

Next in This Section

- Home Button

- Menu

- Admin Menu

- Back Button

- History Button

- Forward Button

- About Button

- User Menu

- Menu Item Search

- Help Button

Home Button

Click the Home button, , on the Application Toolbar to open your home page. Your home page is defined in User Preferences.

Keyboard Shortcut

Alternate Shortcut

Alt+O

Alt+Shift+O

Note: Refer to Shortcut Key Summary for information about the alternate shortcut.

Menu

Menu is available in the application toolbar to help you navigate to the different pages of the system

Keyboard Shortcut

Ctrl+Alt+M

The menu list is organized by functional area. Clicking the Menu button displays each functional area. Clicking a functional area, in turn, displays a submenu that contains pages within that area.

The pages within each functional area typically have two options: Search and Add. If the menu item does not have an Add or Search option, select the menu item itself.

How the Search and Add option behaves depends upon whether the maintenance page is fixed or portal-based.

Fixed:

- Search: Displays a pop-up search window for the user to enter the search criteria and select the entity to display. Once the entity is selected, the user is taken to the maintenance map with the data populated in the fields.

- Add: Displays the maintenance page with empty fields so that the user can complete the information and save the entity.

Portal-Based:

- Search: Displays a search portal where the user can enter the search criteria and select the desired entity. Once the entity is selected, the user is typically taken to a maintenance portal or the information is broadcast to other zones within the same portal.

- Add: Either navigates to a page where the user can select the entity type or business object, or directly to the input map where the user can enter and save the entity.

Users may also opt to use the Menu Item Search input field.

Admin Menu

The Admin dropdown is available in the application toolbar to help you navigate to the different pages of the system.

Keyboard Shortcut

Ctrl+Alt+A

Depending on how your implementation has configured the Admin menu list, it may be organized either by functional area or alphabetically.

Clicking the Admin button displays each functional area or alphabetical list. Clicking one of the options, in turn, displays a submenu that contains pages within that area. The following is an example of the Admin menu organized functionally.

Note: Menu navigation paths referenced in the administrative user guide provide the functional grouping. If your implementation uses the alphabetic grouping, the page can be find in the alphabetic letter that is the first letter of the page name.

Note: Refer to Installation Options for information about the admin menu configuration options.

The menu lines displayed for each menu entry typically have two options: Search and Add. If the menu item does not have an Add or Search option, select the menu item itself. See Menu for more information about these options.

Users may also opt to use the Menu Item Search input field.

Back Button

Click the Back button on the application toolbar to open the previously visited page.

Keyboard Shortcut

Alt+B

The back and forward navigation buttons, as well as the History list, appear in the application toolbar only when page use warrants their appearance.

Note: Under certain circumstances, such as revisiting a page that was left unsaved after being loaded with default data, a page may not appear as it did when you left it.

History Button

Click the History button to display a list of previously visited pages. When you click on an entry in the list to return to an earlier page, all items above the selected page are removed from the list.

The back and forward navigation buttons, as well as the History list, appear in the application toolbar only when page use warrants their appearance.

Note that if the page has been configured to display an information string in the page title area, that information will also be visible in the History dropdown.

Keyboard Shortcut

Ctrl+Alt+H

Forward Button

Click the Forward button to return to the page that was most recently dismissed.

Keyboard Shortcut

Alt+G

The back and forward navigation buttons, as well as the History list, appear in the application toolbar only when page use warrants their appearance.

Note: Under certain circumstances, such as revisiting a page that was left unsaved after being loaded with default data, a page may not appear as it did when you left it.

About Button

Click the about button to display a window that describes the current and release information for your version of your product.

The about window shows a variety of information including:

- The logged in user ID

- The release ID of the product

- The release ID of the framework used to construct the product

- The release ID of any customer specific modifications (this comes from the installation record)

User Menu

The User menu is available in the application toolbar to provide access to user-specific options.

Through this dropdown, the user can access their User Preferences or Logout of their current session.

Note: Configurable Menu. Additional menu entries may be visible in your implementation as this menu configuration allows for additional options to be defined.

Next in This Section

- Preferences

- Logout

Preferences

Click the Preferences menu item in the User Menu to view or modify your settings in a form that appears in the Main tab in the object display area.

Keyboard Shortcut

Ctrl+Alt+P

Logout

Click the Logout menu item in the User Menu to complete your current session of the application. Clicking this item logs the current user out and displays the Welcome page so that another user can login.

Keyboard Shortcut

Ctrl+Alt+L

Menu Item Search

The Search Menu input field and search icon are used to allow a user to enter the description of a menu item entry to navigate directly to the corresponding page or BPA script rather than using the menus to navigate to the desired page / script.

Keyboard Shortcut

Ctrl+Alt+F

Typing text in the field shows menu items whose descriptions include the typed text.

Note that only menu items within the Menu and Admin Menu that the user has security access for are included in the results. The text included in the search is taken from the menu item description. As described in Menu, menu lines often have two sub item: Search and Add. In most instances, the description of the "Search" menu item is simply the menu entry text, for example To Do Entry. The description of the "Add" menu entry includes the word Add in front of the menu entry text, for example Add To Do Entry.

Help Button

Click the Help button in the Application Toolbar to open context-sensitive Help in a new browser window.

Keyboard shortcut:

Keyboard Shortcut

Alt+F1

Page Title Area

The Page Title Area displays the page title and the page actions toolbar.

For certain pages in the system, the page title may be followed by an information string. It is only applicable to portal-based pages that display a single record. This information is only visible if the portal has been configured to display the primary key’s information string. Typically only “stand alone” maintenance portals are configured to show the information string, whereas “all-in-one” portals are not configured this way.

Fastpath: Refer to Common Base Portals and Zones for more information about standard base product portals.

Note: If an information string is long and would interfere with a page actions button, the information string will automatically be truncated and suffixed by an ellipsis, “…”, indicating that more information is available. In this situation, the missing text can be viewed if the user hovers their mouse over the string.

The Page Actions Toolbar displays standard control options, such as Save and Duplicate. More detail about the actions that may appear are described in the following section.

Next in This Section

- Page Actions Toolbar

Page Actions Toolbar

In the Page Title Area, control functions appear in the Page Actions Toolbar; such as, Clear, Save, Duplicate, Delete and Refresh buttons.

Note:
Buttons in the Page Title Area appear as the function is available to the user; for example, the Delete button will not appear if the user has made any changes to the page’s content, or does not have the necessary security rights for this action.

In addition, other functions that are specific to a portal-based page may appear in the toolbar, if configured. For example, the ability to navigate to the Search zone for a specific maintenance object may be visible on the maintenance portal.

This section describes the standard features that are available in the Page Actions Toolbar.

Next in This Section

- Bookmark Button

- Next/Previous Item Buttons

- Duplicate Button

- Delete Button

- Clear Button

- Save Button

- Refresh Button

Bookmark Button

Click the Bookmark button on the Page Actions Toolbar to save the current page and context to the bookmarks list.

Keyboard Shortcut

Ctrl+Alt+B

Note: Secured. This button is secured using the application service F1–BOOKMARKS.Users that do not have security for the application service will not see the Bookmark button (or the corresponding dashboard zone).

After clicking the Bookmark button, you are prompted to provide a name for the bookmark. After saving, it is visible in the Bookmarks Zone, allowing you to return to this page with this context loaded with one click.

Note: Unsaved data will not be included in the bookmark. If you view a record and make changes to data without saving the changes and then bookmark the page, the unsaved changes are not included in the bookmark information.

You may change the name of the bookmark or change the sequence of the bookmarks by navigating to the User — Bookmarks in the user preferences.

Next/Previous Item Buttons

The (Previous Item and Next Item buttons appear in the Page Actions Toolbar under these conditions:

- You access a fixed page, meaning that it is not portal-based.

- You use a search page to display an item.

- There are multiple items in the search results list below or above the selected item.

If, for example, you enter search criteria of "Smith" on the User Search page, you might see the following results:

- Smith, Albert

- Smith, Peter

- Smith, Zane

If you select Smith, Peter, Peter's user information is displayed on the User page. If you then click the Next Item button, Smith, Zane will be displayed. In addition, because Smith, Zane is the last entry in the search results, the Next Item button is no longer needed and will not appear in the Page Actions Toolbar.

If you then click the Previous Item button, Smith, Peter will be displayed; click again and the Smith, Albert record will appear, and, because Smith, Albert is the first entry in the search results, the Next Item button is no longer needed and will not appear in the Page Actions Toolbar.

Keyboard Shortcut

Alternate Shortcut

Alt+P

Alt+N

Alt+Shift+N

Note: Refer to Shortcut Key Summary for information about the alternate shortcut.

Duplicate Button

Click the Duplicate button in the Page Actions Toolbar to create a duplicate of the currently selected object.

Before the new object is added to the database, a dialog appears in which you must enter the unique identifier for the duplicate object. When you click OK, the system creates the record by copying the original record. It may be helpful to think of the duplication function as the equivalent of a "save as" action.

Keyboard Shortcut

Ctrl+Alt+D

Note: Copying ancillary information for a record sometimes requires confirmation during a duplication request. If so, you may also be asked if you also want to duplicate ancillary information. If, for example, you duplicate a user group, besides supplying the ID of the new user group, you are asked if all users in the original user group should be linked to the new user group.

This button does not appear in the Page Actions Toolbar when:

- Duplication is not supported for the current object.

- You are on a portal based page. (For these types of pages, if duplication is supported, the actions are defined in a zone on the portal.)

- You have made changes to the object without committing the changes to the database by clicking Save. (After making changes, you must either discard them using the Refresh button, or save them.)

Delete Button

Not all transactions have the capability to be deleted. Deletion is related to the business impact of the action. In some transactions, Delete is present for some scenarios and unavailable for others; for example, you may not be able to delete a record at a certain status level.

Note:
If you make a change to an object and do not save the changes to the database, you cannot delete the object until you either save the changes or refresh the object with the contents on the database.

Before you delete an object, the system verifies that the object is not referenced anywhere in the system. If it is, you cannot delete it. If, for example, you attempt to delete a user, the system ensures this user has not been referenced in a user group or on a To Do.

Depending on the type of page that you are using, the option to delete may vary.

- Fixed pages display a Delete button in the page actions toolbar when the option is available.

- Portal-based pages display the Delete button in the object-related map.

- List zones on All in One portals commonly display the Delete button (garbage can icon) next to the entity in the search results.

In all cases, before the object is deleted, a confirmation dialog is displayed.

CAUTION:

A timeout situation could occur as the system attempts to verify the use of the deleted object if the object is referenced in many places and involves large volumes of production data. If this timeout situation occurs, you must with your database administration group to delete the offending object.

Clear Button

Click the Clear button to remove the values from the currently displayed object’s fields. This action is typically used to clear input fields when adding a new object.

Keyboard Shortcut

Ctrl+Alt+C

Save Button

Clicking the Save button saves any changes you have made in the data on the current object.

Keyboard Shortcut

Alternate Shortcut

Alt+S

Alt+Shift+S

Note: Refer to Shortcut Key Summary for information about the alternate shortcut.

The button does not appear unless:

- You enter a page in add mode and default values are loaded.

- You make changes to an object after it is displayed (note that you must tab or click out of the field before the Save button appears).

Refresh Button

Click the Refresh button to reload the values on the page with those from the database.

CAUTION:

All unsaved changes are discarded.

Keyboard Shortcut

Alt+R

Object Display Area

The Object Display Area contains the details of the object(s) currently being viewed or maintained. For example, if you display a portal, its zones are displayed in this area.

Because many of the page components follow Internet standards of operation, the behavior of these types of components are not explicitly described. This section focuses on special features that are unique to the application framework.

Next in This Section

- Multiple Tabs

- Text Box

- Date Only Field

- Date and Time Field

- Search Button

- Context Menu Button

- Go To Button

- Broadcast Button

- Embedded Help Icon

- Work Lists

- Scroll Bars with Dynamic Height

- Sorting Functionality

- Get More Functionality

- Adding and Removing Rows Using Arrows

- Reorganizing Items Using the Up and Down Arrows

- Trees

- Required Field Indicator

- Accordion Windows

Multiple Tabs

When a page in the application includes a lot of information, the page may be implemented with vertical scrolling to allow the user to view all the information. Or alternatively, the page may be implemented with several tabs, allowing the user to navigate between tabs to view or update information. The following image is a section of the User page showing the multiple tabs.

Figure 1. Multiple Tabs Example

The names of the tabs describe the type of information that will be displayed in the page when the tab is clicked. For example, if you click on the Favorite Links tab, the contents of the page show the favorite links configured for the user.

Figure 2. Multiple Tabs Example (After Favorite Links Tab Is Clicked)

Note: Hot key options. Rather than clicking on a tab, you can click F2 or Shift+F2 to scroll through the tabs. F2 moves you through the tabs from left to right. Shift+F2 moves you through the tabs from right to left.

Note: Hot key options. Use Alt+ a number to navigate to the tab page whose relative position corresponds with the number. For example, if you press Alt+6 on the above page, the Favorite Links tab will be displayed. If there are more than 9 tabs on a page, you must use the mouse or F2 / Shift+F2 to display a tab. Note that the numeric keypad on your keyboard cannot be used to implement this function.

Note: Returning to a page that contains multiple tabs. If you return to a page (by clicking the Back button or the History button), the page will be positioned on the last tab that was opened.

Note: Page versus Tab nomenclature. The documentation frequently refers to the contents of a given tab as a page. However, the page actually comprises the entire collection of tabs.

Text Box

The following is an example of a basic text box:

If the text box is a large field, the text box may be configured to enable scrolling. In this situation, an expanded edit icon, (a pencil), will appear adjacent to it.

Additional capabilities are provided to display and edit data in these text boxes:

- If the field contains more text than is visible, a pop-up that displays the full text appears when you hover your mouse over the text box. The text in the pop-up can be selected and copied.

- If you click the expanded edit icon, an editable pop-up window appears. If the field is not protected as a result of business rules for the page, you may modify the text in this window.

Note: The following table highlights special characters that are converted to equivalent standard characters when entered in a text box.

Entered Character Description

Unicode

Converted Character Description

Curly left double quote.

U+201D

Straight double quote.

Curly right double quote.

U+201C

Straight double quote.

Curly left single quote.

U+2019

Straight single quote.

Curly right single quote.

U+2018

Straight single quote.

En dash.

U+2013

Simple hyphen.

Em dash.

U+2014

Simple hyphen.

Ellipse

U+2026

Three dots.

Middle dot (bullet / centered dot)

U+00B7

Asterisk.

Fraction 1/4 (using 1 character).

U+00BC

1/4 (using three separate characters).

Fraction 1/2 (using 1 character).

U+00BD

1/2 (using three separate characters).

Fraction 3/4 (using 1 character).

U+00BE

3/4 (using three separate characters).

Date Only Field

When only the date is required, the Date field looks as follows:

If you click the calendar icon next to the date field, or you double-click inside the date field, the following window appears:

If the date field was blank, the current date is highlighted when the window first appears. If the date field contained a date, it is displayed.

You can double-click the desired date, or you can select a date and click Accept to close the date window and populate the date field.

Date and Time Field

When both the date and time are required, the Date and Time fields typically look as follows:

If you double-click or press the Enter key while the cursor is in a Date and Time field, the following window appears:

Select the date and use the toggle buttons (or enter) the time and then click Accept to populate the original fields.

Note: The user cannot select and move the hands on the clock to set the time.

Search Button

The search button appears primarily as a magnifying glass.

When using a pop-up search window, the search button can appear as a button with its function labeled.

You can have the system search for an item that matches the data you entered using any of the following methods:

- Enter a value in the search field and press Enter while the cursor is in the search field. The system assumes you want to search for the value entered and pre-populates it in the search window's search criteria. If a unique match can be found, the system automatically populates the field with details corresponding to the record found. If a unique match cannot be found (either no matches or multiple matches), a search page opens containing selectable items.

- Click the Search button without entering a criteria. This will typically cause a pop-up search window to appear so that you can further refine your search.

- Enter a value and tab out of the search field. The system looks for a value that exactly matches what you entered. If it cannot find such a value, the search dialog will not be presented.

When an item is selected in the search page, the search page closes and the input field is populated with the value selected.

Note: Sorting columns within the search grid. You may click on the column heading of columns in a search grid to cause the contents of the grid to be sorted. Refer to Sorting Functionality for more information.

Context Menu Button

The Context Menu button is a small version of the Menu button from the Application Toolbar. An example is shown below:

Context menus exist to help you navigate to other pages and populating the page with the current context (by passing the ID of the related object). In addition, the menu items offered in a Context Menu differ depending on the entity that the menu is related to; for example, when you click the Algorithm Type context menu, a pop-up menu similar to this appears:

Different context menus exist for each of the major objects in the system; for example, in Customer Care and Billing, the context menu for Premise contains premise-oriented menu items, whereas the context menu for Account contains account-oriented menu items.

Go To Button

Clicking a Go To button, , opens the page for the related object - it functions like a hyperlink.

Broadcast Button

Some zones have been configured to "broadcast" unique identifiers to other zones within the portal; if so, you'll see a broadcast tower icon, , in the first column. Clicking the icon causes specific zones to reload — these zones that have been configured to rebuild when the unique identifier is received. For example, you might have configured a zone to display the image of a bill when a bill ID is broadcast from an info zone.

Embedded Help Icon

The icon containing a small 'i' is an Embedded Help icon.

When an embedded help icon is clicked, a tool tip appears containing additional information.

Work Lists

The work list buttons can appear in a zone’s column heading, .

Clicking the icon results in populating the dashboard Work List Zone with the entire column. The user may use the Work List zone to easily process entries one at a time without returning back to the source query zone. The work list stays populated until the user overlays the work list by clicking a different column's icon.

When a user clicks on a work list entry in the dashboard, the system behaves as if the user clicked on the hyperlink in the zone. In addition, the system adds a check mark next to the item showing that the user has “worked on” or visited the entry.

Note: The Work List zone is populated only upon user request.

Scroll Bars with Dynamic Height

Sometimes the height of a grid isn't sufficient to display a grid's rows. When this occurs, a vertical scroll bar appears and an "expand button" appears above this bar, . For example, the following grid is not high enough to show all of a the available dashboard zones:

If you want to view all of the person's phone numbers without using the vertical scroll bar, you can you click the expand button. When clicked, the height of the grid expands to show all rows in the grid:

Notice, after the grid is expanded, the grid's vertical scroll bar disappears and the button in the upper corner becomes a Collapse Button, . If you click the collapse button, the grid will return to its original height.

Note: Search grids. Expand all functionality is not available in search grids.

Sorting Functionality

Grids have a heading row that contains labels for the columns. By clicking a column heading, you cause the rows to be sorted in the order of the selected column. By clicking on a column more than once, you cause the rows to be sorted in reverse order. Clicking the heading a third time removes the sorting function and returns the grid to its default display organization.

The following shows how information look after organizing the grid, clicking the column heading, by algorithm type (notice the icon in the column name).

Note: Sorting on dropdown values. If you attempt to sort a column that contains a dropdown value, the information is sorted in the order of the unique identifier associated with the dropdown value, not the description you see on the screen; for example, if you sort on a column containing unit of measure, the information will be sorted in the order of the unit of measure code, not the description that appears in the drop down. This means that the resultant sort will appear incorrect and therefore we discourage you from doing this.

Get More Functionality

Grids that can potentially contain a large number of rows have special processing that we refer to as Get More functionality. We'll use an example from Oracle Utilities Customer Care and Billing to explain - consider the grid that contains all payments that have been added to a cash drawer. By the end of the day, this grid could contain hundreds of rows (one for each payment remitted during the day). Rather than show every payment in the grid, the system retrieves the first X payments (where X varies from grid to grid, and from release to release) and appends a Get More button to the bottom of the grid as illustrated below:

When you click the Get More button, the system appends the next X rows to the bottom of the grid.

Note: The absence of a "get more" button. If no button appears at the bottom of the grid, this means you are seeing all of the rows.

Note: Search grids. The Get More function is not available in search grids.

Adding and Removing Rows Using Arrows

In some editable grids, a new row can be added to another editable grid (the grid on the left) by clicking the Add item button, , of the desired row in the grid on the right:

When the Remove item button is clicked, , the row is transferred from the grid on the right to the grid on the left. This change will not be committed to the database until you save the object being maintained

Reorganizing Items Using the Up and Down Arrows

Occasionally, rows can be repositioned in an editable grid by clicking up and down arrows. The following is an example of such a grid:

Notice the following about such a grid:

- The up arrow is dim in the first row. This is because it can't be moved further to the top.

- The down arrow is dim in the last row. This is because it can't be moved further down.

- The up and down arrows are usable in all other rows. Each time you click one of these arrows, the respective row is moved up or down one row.

Note: Reminder. When you move rows into a grid, the system does not apply the change to the database until you click the Save button (which commits the entire object to the database).

Trees

Trees are used to illustrate complex relationships between objects. The following is an example from Oracle Utilities Customer Care and Billing of a page with a tree that is expanded:

The following points describe how to use trees:

You can expand and contract the nodes in a tree by clicking on the icon that prefixes the node (you can also click the + and - button to expand and contract a node).

Note: Expand all. If you press Ctrl while clicking on an icon that prefixes a node, all child nodes (and their children) expand.

You can click the context menu button to cause a context menu to appear. You can navigate to any of the pages that are presented on this menu. Refer to Context Menu Button for more information.

You can click on the information that appears in an underlined node to drill into the page in which the object is maintained. For example, if you click on the account information, you will be transferred to the Account - Main page.

Note: Important! If you make changes after expanding a tree's nodes (e.g., by drilling down on a Premise and changing the premise's address), the tree will contract to the first node if you return to the page.

Nodes in trees fit into two broad categories:

- Information nodes. Information nodes highlight the existence of other data. For example, on the Control Central - Bill Payment Tree, a node exists to highlight the existence of new financial transactions that were created since the last bill was completed.

- Data nodes. Data nodes show information about objects in the system. For example, data nodes exist on the Control Central - Bill Payment Tree that show bills and payments.

Required Field Indicator

An asterisk (*) is used to indicate that a field is required. The system determines this based on the field’s configuration. When a field becomes required because of an algorithm and not the field’s configuration, however, the system will not add an asterisk.

Note: The field indicator only appears on portal-based pages. Older, fixed pages will not include this designation.

Note:
If a page includes a grid, fields within a row may be marked as required.

In this situation, the field(s) within the grid are only required if the row is being populated.

Accordion Windows

Accordion windows are used when the data held in an object's rows does not comfortably fit into a grid.

Each row in an accordion has a header that summarizes a row's details. When you click a header, the row expands to show the details. The following is an example of an accordion where all headers are collapsed (meaning that only summaries of the rows' details are shown):

When you expand a header, its details are exposed. For example, the following shows the same accordion after the third row is expanded:

Note: You must expand to update. In order to update a row in an accordion, you must expand it.

Next in This Section

- Row Summary and Chunk Management

Row Summary and Chunk Management

At the top of an accordion you'll find a summary of its rows. The format of this information differs depending on the number of rows and the size of the accordion:

- If the accordion contains every row, a summary of the total number of rows is displayed.

- If the accordion contains a subset of rows, you are presented with a summary of the rows AND you are provided with options to display different "chunks" of rows.

- Click First to display the first "chunk" of rows (the size of a chunk differs depending on the accordion). This option is dimmed if the first chunk is in the accordion.

- Click Previous to display the previous chunk of rows. This option is dimmed if the first chunk is in the accordion.

- Click Next to display the next chunk of rows. This option is dimmed if the last chunk is in the accordion.

- Click Last to display the last chunk of rows. This option is dimmed if the last chunk is in the accordion.

Dashboard Area

The dashboard is a portal that contains zones. These zones appear regardless of the object being displayed in the Object Display Area. Refer to Dashboard Portal for a description of these zones.

Note: User configurable. Every user has control over the zones that appear in their dashboard. Refer to Portal Preferences for more information about how a user can customize the contents of the dashboard.

Script Area

When a script is initiated, the object display area shifts down to make room for the script area.

The information in the script area takes you through the steps in the selected business process (provided by your implementation team).

Maintenance Pages

Maintenance pages are used to maintain (add, change, etc.) the information in the system using a fixed page metaphor. All user interfaces implemented in this way function in a similar manner. This section focuses on functionality common to all maintenance pages using this metaphor.

Note: Not all maintenance pages in the application use this style of maintenance page. The preferred metaphor for maintenance pages, however, is to use portal-based pages. For more information see Common Base Portals and Zones.

Next in This Section

- The Unique Identifier Area

- Confirmation & Error Messages

- Warning If Unsaved Changes Exist

The Unique Identifier Area

Every object in the system must have a unique identifier. For some objects, typically administrative or control table data, the unique identifier is defined by the user creating the record. Other objects, typically master or transaction entities, the unique identifier is assigned by the system after the record is saved.

Where the identifier is displayed depends upon whether the ID is user-defined or system generated.

Pages displaying objects with a user defined identifier (such as To Do Type) typically display the identifier on the left along with a search button. For master and transaction tables, (such as To Do Entry) the unique identifier is typically found in the upper right corner of the screen along with a search button and is labeled as the entity’s ID. In this case, if there is an information string associated with the object, it is displayed on the left.

If the object being maintained has an associated context menu, a Context Menu Button is displayed appear.

Confirmation & Error Messages

Whenever a database modification action is requested, the system first validates the data to be put on the database.

First, the system validates the information. If there are errors, the first error encountered is displayed in a window. In addition to the error message, the error window also contains the error number and the identities of the programs that detected the error. If you don't understand an error and you have to call product support, please supply them with this information.

If there are no errors, the system is modified.

Warning If Unsaved Changes Exist

If you make any changes to an object and you don't commit these changes to the database, the following warning appears: "You have unsaved changes that will be lost if you continue. Press OK to continue anyway."

If you want to commit the changes, click Cancel. You will then return to the page and can make further changes or press Save. If you want to discard your changes and transfer to the new page, click OK.

CAUTION:

This warning is not displayed if you are working on a new object on a fixed page and you navigate to a different page. Information about new objects is preserved in memory in anticipation of your return to the page. For example, if you are in the middle of adding a new user and you want to quickly reference information on a different page, you will not receive the above warning because your information will be saved. If you use the back button to return to the user page, all of the information you were adding will be present and you can enter the rest of the new user's data.

Query Pages

Query pages are used to display record sets in the system. Most query pages function in a similar manner. This section focuses on functionality common to all of the system's query pages.

Next in This Section

- The Search Area

The Search Area

The upper right corner of the screen is almost always the identifier of the object associated with the search. In Oracle Utilities Customer Care and Billing for example, the unique identifier on the Account Financial History page is the Account ID.

To the right of the unique identifier is a Search button. This button is used to search for a different object than the one whose data is being displayed in the page.

If the object being displayed has an associated context menu, a Context Menu Button is displayed.

Portals

This section describes certain types of portals provided in the system where a user may control the content, for example the dashboard.

Portals used for base product query and maintenance pages are typically configured to not allow user customization. Refer to Common Base Portals and Zones.

In most base products, there are several pages whose content can be customized by individual users. These portals exist because different users have different data requirements. For example, in Oracle Utilities Customer Care and Billing a billing clerk might prefer the customer information portal to show a customer's bills and payments. However, a credit and collection supervisor might prefer the same page to show an account's collection activity. Portals allow each user to define what they want to see.

The contents of this section provide background information about portals.

Next in This Section

- Portals Are Made Up Of Zones

- Each User Can Customize Which Zones Appear

- Users Must Be Granted Security Access To Each Zone

- Zones May Appear Collapsed When A Page Opens

- Dashboard Portal

Portals Are Made Up Of Zones

The term "zone" is used to describe a section on a portal. For example, the following is a portal with seven zones:

- Switch Language

- Bookmarks

- Checked Out

- Current Context

- Current To Do

- Favorite Links

- Favorite Scripts

Note: This example may not be available in your application; it is used for illustration purposes only.

Each User Can Customize Which Zones Appear

For any portal that is configured to show on portal preferences, each user has control over the following:

- Which zones appear on their portal

- The order in which the zones appear

- Whether the zones should be "collapsed" (i.e., minimized) when the portal opens.

Users define their preferences by clicking the User Preferences button. Pressing this button transfers the user to the User Preferences page on which their Portal Preferences can be defined.

CAUTION:

Recommendation. We strongly recommend that you set your preferences to collapse zones that you don't use often. Why? Because we don't perform the processing necessary to build collapsed zones until you ask to expand a zone. Opening a page with zones collapsed accelerates the response times of portal.

Users Must Be Granted Security Access To Each Zone

A user must be security granted access rights in order to see a zone on a portal.

Fastpath: Refer to Granting Access to Zones for information .

Zones May Appear Collapsed When A Page Opens

Portal Preferences allows the user to collapse a zone (or minimized) when a portal appears to reduce space for the zone while keeping the data easily available. To view the information in a collapsed zone, the user can press the zone's expansion button, , to either expand or collapse the zone:

CAUTION:

Recommendation. We strongly recommend that preferences be set up to collapse zones that may contain data that is only needed upon a user's request. The system doesn't perform the processing necessary to build collapsed zones until a user asks to expand a zone. As a result, indicating a zone is collapsed improves response times.

Dashboard Portal

The dashboard is a portal that always appears on the desktop. Its zones contain tools and data that are useful regardless of the object being displayed.

Note: Minimize the dashboard. You can minimize the dashboard by clicking on the vertical bar on the left side of the dashboard. This causes the dashboard portal to disappear allowing more of the page area to display. The vertical dashboard bar is then displayed on the right side of the page. Clicking the dashboard bar restores the display of the dashboard portal.

Keyboard Shortcut

Alt+J

The contents of this section describe the zones that are provided by the framework product for this portal. Please note the following additional information about the dashboard portal that may impact how it appears.

- Additional zones may be available in other products. The zones described below are available in every base product. Please refer to the product-specific documentation for additional dashboard zones available in your product (open the help and navigate to the index entry labeled Dashboard).

- Context Sensitive Zones may appear. Some pages may define additional zones that should appear in the dashboard only if that page is displayed. These are referred to as Context Sensitive Zones.

- Dashboard zones are configurable. The dashboard portal is configured to allow a user to define preferences for it. Refer to Portal Preferences for more information.

Note: Security. As a general rule, dashboard zones each refer to a unique application service so that a security administrator may configure which users are allowed to have access to which zones. Note that the user portal preferences indicates which zones a user has security access to.

Next in This Section

- Bookmarks Zone

- Current To Do Zone

- Favorite Links Zone

- Favorite Scripts Zone

- Favorite Searches Zone

- Switch Language Zone

- To Do Summary Zone

- Work List Zone

Bookmarks Zone

After clicking the Bookmark button and saving a bookmark, it is visible in the Bookmarks zone. Clicking one of the links in the zone navigates to the page where the bookmark was saved and loads the information related to the record that was displayed when the bookmark was saved.

Click the trash can icon to delete the bookmark.

Note that a user may change the name of the bookmark or change the sequence of the bookmarks by navigating to the User — Bookmarks in the user preferences.

Current To Do Zone

The Current To Do zone is designed to streamline the process of working on To Do entries from assignment to completion. It displays key information about the user's current To Do entry and provides functions that help minimize the number of steps it takes to resolve the entry and potentially other entries related to it.

The following sections provide more detail about the zone.

Next To Do Assignment

Users may have the option to click the To Do icon to request the next To Do entry they should work on. This functionality is optional and can be configured to follow your organization's business rules in determining the next task for a user. For example, if your organization practices work distribution "on demand", this feature can be configured to find the highest priority entry a user can work on and assign it to the user. Refer to work distribution for more information on this business practice.

Note: Next Assignment Rules Are In A Plug-in. Refer to Next Assignment Algorithm for more information on how to configure the system to take advantage of this function.

If the system is successful in determining the next entry the user should work on, this entry becomes the user's current To Do and its information is displayed on the zone.

User’s Current To Do

The user’s current To Do may be set using the Next Assignment algorithm, or by drilling in on a To Do from the To Do List or To Do Search page as described in A User's Current To Do. Once a current To Do has been set, the zone displays details related to the To Do.

The Message describes why the entry exists. The message description allows the user to drill into the page on which the entry's respective object is displayed. For example, if the entry is associated with an asset that needs review, the user is brought to the asset page to view the information and potentially take action. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched.

Info displays the standard To Do information. An Info icon appears if there are comments on the To Do and a Description icon appears if there is a log entry of type Forwarded, Sent Back or User Details on the To Do. The description drills into the To Do entry page allowing the user to view more information about the entry or make changes to it as needed.

The user may use the Complete button in the zone to complete the current entry.

Next / Previous To Do Buttons

The Previous To Do and Next To Do buttons are enabled on this zone under the following conditions:

- The user selected an entry either on the To Do List page or the To Do Search page.

- At least one other entry exists below (for Next) or above the entry selected (for Previous).

Clicking Next To Do or Previous To Do will bring the user to the transaction indicated on the To Do Entry’s message, where its respective object is displayed. It also makes that To Do the Current To Do displayed in the zone.

Keyboard Shortcut

Comments

Alternate Shortcut

Alt+Y

Previous To Do

Alt+Z

Next To Do

Alt+Shift+Z

Note: Refer to Shortcut Key Summary for information about the alternate shortcut.

Note: When a user drills down on a To Do entry from the To Do List page, the system automatically changes the status of the entry to Being Worked. If Next To Do or Previous To Do is subsequently used to scroll through this list, the system does not change the To Do entry's status. To change the status of these entries, the user must navigate to the To Do List. On this page, multiple entries may be selected and their status changed with a single user-interface action.

Related To Do Entries

If the To Do entry has non-complete related entries a summary Related To Do description appears. The description states the total number of related entries, how many are still in Open, how many are assigned to current user and how many assigned to others. This hyperlink navigates to the To Do Search query allowing the user to review the related entries. At this point the user may decide to assign entries that can be positively identified as being caused by the same problem as the current To Do also to himself.

If the user determines that all related To Do entries have been resolved with the appropriate action taken, the Complete All button may be used to complete in one step the current entry and all its truly related entries assigned to the current user.

If the related entries are not resolved with one action, the user may opt to use the Complete button to complete the current entry alone and work on related entries one at a time. Using the related To Do information hyperlink the user may navigate to the To Do search page and drill into the first related To Do to work on using the message hyperlink. This entry now becomes the user's current To Do and the Next To Do and Previous To Do action buttons are set to scroll through the related entries list.

Favorite Links Zone

Each line in the Favorite Links Zone corresponds with one of the user's favorite links (e.g., transactions). Clicking on a line invokes the transaction. A number appears adjacent to the first nine entries to highlight that these links can be invoked by pressing an accelerator key (Ctrl + a number). Note that the numeric keypad on your keyboard cannot be used to implement this function.

Users define their favorite links by clicking the User Preferences button. Clicking this button transfers the user to the User Preferences page on which their Favorite Links can be defined.

Favorite Scripts Zone

The Favorite Scripts zone lists the business process assistant (BPA) scripts that you have defined on your user preferences. You can click on a script to execute it. You can click the Search button in the zone to search for other scripts.

Note: If you do not see the Favorite Scripts zone in your dashboard, navigate to User Menu and click the Preferences menu item to display the User - Portal Preferences page. Under the Dashboard Portal row, select the Display option for the Favorite Scripts zone.

Favorite Searches Zone

If you marked a saved search as a favorite using Saved Searches functionality, the search is visible in the Favorite Searches zone. Clicking one of the links in the zone navigates to the page where the search was saved and populates the filter values and executes the search.

Switch Language Zone

The Switch Language zone is used to switch the application's language. Only languages that are supported by your implementation will appear.

To switch the application's language, choose the desired language and press the Refresh button.

Note: If your implementation uses a single language. If your implementation uses a single language, you should suppress this zone by not granting security rights to the zone's application service.

To Do Summary Zone

The To Do Summary Zone has several purposes:

- It presents a summary of the To Do entries that have been assigned to you and are Being Worked On.

- The colored "age bars" highlight the age of the To Do entries. The colors red, yellow and green are used to highlight the relative number of old, middle-aged and new To Do entries. The age associated with each of these colors is user-configurable. Note, you can hover the cursor over an "age bar" to see the number of To Do entries.

- If you click on the To Do Type description or on an "age bar", you'll be transferred to the To Do List transaction where these To Do entries will be displayed. From this page, you can drill down to the specific entries.

Note: Time saver! After you drill down on entry from the To Do List page, if you have the Current To Do zone configured in the dashboard, you can use the Previous To Do and Next To Do buttons in the zone to scroll through additional To Do list entries without returning to the To Do List page.

Work List Zone

The Work List zone provides quick access to an entire column of an info or query zone. When a user clicks on a work list entry, the system will do whatever it would have done if they'd clicked on the hyperlink in the zone. In addition, the system ticks off that they've worked on the entry (this feature is mostly so users know that they've at least looked at something). Refer to Work Lists to better understand how to configure query columns to support work lists.

User Preferences

The Preferences (or My Preferences) transaction and the User Maintenance transactions are the same except that with My Preferences, only the following items can be modified:

- Main Tab

- Language

- Display Profile

- Time Zone

- Email Address

- Dashboard Width

- Home Page

- To Do Summary Age Bar Parameters

- Bookmarks

- All information can be modified

- Portal Preferences

- All information can be modified

- Favorite Links

- All information can be modified

- Favorite Scripts

- All information can be modified

Next in This Section

- User - Main

- User - To Do Roles

- User - Access Security

- User - Bookmarks

- User - Portal Preferences

- User - Favorite Links

- User - Favorite Scripts

- User - Characteristics

- User - Miscellaneous

User - Main

This page lets you view or define user information and access settings.

To open the page, use one of the following navigation options:

- The Admin > Users > Search menu item.

- The Menu > My Preferences menu item.

- The User Menu > Preferences menu item in the application toolbar.

Note that some fields are only modifiable when the page is opened from the from the Admin menu.

Description of Page

Basic user identification information is viewed or set in the First Name, Last Name, User ID, and Login ID fields, all of which are modifiable only when the page is opened from the Admin menu. User and logon IDs must be unique. The Login ID is the id that the user uses to log in to the system. The User ID is the ID that is used throughout the application when users are assigned to tasks or when the user ID is stamped on records when logging add or update actions.

Language Code defines the language in which the user's screen prompts and messages appear.

Set User Enabled to allow the user to access the system.

Note: This field, available only when the page is accessed through the Admin menu, provides special field-level security. A user can change the field only if the Enable/Disable access mode is set.

Display Profile ID defines the display options for the user.

The next group of fields is used to view or set user preferences. For example, you can set up portal preferences on a "template user" and indicate that specified users will inherit their portal preferences from the template. Doing so provides consistency in the application of account information and dashboard zones. This fields are modifiable only when the page is accessed through the Admin menu.

- Set User Type to Template User if the user's preferences are to match those of other users.

- If a user's portal preferences are to be inherited from a "template user", use the Portals Profile User ID to define the user ID of the template user. If applied, the specified user will inherit portal preferences from the Portals Profile User ID and will be unable to customize those preferences.

- If a user's favorite links are to be inherited from a "template user", use the Favorites Profile User ID to define the user ID of the template user. If applied, the specified user will inherit favorites preferences from the Favorites Profile User ID and will be unable to customize those preferences.

The Time Zone associated with the user may be defined. Implementations may use this information for features and functions where the user's time zone impacts display of data.

Email ID captures the user's email address.

Dashboard Width defines the number of pixels to use for the user's dashboard area. A setting of 200 is recommended as a minimum. Depending on the width of a user's monitor, a higher setting (such as 250) will display more information without compromising the space on the main area of the application. Setting the value to 0 will suppress the dashboard.

Home Page defines the page that appears when the user starts a session or clicks the Home link.

The To Do entry fields control how To Do entries are aged in respect of the "age bars" that appear on To Do Summary, To Do Supervisor Summary and the To Do Summary Dashboard Zone.

- Use Lower Age Limit for Yellow Bar to define the number of days old a To Do entry must be to be considered "yellow" in the age bar. To Do entries below this limit are considered "green" in the age bar.

- Use Upper Age Limit for Yellow Bar is the high limit for the "yellow" bar. To Do entries older than this are considered "red" in the age bar.

The User Group collection defines the group(s) with which the user is associated and the date (if any) when the user's association expires. This feature is modifiable only when the page is accessed through the Admin menu. For more information, see The Big Picture Of Application Security. Assignments of users in a user group can also be established or maintained through the User Group - Users page.

Note: The ability to maintain the user groups on this page requires special field-level security. A user can change the field only if the System Administration access mode is set.

User - To Do Roles

Open the User page and then navigate to the To Do Roles tab to define the To Do roles assigned to the user.

The information on this page cannot be modified if accessed through My Preferences.

Fastpath: A user's To Do roles control the types of To Do entries the user can access. For additional information on To Do roles, see To Do Entries Reference A Role.

Description of Page

The grid contains the user's To Do roles. To modify a To Do role linked to the user, simply move to a field and change its value. To remove a To Do role, click the - (minus) button. To add a new To Do role, click the + (plus) button and enter the role.

Where Used

Every To Do entry references a role. A To Do role has one or more users (and a user may belong to many To Do roles). Users who are part of the To Do role assigned to a To Do entry may work on the To Do entry. For more information on this feature, see The Big Picture Of To Do Lists.

User - Access Security

Open the User page and then navigate to the Access Security tab to define a user's security rights. You cannot modify this page if you accessed it through My Preferences.

Fastpath: Refer to The Big Picture of Application Security for more information about data access roles and access groups.

Description of Page

Use the Default Access Group to define the access group that is defaulted on new records added by this user that are subject to row security.

The scroll area contains the Data Access Roles to which this user belongs. A user's data access roles play a part in determining the accounts whose data they can access.

To add additional data access roles to this user, click the + button and specify the following:

Enter the Data Access Role. Keep in mind that when you add a Data Access Role to a User, you are granting this user access to all of the accounts linked to the data access role's access groups.

Use Expiration Date to define when the user's membership in this data access role expires.

Note: You can also use Data Access Role - Main to maintain a data access role's users.

The tree highlights the Access Groups to which the above Data Access Roles provide access.

User - Bookmarks

This page is used to manage a user’s bookmarks that are created when a user clicks the Bookmark button and saves a bookmark. From this page the user can delete a bookmark, change the name of the bookmark or change the sort sequence.

Open the User page and then navigate to the Bookmarks tab to modify or delete a bookmark.

Description of Page

Sequence is the sort sequence associated with the bookmark. Bookmarks with the same sequence are then sorted alphabetically.

Name is the user-defined name assigned to the bookmark. This is the text that is visible in the Bookmarks dashboard zone.

Note: Favorite Links vs. Bookmarks. Favorite links are configured through the user page and define pages that a user can navigate to. They do not define context (although some pages may use information currently in global context when navigating). Some users may not be allowed to configure their own favorite links and would see the favorite links associated with a profile user. Bookmarks are created using a bookmark button available on each page. The bookmark saves navigation information, context information and also captures some information about the state of a page. Bookmarks are not governed by any user profile configuration.

User - Portal Preferences

The base product contains several portals that allow users to customize them via portal preferences. Portal preferences allow users to control:

- Which zones appear on the portal

- The order in which the zones appear

- Whether the zones should be "collapsed" (i.e., minimized) when the portal opens.

Note: You may not be able to change your portal preferences. If a note appears immediately before the list of portals, a system administrator has configured your user ID to reference a Portals Profile User ID (this is defined on the Main tab). Preferences set in this way cannot be modified. System administrators do this in order to enforce a common look-and-feel throughout the user community.

Open the User page and then navigate to the Portal Preferences tab to modify a user’s preferences.

Description of Page

The accordion contains a row for every portal configured to show on user preferences and to which you have access. To change how a portal's zones appear, expand the respective row and change the elements accordingly. The remainder of this section describes how you can configure how a portal's zones appear.

Zone lists all of the zones in the portal.

Place a check under Display if the zone should be displayed on the portal.

Place a check under Initially Collapsed if the zone should be minimized when the portal is initially opened. Setting zones as initially collapsed is a good idea to save space and to help pages to load more quickly. Refer to Zones May Appear Collapsed When A Page Opens for more information.

Use Sequence to control the position of the zone in respect of the other zones. This field is disabled if Display is not checked. Duplicate Sequence numbers are allowed.

For zones displaying data that is changing often, use Refresh Seconds to define in seconds how often the zone is refreshed. The minimum valid value is 15. The maximum valid value is 3600 (1 hour). A value of 0 indicates no automatic refresh.

Security Access indicates whether the user has access rights to a zone. Refer to Granting Access To Zones for more information.

User - Favorite Links

This page is used to define a user's favorite transactions and URLs. Each such link appears as an entry in the Favorite Links Zone in the Dashboard area.

Note: A hot key can be used to execute a favorite link. Rather than clicking a button in the favorite links zone, you can invoke your first nine favorite links by pressing Ctrl + a number (where the number corresponds with the relative position of the transaction in your list of favorites). Note that the numeric keypad on your keyboard cannot be used to implement this function.

Open the User page and then navigate to the Favorite Links tab to modify a user’s favorite links.

Description of Page

Note: You may not be able to change your favorite links. If a Note appears beneath your User ID, your user id has been setup to reference a specific Favorites Profile User ID as defined on the Main tab. If a system administrator has setup your user ID in this way, your preferences may not be changed. System administrators may apply this feature in order to enforce a common look-and-feel throughout the user community.

Each row references a Navigation Option. The navigation options supplied with the base package correspond with the system's menu items. This means you can setup a favorite link to open any transaction in the system (in either add or update mode).

Note: Favorite links can point to other places. The navigation options supplied with the base package always open a transaction's Main tab. If you find yourself continually accessing a different tab page, you can have your implementation team create a new navigation option that references the desired tab page. Once this navigation option is set up, you can reference it as one of your favorite links. In addition, it's also possible for your implementation team to setup navigation options that open a URL outside of the system. For example, your implementation team could setup a navigation option to a credit rating company's website. Once this navigation option is set up, you can reference it as one of your favorite links.

Use a Sequence to control the order in which the navigation option appears in the Favorite Links Zone.

Security Access indicates if you have been given security rights to the respective transaction. Refer to The Big Picture Of Application Security for more information.

Note: Favorite Links vs. Bookmarks. Favorite links are configured through the user page and define pages that a user can navigate to. They do not define context (although some pages may use information currently in global context when navigating). Some users may not be allowed to configure their own favorite links and would see the favorite links associated with a profile user. Bookmarks are created using a bookmark button available on each page. The bookmark saves navigation information, context information and also captures some information about the state of a page. Bookmarks are not governed by any user profile configuration.

User - Favorite Scripts

This page is used to define a user's favorite scripts. Each script is displayed in the Favorite Scripts zone on the Dashboard portal where it can be used to initiate a script.

Note: A hot key can be used to execute a favorite script. Rather than selecting a script from the business process assistant, you can invoke your first nine favorite scripts by pressing Ctrl + Shift + a number (where the number corresponds with the relative position of the script in your list of favorites). Note that the numeric keypad on your keyboard cannot be used to implement this function.

Open the User page and then navigate to the Favorite Scripts tab to modify a user’s Favorite Scripts.

Description of Page

Note: You may not be able to change your favorite scripts. If a Note is displayed on top of the grid, your user id has been setup to reference a specific Favorites Profile User ID as defined on the Main tab. If a system administrator has setup your user ID in this way, your preferences may not be changed. System administrators may apply this feature in order to enforce a common look-and-feel throughout the user community.

Each row in the grid contains one of your favorite Scripts.

Use the Sort Sequence to control the order in which the scripts appear in the business process assistant menu.

Security Access indicates whether you have access to the script's application service. Refer to The Big Picture Of Application Security for more information.

User - Characteristics

Select Admin > User > Search and navigate to the Characteristics tab to define characteristic values for the user. You cannot modify this page if you accessed it through My Preferences.

Description of Page

Use the characteristics grid to capture additional information about the user.

You can only choose Characteristic Types defined as permissible for the user record. Refer to Setting Up Characteristic Types & Their Values for more information.

Enter a valid Characteristic Value for the selected characteristic type. You may enter more than one characteristic row for the same characteristic type, each associated with a unique Sequence number. If not specified, the system defaults it to the next sequence number for the characteristic type.

User - Miscellaneous

Select Admin > User > Search and navigate to the Miscellaneous tab to view additional information associated with a user.

User Id, First Name and Last Name are displayed. Depending on your implementation, additional zones may appear on the User Portal

If additional zones appear, use the embedded help for information about the fields managed on the zone.

Initiating Scripts

Your implementation team can set up business process assistant (BPA) scripts to walk you through business processes. Once scripts have been set up, you can initiate a script using any of the following methods:

- You can define a list of your "favorite scripts" on your user preferences. You can then invoke any of the scripts from the Favorite Scripts zone on the dashboard portal. You can also invoke any of your first 9 favorites by pressing Ctrl + Shift + a number (where the number corresponds with the relative position of the script in your list of favorites). For example, if you press Ctrl+Shift+2 and you've setup your "favorite scripts" to be Start Autopay and Stop sending marketing information; the Stop receiving marketing information script is invoked. Note that the numeric keypad on your keyboard cannot be used to implement this function.

- You can configure a menu item to launch a script by referencing a navigation option that is a script navigation option type.

- The system creates To Do entries to highlight tasks that require attention (e.g., bills in errors, accounts without bill cycles, etc.). Users can complete many of these tasks without assistance. However, you can set up the system to automatically launch a script when a user selects a To Do entry. For example, consider a To Do entry that highlights a bill that's in error due to an invalid mailing address. You can set up the system to execute a script when this To Do entry is selected. This script might prompt the user to first correct the customer's default mailing address and then re-complete the bill. Refer to Executing A Script When A To Do Is Launched for more information.

- You can indicate that a script should be launched upon entering the system. This functionality enables an external system to launch the system and immediately launch a script.

- The following hot keys cause an interactive menu is displayed:

- Ctrl+Alt+Q

- Ctrl+Shift+S

The menu allows you to search for a script using any word in its description. Note, if you've turned on Search only Eligible Scripts, your search is limited to eligible scripts. Note, the system displays an indication if each script in the grid is Eligible or Ineligible in this section.

You can initiate a script from this area by clicking on it.

When a script is initiated, this menu closes and the object display area shifts down to make room for the script area.

Note: Securing scripts. Only scripts the user is allowed to execute are displayed. Refer to Securing Script Execution for more information.

Note: Customize the script area. Using the Height step type, an individual script may be configured to use more or less of the script area than the standard script area. It is also possible to configure a script to hide the script area altogether.

The information in the script area takes you through the steps in the selected business process (note, your implementation team controls the information that appears in the script area).

The following points highlight useful information common to all scripts:

- Return focus to script area. Often during a script the focus moves from the script area to another section of the page. For example, you might be required to fill in data for a new record being added. When you are ready to return to the script area, rather than using the mouse to return to the area, you can press Ctrl+Shift+F. The focus returns you to either the first available input field or to a "default" button if no input field is available.

- The Continue button. Many steps in a script ask you to click the Continue button when you're ready to restart a script. For example, a step may ask you to confirm a customer's automatic payment information and then click Continue when you're ready for the script to restart. Rather than using the mouse to click this button, you can press Ctrl+Shift+C.

- Selected button changes color. When you click a button in the script area, the button selected changes color so that you can easily see which option you selected.

Fastpath: Refer to The Big Picture Of Scripts for more information about scripts.

Note: You can abort a script at any time by clicking the red X button in the upper right corner of the script area (or by pressing Ctrl+Shift+X).

Shortcut Key Summary

The following table summarizes the keyboard shortcuts (hot keys) available in the system:

Note: It is possible that your specific product supports additional shortcut keys. Refer to your product documentation for more information.

Note: It is possible that some of the following system accelerator keys may duplicate shortcuts, or hot keys, that are predefined within your browser. If this is the case, the browser's functionality commonly takes precedence.

Note: It is possible that your implementation uses one of the accelerator keys listed below for a different purpose. For example, in some languages, a shortcut key may be used for a special character in the alphabet not included on all keyboards. It is possible to turn off any of the Alt+letter shortcuts and Ctrl+Alt+letter shortcuts listed below using a properties file entry. The property is ouaf.shortcut.ignore.altKeys= where one or more letters may be entered separated by a comma. When setting this property, the system automatically enables a 'potential alternate key' for certain functions (see the table below). Refer to the Server Administration Guide for more information about the property.

Accelerator Key

Potential Alternate Key (see Note above)

Function

Ctrl+Alt+A

Opens the Admin Menu button.

Alt+B

Returns to the previous page on which you were working. This is the equivalent of clicking the Back button.

Ctrl+Alt+B

Launches the Bookmark dialog. This is the equivalent of clicking the Bookmark button.

Alt+C Ctrl+Alt+C Alt+Shift+C

Clears the currently displayed object from the page. This is the equivalent of clicking the Clear button.

Ctrl+Shift+C

If the current step in the Script area has a Continue button, this shortcut is equivalent to clicking Continue.

Ctrl+Alt+D Alt+D

Creates a duplicate of the object being displayed. Equivalent to clicking the Duplicate button.

Ctrl+Alt+F

Positions the user's cursor to the Menu Item Search input field.

Ctrl+Shift+F

If the Script area is open and you are working on a different area of the page, this key returns focus to the script area. Focus returns to either the first available input field or to a "default" button if no input field is available.

Alt+G

Returns to the most recent page that was displayed when the Back button was clicked. Equivalent to clicking the Forward button.

Ctrl+Alt+H

Opens a dropdown list of recently-visited pages, the equivalent of clicking the History button.

Alt+J

Minimizes the dashboard. It also expands the dashboard, if it was minimized.

Alt+K

Transfers you to To Do Entry - Main for the current item in the To Do list. Pressing Alt+K while on this page takes you to the first To Do entry on the list.

Ctrl+Alt+L

Logs the user out of the system. This is equivalent to clicking the Logout menu item.

Ctrl+Alt+M

Opens the Menu button.

Alt+N

Alt+Shift+N

Displays the next entry in the search results. Equivalent to clicking Next Item.

Alt+O

Alt+Shift+O

Navigates to the user's home page. Equivalent to clicking the Home button.

Ctrl+Alt+P

Opens your User Preferences page. Equivalent to clicking the Preferences menu item.

Alt+P

Displays the previous entry in the search results. Equivalent to clicking Previous Item.

Ctrl+Alt+Q

Opens the business process assistant, where you can select a script that walks you through a business process.

Alt+R Ctrl+Alt+R

Refreshes the page with the last saved version of the object being displayed in the page. Equivalent to clicking the Refresh button.

Alt+S

Alt+Shift+S

Saves any changes that you've made on the database. Equivalent to clicking the Save button.

Ctrl+Shift+S

Opens the business process assistant, where you can select a script that walks you through a business process.

Alt+X

Alt+Shift+X

Opens the To Do Summary.

Ctrl+Shift+X Ctrl+Shift+Z

If the Script area is open, equivalent to clicking the Close button in the script area. If a pop-up window is open, this closes the window.

Alt+Y

Displays the previous item in the To Do list. Equivalent to clicking the Previous To Do button in the Current To Do zone.

Alt+Z

Alt+Shift+Z

Displays the next item in the To Do list. Equivalent to clicking the Next To Do button in the Current To Do zone.

Alt+Insert

Inserts a new row into an editable grid if the insertion point is in the grid. Equivalent to clicking the Insert button.

Alt+Delete

Removes a row from an editable grid if the insertion point is in the grid. Equivalent to clicking the Delete button.

Alt+F1

Invokes online Help for the application. Equivalent to clicking the Help button.

Alt+1 ...Alt+9

These keys are only applicable when a page / portal with multiple tabs is open. The shortcuts open the tab page whose relative position corresponds with the shortcut number. For example, if you press Alt+3 on a page with multiple tabs, the third tab is displayed. If there are more than nine tabs on a page, you must use the mouse or F2/Shift+F2 to display a tab. Note that you cannot use the numeric keypad for these shortcuts.

Ctrl+1 ...Ctrl+9

Invokes the favorite link whose relative position corresponds with the shortcut number. For example, if you press Ctrl+3, the transaction for your third "favorite link" is invoked. Note that you cannot use the numeric keypad for these shortcuts.

Ctrl+Shift+1 ... Ctrl+Shift+9

Invokes the favorite script whose relative position corresponds with the shortcut number. For example, pressing Ctrl+Shift+2 selects the second of your "favorite scripts". The numeric keypad cannot be used for these shortcuts.

Alt+left arrow

Populates a scroll area with the previous entry. Equivalent to clicking the scroll control .

Alt+right arrow

Populates a scroll area with the next entry. Equivalent to clicking the scroll control .

Enter when in a field with an adjacent Search button

Invokes the search. Equivalent to clicking the Search Button.

Enter when a row in a search result grid is highlighted

Selects the item and closes the search. Note that after selecting an item from the search results, you can press Alt+N or Alt+P to scroll up or down through other items in the result grid without returning to the search results.

Enter when a menu item is highlighted

Selects the menu item.

Enter when the insertion point is within a tree node

Equivalent to clicking on the item in the tree:

- If the insertion point is on a node image, the node is either expanded or collapsed, dependant on its current state.

- If the insertion point is on a context menu, the context menu is opened and normal menu processing applies.

- If the insertion point is on a "link" element, normal navigation processing occurs.

Tab when a row in a search result is highlighted

Highlights the next row.

Shift + Tab when a row in a search result is highlighted

Highlights the previous row.

Space when the insertion point is on a button

Equivalent to pressing the button.

Space when the insertion point is in a date/time field

Opens the date/time selection window.

Space when the insertion point is in a check box

Toggles the check box between checked and unchecked.

Page Up while in a list grid

Scrolls the contents of the list grid up approximately one page.

Page Down while in a list grid

Scrolls the contents of the list grid down approximately one page.

Up or Down Arrow when in a dropdown list

Moves to the next or previous value in the list. You can also press a letter key to locate the next value starting with that letter.

Up or Down Arrow keys when in search results

Highlights the next/previous row in search results.

Up, Down, Left or Right Arrow when using a menu

Highlights other menu items.

Esc when using a menu

Closes the menu.

F2

Opens the next tab page when viewing a page / portal with multiple tabs.

Shift+F2

Opens the previous tab page when viewing a page / portal with multiple tabs.

Portal and Zone Features

This section describes using portals and zones to find and display information. This is the preferred technique used by the base product for query and maintenance dialog.

Additionally, portals and zones may be configured by your implementation to supplement the base package provided functionality.

Next in This Section

- Zone Types and Characteristics

- Common Base Portals and Zones

Zone Types and Characteristics

The topics in this section describe common zone types, function, and common characteristics.

Fastpath: Refer to The Big Picture of Portals and Zones for a description of general portal and zone functionality.

Next in This Section

- Common Characteristics of Zones

- Explorer Zones

- Map Zones

- Timeline Zone

Common Characteristics of Zones

The following topics describe common characteristics of all zone types supported by the base package.

Next in This Section

- Zone Visibility

- Control Zone Headers

Zone Visibility

A zone may be configured to dynamically be visible or completely hidden depending on the information being displayed. When hidden, not even the header is displayed.

For configuration information, refer to Zone Visibility Service Script.

Control Zone Headers

A zone may reference a UI Map to define and control its header. This feature provides the means to achieve a uniform look and feel for the application as well as add functionality to the zone header beyond being just a title bar to open and close the zone. Refer to UI Map and to its context sensitive tips zone for more information on Fragment UI Maps and how they are used to construct zone headers.

Explorer Zones

The product provide several zone types that are used to find or display a set of information. These are called explorer zones. There are two types of explorer zones:

- Info zones. An info zone displays a list of information about an object. These types of zones often display information without requiring any input from the user.

- Query zones. A query zone allows users to find objects matching a given search criteria.

Virtually every aspect of an info or query zone is controlled by its zone configuration. However, most share basic common components described in the subsequent sections.

Next in This Section

- Search Criteria / Filter Area

- Description Bar

- Results Area

- Title Bar

- Configurable Columns

- Multi-Query Zones

Search Criteria / Filter Area

For query zones, the Search Criteria Area (also called Filter Area) contains the criteria used to find objects. The design of the zone controls the number and type of filters that appear in this area. After search criteria is entered, clicking the Search button causes the system to look for records that match the criteria. The results are shown in the Results Area.

For info zones, the zone's configuration indicates whether or not a Filter area is applicable and if so, whether or not it is open or closed by default. If the filter area is configured, the Show Filter icon is visible in the zone header. Click this icon to expose the Filter Area, if it is not visible and click the icon to hide the Filter Area if desired. Use this area to filter the information that appears in the zone by different values. Click the Search button to rebuild the Results Area using the specified filters.

For example, the following shows an info zone listing user groups that do not have access to a given Application Service where a filter area has been configured to allow users to show user groups specific to a given user by ID or name.

The info zone includes configuration to indicate whether the filter area, when exposed, should be shown at the top of the zone (above the results) or at the bottom of the zone (below the results). For query zones, the search criteria is always displayed at the top.

Note: Press Enter. Rather than clicking the Search button, you can press Enter to trigger the search / info zone refresh.

Description Bar

The Description Bar describes the search criteria that were used to build the Search Results Area.

Results Area

The Results Area displays the appropriate list of objects. For an info zone, this is the list of appropriate objects with any input filter criteria considered. The following is an example of the results for an info zone. For a query zone, this is the list that matches the search criteria defined in the Filter Area. The following is an example of the results set of an Info Zone.

For a query zone, the columns that appear may differ depending on the search criteria. For example, if you search for a customer by their driver's license number, the resulting columns may be different than the ones displayed when you search by customer name.

The following points highlight details related to viewing and working with the result set:

- Broadcast. If the results set is configured to display a broadcast icon, , it means that at least one other zone on the portal is configured to display data related to the record selected in the results list. Clicking this icon will cause the other zone or zones to be built or refreshed to display related data.

- Hypertext. One or more columns in the zone may be configured as hypertext. Clicking the hypertext will result in navigating to another page to display data related to that column based on the configuration for that column.

- Maximum height. The maximum height of the report area is controlled by the zone's configuration. A vertical scroll will appear when more rows exist than fit into the height.

- Maximum rows. The maximum number of rows that can appear is controlled by the zone's configuration. Excess rows are truncated before display. Please note, you can configure the zone to download more rows to Excel than appear in the Results Area.

- Control column sorting. By default zones are designed to allow a user to sort the results list by clicking any column heading. Clicking once sorts ascending. Clicking again sorts descending. However, a zone may be configured to not allow this type of sorting.

- Rearranging columns. A zone may be configured to allow a user to rearrange columns and add or remove columns visible in the Result Area. Refer to Column Configuration for the details.

The type and variety of columns that appear in the Results Area is controlled by the zone's configuration. You can even set up an info zone to display information in hierarchical trees. For example, the following info zone from Oracle Utilities Customer Care and Billing has been configured to show a person’s related persons.

Title Bar

The Title Bar contains the zone's description along with other icons and functions described in this section.

In the corner of the Title Bar, you'll see an indicator that tells you whether the zone is collapsed (e.g., minimized) or expanded. Each time you click the indicator, the zone toggles between expanded and collapsed. The following image shows a collapsed zone.

Note: Recommendation: For zones that are configured to show on portal preferences, set up Portal Preferences to collapse zones that aren't needed every time a portal is displayed. Rationale: The system doesn't build collapsed zones when a portal is displayed. Instead, collapsed zones are only built when a user expands them. Thus, indicating a zone is collapsed improves response times.

If the zone is configured with help text, a help icon appears to the right of the zone title. Click this icon to view the help text.

If a saved search is open for a zone, the name of the saved search is displayed after the zone title.

The following sections describe additional icons and tools visible on the title bar. Note that in addition to the information described in this section, additional actions that are specific to a zone may appear based on configuration. The actions may appear in the form of hypertext, an icon or a button.

Next in This Section

- Explorer Zone Menu

- Show Filters

- Show Column Configuration Area

- The Open Zone Maintenance Icon

Explorer Zone Menu

Click the Explorer Zone Menu icon to list available tools. The following topics describe each tool.

Next in This Section

- Clear Filters

- Export to Excel

- Print

- Save Search Options

Clear Filters

Click the Clear Filters link in the Explorer Zone menu to clear the filter values and zone data.

Export to Excel

Click the Export to Excel link in the Explorer Zone menu to download the zone's data to Excel. This link is hidden if the zone has been configured to not download rows to Excel.

Print

Click the Print Zone link in the Explorer Zone menu to print the zone.

Save Search Options

Query zones and info zones that include filter areas, allow a user to capture and save filter criteria so that the same search can be more quickly executed in the future. Users may save many different search options for the same zone. Users also have the option to nominate one search as the default so that this search is automatically loaded upon entering the zone. In addition, users may choose to set one or more searches as a Favorite, which causes the search to appear in the Favorite Searches zone in the dashboard. This allows a user to navigate to the portal for that zone and load the saved search in one click.

The Explorer Menu includes various options for supporting Saved Searches that are described below.

Note the following additional points about this functionality:

- Click Search before Saving. When a user wants to save a search, the search criteria should be entered and the Search button should be clicked prior to saving the search.

- Criteria is saved, not results. Although a user must click Search prior to saving the search, the system saves the criteria, but not the results. When returning to the query or info zone in the future and opening a given saved search, the results displayed will be the current records in the system that match the saved search criteria.

- Multi-Query Zones. When a user is on a multi-query zone, the searches are saved at the multi-query zone level so that all saved searches for the various search dropdowns for a given multi-query zone are visible in the Open Saved Searches menu option.

- Functionality is Secured. If for any reason an implementation wishes to restrict which users are allowed to save searches, the functionality is securable. Only users with Inquire access to the F1_USRFAVSCH application service will see these options in the explorer menu. This is the same application service that is used to provide access to the Favorite Searches dashboard zone.

Next in This Section

- Save As

- Open Saved Search

- Save

- Set As Default

- Remove As Default

- Add To Favorites

- Remove From Favorites

- Delete

Save As

The Save As... option in the Explorer Zone menu allows a user to save the current entered search criteria. This should be clicked after executing the search.

The user is prompted to provide a name for the search. This search is now available from the Open Saved Searches option. If desired, a user can also choose to make this search the Default or may choose to Add to Favorites.

This option is visible whether or not an existing saved search is loaded. When a saved search is loaded, this option allows a user to make changes to the search criteria and save a new search with that criteria.

Open Saved Search

The Open Saved Search... option in the Explorer Zone menu is visible if there are any saved searches for the zone that is currently visible. Select this menu entry to view the current list of saved searches for the zone. For multi-query zones, any saved search for any of the query zones that are part of the multi-query zone are visible. Choose the desired saved search. The criteria is updated with this information and the search is performed.

Save

The Save option in the Explorer Zone menu is visible if a Saved Search is already loaded. This option allows a user to save changes to the criteria of an existing saved search (overwriting the previously saved criteria).

Set As Default

The Set As Default option in the Explorer Zone menu is only visible if a saved search is loaded and it is not currently the default. Click this option to nominate this search to be the one that is loaded when navigating to this zone from the menu.

Remove As Default

The Remove As Default option in the Explorer Zone menu is only visible if a saved search is loaded and it is currently the default. Click this option to no longer load this search automatically when navigating to this zone from the menu.

Add To Favorites

The Add To Favorites option in the Explorer Zone menu is only visible if a saved search is loaded and it is not currently included in the favorite searches zone. Click this option to include this search in the Favorite Searches zone. Once a search is in the Favorite Searches zone, you can use the link to the search in the dashboard to navigate to the portal for this zone and load the saved search in one click.

Note: Not available for dependent zones There are some portals that include a zone that is not the main query or info zone on the portal, but is rather a zone providing additional information for a record that is displayed. If a zone like this has filter options or configurable columns, a user is able to save searches and mark one as a default, but will not be able to add the saved search to favorites because the zone is dependent on other data on the page that is not captured for the individual zone.

Note: Dashboard Zone Preferences. Be sure that your portal preferences are configured to include the Favorite Searches dashboard zone.

Remove From Favorites

The Remove From Favorites option in the Explorer Zone menu is only visible if a saved search is loaded and it is currently included in the Favorite Searches zone. Click this option when you want to keep the saved search but you no longer want it visible in your Favorite Searches zone. (Deleting a saved search that is also marked as a favorite will automatically remove the search from the favorite searches zone.)

Delete

The Delete option in the Explorer Zone menu is only visible if a saved search is loaded. Click this option to remove the currently opened saved search from the list of saved searches.

Note that if the saved search had been configured as favorite, deleting the saved search remove it from the favorite searches zone.

Show Filters

Click the Show Filters icon to show the Filter Area. This button only appears if the zone has been configured to have filters.

Note: If the zone is configured to have filters and the drag and drop (column configuration) area, only one or the other is shown at any given time. It means that a user can either change the filter criteria and refresh the search results or change the column configuration and refresh the results.

Show Column Configuration Area

Click the Column Configuration icon to show the Column Configuration Area. This button only appears if the zone has been configured to allow columns to be dragged and dropped into the Results Area.

Note: If the zone is configured to have filters and the drag and drop (column configuration) area, only one or the other is shown at any given time. It means that a user can either change the filter criteria and refresh the search results or change the column configuration and refresh the results.

The Open Zone Maintenance Icon

Click the "wrench" icon to switch to the zone's zone maintenance page. On this page, you can change the parameters that control the zone's behavior.

Note: Debug mode only. This icon only appears when the system operates in Debug mode.

Configurable Columns

Info zones and query zones may be configured to allow users to rearrange columns and to remove or add columns to the output. This is also referred to as "drag and drop" of columns.

When a zones is configured to support this functionality, the Show Column Configuration Area icon is visible in the zone title area. Click this icon to expose the Column Configuration Area, if it is not visible and click the icon to hide the Column Configuration Area if desired.

If configurable columns are allowed, a user may rearrange the order of columns currently displayed in the Results Area by clicking the column heading and "dragging" it to the desired location.

In addition, the column configuration area may display columns that are not currently in the Results Area. These are indicated by a cream background. A user can drag one of these columns to the results area and then click Refresh to rebuild the zone. To remove a column that is currently in the results area, click the trash can icon next to the column name in the column configuration area and then click Refresh to rebuild the zone.

The following is an example of how the Column Configuration Area looks:

Multi-Query Zones

This type of zone combines individual Query Zones into a single query zone. A Search By dropdown, built from the zone descriptions of the individual Query Zones, allows you to select the desired query to execute. Selecting a specific Query Zone display the filters of that query in the filter area. At this point the zone simply executes the selected Query Zone, as if it was executed on a standalone zone. By default, the first query zone option is selected.

Map Zones

A map zone displays information related to one or more objects. For objects that are maintained using portal-based pages, the standard display of the object is using a map zone. Map zones may be configured to display an explicit map or may dynamically display the map based on the configuration of the record being displayed.

Because the information displayed in a map zone is configured using HTML, virtually any format supported by HTML is possible. The following is an example of a typical map zone used to display information about an object.

A tool tip can be used to display additional help information for the details shown in a map zone. The tool tip may appear adjacent to the section header or adjacent to individual elements on a map.

Note: You can customize the help icon or disable map help using the Custom Look and Feel feature configuration.

Next in This Section

- Open Map Maintenance Icon

Open Map Maintenance Icon

Click the "hammer" icon to switch to the UI map maintenance page. On this page, you can view the HTML configuration for the zone. Note that for map zones that display a business object configured without a map, the elements displayed are automatically rendered. In this case, no "hammer" icon is visible.

Note: Debug mode only. This icon only appears when the system operates in Debug mode.

Timeline Zone

A timeline zone is used to show events over time for multiple types of data. This type of zone is helpful for providing a consolidated view of separate events occurring in time that may in fact impact each other. For example, in the billing system, a timeline can show bills, payments and collection processes for the same time period.

The topics in this section describe the rich functionality available in timeline zones.

Timelines Zones Are Configured By Your Implementation Team

The product provides support for creating timeline zones. However, whether timeline zones are configured for your implementation and on which portals they may be visible will depend on your specific configuration. Refer to Configuring Timeline Zones for general information about configuring timeline zones. Refer to your specific edge application’s documentation for details about what type of timeline information is provided out of the box.

The Anatomy Of A Timeline Zone

The following illustration highlights the various elements in a timeline zone. These elements are described in the remaining topics.

You Can Move Through Time

You can click the controls at the top of a timeline zone to change the date-range of the zone's information:

The following points describe how to use these controls:

- To reposition the timeline to a specific date, selected the desired month and year and click the search button.

- To go back one year, click the double-left arrow.

- To go back one month, click the single-left arrow.

- To go to today, click the red line (between the arrows).

- To go forward one month, click the single-right arrow.

- To go forward one year, click the double-right arrow.

Timelines Can Have Many Lines

Depending on how a timeline zone is configured, it will typically have one or more "lines" that show when significant events have occurred. Each line represents a specific type of data. The data may be related to a specific maintenance object, for example, payments may be displayed in one line and bills in another. It may also be possible to create multiple lines for different types of records for the same maintenance object. For example, if your product provides an algorithm to display cases, it may support defining a different entry for each case type.

Each Line Shows Events

Each line on a timeline may contain zero or more events where each event shows the date when the event occurs. For example, the payment line in a timeline has a separate event for every payment received from the customer. Each line's description contains the number of events on the line.

CAUTION:

If a line has more events than can fit onto a timeline, the line will show the first "chunk" of events and a message will appear in the "more info area" explaining that some events have been truncated. If this happens and the truncated events are in a later period, you can reposition the timeline's base period to show the truncated events. Refer to the You Can Move Through Time section above for more information

An Event's Color And Icon Can Convey Information About The Event

The timeline zone is driven by algorithms and the algorithms may be configured to highlight different types of events in different colors and / or icons. For example, a timeline that shows payments may use different colors and/or icons to visually differentiate between canceled payments and frozen payments.

An Event's Hover-Text Can Contain Additional Information

The timeline zone supports providing hover text that appears when a user hovers the mouse over an event. Each type of event can have different hover text. Typically the standard information string is shown for each event.

Clicking On An Event Shows More Information In The Detail Area

When you click on an event, additional information appears in the zone's detail area (at the bottom of the zone). The following information may appear:

- The event's common "information string" appears. This information is hypertext to allow for easy access to the transaction on which the object is maintained.

- Additional information may appear. This is dependent on the particular timeline algorithm. Refer to each timeline algorithm's description to find out if additional information appears in the detail area under any conditions.

- If the algorithm has configured BPA scripts that can be executed to perform business processes on the object, the BPA script description appears prefixed with a "wizard's hat" icon.

Common Base Portals and Zones

The following sections describe common standards followed by the product for base query and maintenance dialogue.

Next in This Section

- All-In-One Portal

- Separate Query and Maintenance Portals

All-In-One Portal

The all-in-one portal is used for low volume objects, where a small number of records are expected.

For example, many control tables use this style of portal. In this portal, rather than separate query and maintenance portals, a single portal allows a user to find a record and maintain the record. A zone listing all existing records is displayed when first entering the portal. A user can perform actions on existing records or add new records from there. More details about the list zone are provided below.

Refer to Maintenance Portal for information about zones commonly found on maintenance portals.

The all-in-one portal will typically provide the ability to add a new record. This may be a button in the Page Action area or a hyperlink defined directly on the list zone’s header area.

Next in This Section

- List Zone

List Zone

This info zone appears when first entering the portal and displays a row for each record.

The following functions are commonly available in a list zone:

- A broadcast icon is included in each row. Clicking this icon opens other zones that contain more information about the adjacent record.

- An Edit icon may be included in each row. Clicking this icon launches the maintenance BPA script to modify the adjacent record.

- A Duplicate icon may be included in each row allowing the user to duplicate the adjacent record without having to first display the record.

- A Delete icon may be included in each row allowing the user to delete the adjacent record without having to first display the record.

- If the record has a simple BO lifecycle of Active and Inactive, the list zone may include a button to Activate or Deactivate the adjacent record.

Separate Query and Maintenance Portals

For high volume objects where more sophisticated search criteria is needed to find a particular record, separate portals are provided to search for the record and to maintain it.

The query portal contains a zone to search of the object that you wish to maintain. Additional information about the query portal's search zone is provided below. Clicking an appropriate record in the search results navigates to the object's stand-alone maintenance portal.

The query portal will typically provide the ability to add a new record. This may be a button in the Page Action area or a hyperlink defined directly on the list zone’s header area.

Next in This Section

- Query Portal Search Zone

- Maintenance Portal

Query Portal Search Zone

The query portal contains one zone used to search for the object.

The zone may be a standard query zone or may be a multi-query zone providing one or more ways to search for your record.

Once the search results are displayed, click on the hypertext for the desired record's information string to navigate to the stand-alone maintenance portal.

Maintenance Portal

A maintenance portal refers to a page that is used to view and maintain a specific record. These types of records are governed by a business object, which defines the user interface layout for both the display of the record and the add or update of the record.

An all-in-one portal is a type of maintenance portal, once a record has been broadcast from the list zone. For the separate query and maintenance portal dialogue, the maintenance portal includes only zones relevant for the specific record selected.

Maintenance portals may have multiple tabs to display information relevant for the object. Often, if the object has a Log, the log is on a separate tab. (Although there may be some maintenance portals that include the log zone on the Main tab.)

The stand-alone maintenance portal is typically configured with the ability to navigate back to the query portal using either a Search button in the Page Actions area or using a Go To Search hyperlink in the main zone’s header area. The stand-alone maintenance portal may also include the ability to add a new record using an Add button in the Page Actions area. (If not, a new record can be added by navigating through the menu or by navigating to the query portal where an Add hyperlink may be found.

The following zones are common to portals used to maintain a record.

Note that additional zones may exist for specific all-in-one portals or stand-alone maintenance portals based on the particular functionality. Refer to the documentation for each portal to understand the specific zones that are provided.

Next in This Section

- Object Display Zone

- Log Zone

Object Display Zone

This is a zone that displays the object being maintained.

An object being displayed may or may not allow for actions or updates to be made. Typically there is a Record Actions section in the display area that presents the valid actions. Depending on the functionality, the actions may prompt the users to input values required for that action.

Log Zone

If the maintenance object for the record includes a status, it typically has a log that records important events in its lifecycle.

This log is shown in an info zone on the portal, either on the Main tab or on a separate Log tab. A link appears in the zone's title bar to allow the user to add a new manual log entry.

Device Management

Next in This Section

- Devices

- Device Configurations

- Measuring Components

Devices

Next in This Section

- About Meters

- About Items

- About Communication Components

- Maintaining Devices

About Meters

Meters are a type of device, which can be physical or virtual objects, that can produce data to be handled by the system.

A meter can have one or more device configurations over time. A meter's measuring components (if applicable) are associated with the device via device configurations.

A meter's device category (defined as an option on the device's business object) defines the broad category to which a particular device belongs. This option is used by smart meter commands and other processes when determining how the system should behave when executing processes based on the category of device. For example, when viewing items via the Device portal, certain item-specific zones appear that are not displayed when viewing meters or communication components. The base package supports the following device categories for meters:

- Smart Meter: these meters are associated to a head end system and support smart meter commands. The measuring components associated to these devices are expected to be read very frequently. These meters support periodic estimation

Refer to Periodic Estimation for additional functional information about how the periodic estimation can fill in missing reads for both interval and scalar measuring components.

- AMR Meter: these meters may also be associated to a head end system but they do not support smart meter commands. The measuring components are read frequently.

- Manual Meter: these meters are seldom read and do not support smart meter commands.

Attributes used to define devices include the following:

- Basic information about the Device including type of device (Smart Meter, Manual Meter, etc), Manufacturer, and Model

- One or more device identifiers such as serial number, badge number, meter number, etc.

- For smart meters the device can also specify a head end system and an incoming data shift. Note: these fields are only necessary when there is no fallback defined on the device type.

Refer to Initial Measurement Data for additional functional information about how the device's head end system and incoming data shift can impact processing.

About Items

While the most common type of devices are meters, there are many other devices that can be involved with a customer's service. These other devices are referred to simply as "items", and are used to represent lamps, poles, current transformers, backflow devices, pulse initiators, etc.

Items can be either "badged" or "unbadged". "Badged" items are those that have unique identifiers, and are represented by device records. Device records are not created for "unbadged" items. "Badged" items are installed at service points in much the same way as meters are installed (though they use an item-specific install event). For "unbagged" items, "multi-item" service points are used to define the number of each type of item that is installed at the service point.

These "badged" items are not directly measured and therefore do not have a measuring component. Instead there is configuration on the device type that will identify an effective dated average daily usage. Using the average daily usage the item's consumption will be calculated. The total consumption for a given period will always be equal to the average daily usage multiplied by the duration of the period. However, when the consumption for a period is turned into an interval curve there are two ways this can be done:

- Use Straight Line: the consumption will be evenly divided amongst the intervals (thus producing a straight line when graphed)

- Use Profile: a profile measuring component will be used to align the consumption to a curve. This is useful because it can more accurately identify the hours where consumption has occurred.

Refer to About Service Points for additional functional information about "unbaged" items.

About Communication Components

Communication components are devices attached to meters. A communication component may handle electronic transmission of measurement data, events, and commands in situations in which the underlying meter is not capable or not enabled to handle this data. Devices of this sort are sometimes referred to as ERT (Electronic Receiver/Transmitter) meters, or communication modules (for example, the term "gas module" may refer to a communication module attached to a gas meter).

Maintaining Devices

This portal is used to display and maintain a Device.

Refer to About Meters, About Items, and About Communication Components for additional functional information.

You can access the portal from the Main > Device > Device. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

This portal includes the following zones:

- Device: defines the basic attributes of the device

- Device Configuration Overview: lists the device configurations for the device

- Device Activities: lists activities related to the device in date descending order

- Device Events: lists the most recent device events associated to the device in descending order

- Device Exceptions: lists the first 50 VEE exceptions for all measuring components for the device, sorted by the exception creation date in descending order

Device Configurations

Next in This Section

- About Device Configurations

- Maintaining Device Configurations

About Device Configurations

Device configurations represent specific configurations of a device as of a certain time.

Over time, a device can have many configurations. Device configurations are effective-dated allowing a device to retain its identifiers (such as serial number, badge number, etc.) even while the quantities it measures change over time.

Each device configuration can have one or more measuring components associated with it.

Attributes used to define device configurations include the following:

- The device configuration type

- The parent device

- The effective date and time of the device configuration

- The time zone in which the device operates

Refer to Multi Time Zone Support for additional information on the importance of the Device Configuration time zone.

Maintaining Device Configurations

You use the Device Configuration portal to maintain device configurations.

Refer to About Device Configuration for additional functional information.

You can access the portal from the Main > Device > Device Configuration. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

This portal includes the following zones:

- Device Configuration: Defines the basic attributes of the device configuration

- Measuring Components: Lists the measuring components for the device configuration

- Scalar Readings: Displays a list of scalar readings for scalar measuring components associated with the current device configuration. To create a new reading for scalar measuring components associated with the device configuration, click New Reading. To edit an existing reading, click the edit icon for the reading you wish to edit.

NOTE: The Scalar Readings zone is available only with Oracle Utilities Meter Data Management.

Measuring Components

Next in This Section

- About Measuring Components

- Physical Measuring Components

- Scratchpad Measuring Components

- Maintaining Measuring Components

About Measuring Components

Measuring components are single points for which data will be received and stored in the system.

A measuring component can be associated to a device, which can have one or more measuring components, or it can be "virtual" or "stand-alone," meaning that it is not associated to a device.

The Service and Measurement Data Foundation supports the following types of

measuring components:

- Physical : Physical measuring components are those that physically exist, and that are linked to a device that can be configured differently over time. Interval channels and scalar registers are examples of physical measuring components.

Note: The terms register and channel are synonyms for measuring component.

- Standalone: A standalone measuring component is used to record measurements for something that does not have a physical presence or is not associated to a particular device or service point. For example, you might create a standalone measuring component to record the average daily temperature supplied by a weather station.

- Scratchpad: Users create scratchpad measuring components based on physical measuring components to experiment with measurement manipulation functions.

- Aggregator: An aggregator measuring component holds summarized usage from other measuring components. For example, aggregator measuring components could be configured to hold total consumption for each postal code within a service territory. Head-end system processing statistics used by Oracle Utilities Smart Grid Gateway are stored as aggregated measurements for aggregator measuring components.

Refer to About Aggregations for additional functional information about aggregation measuring components.

Attributes used to define measuring components can include the following:

- The measuring component type

- The device configuration to which the measuring component is associated

- Details concerning how the measuring component is read, such as the number of digits, the type of read out (dials or digital), the meter multiplier, etc.

- The VEE groups used for validation and estimation of measurement data.

Refer to About VEE for details about the types of VEE groups supported.

Scalar vs. Interval

Beyond the four types described above, measuring components generally fall into one of two primary classes of: scalar measuring components, and interval measuring components.

- Scalar measuring components are measured at unpredictable intervals. For example, "once a month" is not a predictable interval as the amount of time between reads in unpredictable and inconsistent.

- Interval measuring components are measured at predictable intervals, such as every 15 minutes, every 30 minutes, every hour, etc.

- The terms "interval size" and "seconds-per-interval" (SPI) are used to define the size of an interval measuring component's intervals.

- Note: A device may have any combination of interval and/or scalar measuring components

Measuring Component Measurements

Measuring components are configured to measure specific types of quantities. These include:

- Unit of Measure: The unit of measure for the quantity being recorded. Examples include kilo-watt hours (kWh), kilo-watts (kW), therms, cubic feet (CCF), temperature (Fahrenheit or Celsius), etc.

- Time of Use: Modifiers for a given unit of measure that indicate a period of time during which a quantity has been used, such as On-Peak (meaning during a time when the greatest quantity of some consumable is being used), Off-Peak (meaning during a time when the least amount of some consumable is being used), etc.

- Service Quantity Identifiers: Used to further distinguish between measured quantities that have identical UOM/TOU combinations, including situations in which the distinguishing identifier of a UOM is not accurately described as a TOU. Generally, SQI is only used when multiple measuring components measure the same thing, but in different ways. A meter that measures both generation KWH and consumption KWH could use SQIs to differentiate between the two.

The combination of UOM, TOU and SQI define what a measuring component measures. TOU and SQI are optional, but UOM must be defined for all measuring components. For example, consider a meter (as illustrated in the image below) with two measuring components, both measuring the same unit of measure (kWh), but each measuring component measures consumption in different time of use (TOU) periods (peak and off-peak).

Subtractive vs. Consumptive Measurements

Another attribute that defines how measuring components measure quantities is the distinction between subtractive and consumptive measuring components.

A subtractive measuring component's usage is equal to the current reading (also known as the Stop or End Measurement or Reading) minus the previous reading (also known as the Start Measurement or Reading). To put this more simply:

Usage = End Reading - Start Reading

Most residential scalar meters are subtractive and in some cases interval meters can be subtractive as well . The table below lists a series of measurements for a subtractive measuring component.

Date

kWh (Reading)

Usage

01/01/2010

0

01/31/2010

1000

1000 kWh

03/02/2010

1780

780 kWh

04/01/2010

2700

920 kWh

A consumptive measuring component's usage is equal to its current measurement. Most residential interval meters are subtractive. For scalar, consumptive measuring components are often used to measure demand, such as KW. The table below lists a series of measurements for a consumptive scalar measuring component.

Date

KW (Reading)

Usage

01/01/2010

0

0 KW

01/31/2010

10

10 KW

03/02/2010

10

10 KW

04/01/2010

13

13 KW

Physical Measuring Components

Physical measuring components are associated to the meters installed at service points. Through a device configuration there can be one-to-many measuring components in place at a given point in time. Much like other measuring components these are either scalar or interval and either consumptive or subtractive.

Note: Refer to About Measuring Components for additional information about scalar versus interval and consumptive versus subtractive measuring components.

The base product supports a core set of physical measuring components, as described in the following sections.

Interval Channel

These measuring components represent consumptive data that is recorded on a regular and consistent frequency as defined by the interval size. By definition interval data must fall on a specific interval boundary. For example, a meter that receives data once per hour cannot have a measurement at 1:30. Rather, the data must fall on either 1:00 or 2:00 not in between.

Data for interval channels is expected to be contiguous. However, in situations where it is not, there is no impact to the calculation of those intervals subsequent to the missing intervals. This is because the calculation of each interval is independent to all other intervals.

If there is a gap in the intervals it can be estimated through the periodic estimation process.

Interval Channel - Subtractive

These measuring components have behavior characteristics of both interval channels and registers. Like the interval channel they receive data on a regular and consistent frequency that is expected to be contiguous. Like a register they use a subtractive consumption calculation and provide rollover validation.

Unlike the interval channel when there are missing intervals there is an impact on the calculation of those intervals subsequent to the missing intervals. This is because the calculation of a given interval is always computed by subtracting its reading from the last known prior reading. The following table describes an example of that scenario:

Date/Time

Reading Condition

Reading

Measurement Condition

Usage

01/01/2010 12:00AM

Regular

0

Regular

0 kWh

01/01/2010 01:00AM

Regular

10

Regular

10 kWh

01/01/2010 02:00AM

Regular

20

Regular

10 kWh

01/01/2010 03:00AM

Regular

30

Regular

10 kWh

Missing measurements

1/01/2010 12:00PM

Regular

120

Combined Quantity

90 kWh

Notice that the consumption for the 01/01/2010 12:00PM interval has become overloaded and covers the entire period for which no intervals have had been received. Also take note that the measurement condition is assigned a unique condition of Combined Quantity to signify that the consumption covers more than one interval.

A similar situation can arise when there has been an underestimation of consumption for a particular meter:

Date/Time

Reading Condition

Reading

Measurement Condition

Usage

01/01/2010 12:00AM

Regular

0

Regular

0 kWh

01/01/2010 01:00AM

System Estimate

10

System Estimate

10 kWh

01/01/2010 02:00AM

System Estimate

13

System Estimate

3 kWh

01/01/2010 03:00AM

System Estimate

16

System Estimate

3 kWh

1/01/2010 04:00AM

Regular

40

Estimated

24 kWh

To help avoid these situations where an interval becomes overloaded with usage due to missing or estimated intervals the subtractive interval channel has the ability to initiate the calculation of missing intervals or re-calculation of estimated intervals when processing newly received intervals.

Note: Refer to Understanding Measuring Component Types link for additional information about how to configure subtractive interval measuring component types to perform prior and subsequent estimation.

Register

A register, often referred to as scalar, measuring component is used to represent infrequently received data from a meter. Typically these types of measuring components will only be read once per month aligning to the billing period for the customer.

The physical meter these measuring components represent often have dial readings where there are a finite number of digits that can register the consumption. When the maximum amount has been measured the meter will rollover and start counting once more from zero. To appropriately handle these scenarios this type of measuring component can be defined with a rollover tolerance that allows the system to accurately identify an invalid reading from a standard rollover. For example when a meter has 6 dials (a maximum of 999,999):

- Going from a reading of 999,990 to 20 would likely be valid and represent consumption of 30.

- Whereas going from a reading of 999,990 to 800,000 would be an invalid reading since it would represent consumption of 810,000.

Given the infrequent nature of these measuring components they are not eligible for the periodic estimation process.

Register - Auto-Read

An automatically read register processes nearly identical to a register. The key difference between these two types of measuring components is that the automatically read variant is expected to be read on a frequency of at least once per day.

These measuring components are eligible for periodic estimation since the information about their reading schedule allows for missing readings to be detected and estimated.

Given the frequency these meters are read and the nature of subtractive consumption calculation they can be configured to re-estimate any past or future estimates when actual data has been received. The actual readings allow these estimates to be refined since the total consumption for the estimated period can be calculated (current reading - last reading prior to estimation).

Note: Refer to Periodic Estimation for additional functional information about how the periodic estimation can fill in missing reads for both interval and scalar measuring components.

Scratchpad Measuring Components

Scratchpad measuring components provide users with a means to manipulate "scratchpad" measurement data without affecting existing "live" measurement data. Examples of measurement manipulation might include experimenting with the impact of executing the "spike smooth" function on an initial measurement, or adding or removing intervals to or from the measurement. Scratchpad measuring components provide users with a means to manipulate "scratchpad" measurement data without affecting existing "live" measurement data.

Scratchpad measuring components are defined by the same attributes as "regular" measuring components, with the following additional attributes:

- User: The name of the user who created the scratchpad. All scratchpad measuring components "belong" to a user.

- Source Measuring Component: The measuring component upon which the scratchpad is based.

Like "regular" measuring components, scratchpad measuring components can be related to a device through a device configuration, but scratchpad measuring components are not considered "active" for purposes of install events, and are not used in usage calculations for usage subscriptions.

Like "regular" measuring components, scratchpad measuring components and viewed and maintained using the Measuring Component portal, and measurement data for scratchpad measuring components can be viewed using the Initial Measurement portal or the 360 Degree View.

Maintaining Measuring Components

You use the Measuring Component portal to maintain measuring components.

Refer to About Measuring Components for additional functional information.

You can access the portal from the Main > Device > Measuring Components. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

This portal includes the following zones:

- Measuring Component: defines the basic attributes of the measuring component

- Initial Measurement Data History: lists the last 50 initial measurements for the measuring component in reverse chronological order.

- Measuring Component Profile Use: lists all profile factors on which the measuring component is referenced as a factor value.

- Measurements: lists final measurements for the measuring component, including any derived values for each measurement. Note: depending on the type of measuring component this zone may be the Interval, Scalar, or Subtractive Interval variant.

- Device Configuration Overview: Displays an overview of the measuring component's parent device's configurations over time, including the measuring components associated with each configuration, and service points (along with the relevant install events) at which the device's configurations have been installed over time, if any exist.

Device Installations

Next in This Section

- Service Points

- Install Events

- Route Management

- Facilities

- Network Locations

Service Points

Next in This Section

- About Service Points

- Maintaining Service Points

About Service Points

Service Points are locations at which a company supplies service and are used in Oracle Utilities Meter Data Management to store information describing the type of service supplied and how it is measured. A Service Point allows for a device to be installed for recording the energy or commodity delivered to the customer.

Attributes used to define Service Points can include the following:

- Basic information about the Service Point, including address, time zone, market, parent Service Point (if applicable), status, and main contact

- Specifics related to whether or not the current Service Point supplies service to life support equipment, or if the load supplied to the Service Point is considered sensitive.

- Information related to field work performed at the current Service Point, including any applicable warnings or instructions

- The measurement cycle, route, and route sequence for the Service Point

Unbadged Items

Items that do not have any unique identification are referred to as "unbadged." These types of items, unlike "badged" items, do not have a device to represent them. Instead they are associated to service points with the service point category of "multi-item." For these types of service points a list of "unbadged" items can be configured to represent the items that require usage to be calculated. This is an effective dated list that allows for changes over time to the type and count of items over time. The consumption of the list of items is either calculated using the service quantity associated to the item types listed or by using the installation override quantity that can be specified on the service point.

Refer to Multi Time Zone Support for additional information on the importance of the Service Point time zone.

Maintaining Service Points

This portal is used to display and maintain a Service Point.

Refer to About Service Points for additional functional information.

You can access the portal from the Main > Device Installation > Service Point. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Service Point: defines the basic attributes of the Service Point

- Device History: lists all Device Configurations that have been installed for the Service Point, in reverse chronological order

- Usage Subscriptions: lists all Usage Subscriptions linked to the Service Point, sorted in descending order by Start Date/Time of Usage Subscription/Service Point

- Children Service Points: lists the first 50 children Service Points of the parent Service Point

- SP/Measurement Cycle Schedule Route List: lists all the Measurement Cycle Schedule Routes linked to the Service Point.

- SP Service Issue Monitors: displays a list of service issue monitors and related service investigative orders related to the current Service Point, in reverse chronological order.

- SP Business Flags: displays a list of business flags related to the service point in reverse chronological order.

- SP Suppression History: displays a list of suppression activities related to the service point in reverse chronological order.

Install Events

Next in This Section

- About Install Events

- Maintaining Install Events

About Install Events

Whenever a device is installed at a Service Point, an installation event is created. Installation events capture the history of the devices that have been installed at a Service Point. This allows consumption for a Service Point to be calculated over time. In technical terms, installation events (or Install Events) link a specific Device Configuration to a Service Point.

There are specific Install Event business objects for different types of devices, including smart meters, items, manual meters, and communication components.

When creating Install Events for items, only "badged" items (those that are uniquely identified in some way) use item Install Events. "Unbadged" items do not use Install Events. Instead, the number of each type of item is specified in the "Multi-Item Detail" section of the Service Point.

While a device is installed at a Service Point, it may be turned off (and back on again). The installation event that records the original installation date and time also records the dates and times when the device has been turned on and off. When a device is removed, the original installation event is updated with the removal date and time.

Maintaining Install Events

This portal is used to display and maintain an Install Event.

Refer to About Install Events for additional functional information.

You can access the portal from the Main > Device Installation > Install Event. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Install Event: defines the basic attributes of the Install Event, the on/off history for the Install Event, and removal information.

When creating a new record, the following options are available:

Name

Details

Business Object

Communication Component Install Event

This Install Event is intended for use with a Communication Component that is installed on top of a traditional Meter.

D1-CommComponentInstallEvent

Item Installation Event

This Install Event records the installation of an Item (i.e. streetlight).

D1-ItemInstallEvent

Manual Meter Installation Event

This Install Event is used for manually read meters.

D1-ManualMeterInstallEvent

Smart Meter Installation Event

This Install Event is unique to smart meters and has a lifecycle that's maintained by remote meter commands.

D1-SmartMeterInstallEvent

Route Management

Next in This Section

- About Route Management

- Working with Route Management

About Route Management

Route management involves managing the order of the Service Points within measurement cycles and routes.

When creating Service Points, each Service Point can reference a measurement cycle, route, and its sequence within the route. Over time, as Service Points are added and removed to and from measurement cycles and routes, it may become necessary to change the sequence of Service Points within the measurement cycles and routes used in your implementation.

- A measurement cycle defines WHEN the Service Point is visited

- A route within a cycle defines a group of Service Points in a cycle that are visited by a meter reader

- A sequence within a route defines the physical position of the Service Point within a route

- A schedule specifies the dates on which Service Points are visited.

Manually read Service Point reference a measurement cycle, route and sequence within the route. A batch process creates SP/Measurement Cycle Schedule Routes for each Service Point, which link the dates on a measurement cycle schedule to a measurement cycle route defined for the Service Point. These define the specific date on which a meter reader will visit Service Points associated with a specific measurement cycle route, and the sequence in which the Service Points on that route are visited.

Measurement Cycles

Measurement cycles define the schedule for manual meter reading of devices at Service Points in that cycle. Measurement cycles can have one or more associated routes used to collect measurements.

Measurement cycles can also be configured to define when to create usage transactions for Usage Subscriptions associated to Service Points in the cycle.

Measurement Cycle Schedules

Measurement cycle schedules define the dates on which devices are scheduled to be read for a given measurement cycle and the routes used to collect measurements for the measurement cycle.

Working with Route Management

This Route Management portal is used to change the sequence of Service Points within a measurement cycle and route and to transfer Service Points from one measurement cycle and route to another.

Refer to About Route Management for additional functional information.

You can access the portal from the Main > Device Installation > Route Management. You are brought to a query portal with options for searching. Once you enter your search criteria, a list of related Service Points is presented.

The following actions are available once a Measurement Cycle and Route are selected:

- Renumber Sequence: renumbers the sequence of selected Service Points for the route. Use the Renumber Sequence page to renumber the sequence of Service Points in a measurement cycle route.

- Transfer Measurement Cycle Route: Use this button to transfer the selected Service Points to another route. Use the Transfer Measurement Cycle Route page to transfer the selected Service Points to another measurement cycle route. You can also renumber the sequence of Service Points in their new route as part of the transfer.

Facilities

Next in This Section

- About Facilities

- Maintaining Facilities

About Facilities

Facilities represent the network node level closest to the Service Point. In terms of electric networks, facilities typically represent transformers.

While "Facility" is the generic name for this object, many of the Business Objects created within Oracle Utilities Meter Data Management have a more specific name. One good example is the Transformer (D1-Transformer) Business Object.

Maintaining Facilities

This portal is used to display and maintain a Facility.

Refer to About Facilities for additional functional information.

You can access the portal from the Main > Device Installation > Facility. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Facility: defines the basic attributes of the facility

- Network Locations Related to Facility: displays a list of network locations associated with the current facility in reverse chronological order.

- Service Points Related to Facility: displays a list of Service Points related to the current facility, in reverse chronological order.

Network Locations

Next in This Section

- About Network Locations

- Maintaining Network Locations

About Network Locations

Network locations define the location of a facility within a larger network.

Network locations hold the network nodes that provide service to a facility. In the case of electric networks, network locations define the feeder and substation associated with a transformer (facility). Because these network nodes can change over time, a facility can have many network locations (this is an effective-dated relationship). For example, for electric Service Points, whenever the substation or feeder that provides power to a given transformer is changed, a new record that references the latest substation and feeder should be created.

Maintaining Network Locations

This portal is used to display and maintain a Network Location.

Refer to About Network Locations for additional functional information.

You can access the portal from the Main > Device Installation > Network Location. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Network Location: defines the basic attributes of the network location

- Service Points Related to Network Location: displays a list of Service Points related to the current network location, in reverse chronological order.

Measurements

Next in This Section

- Initial Measurement Data

- Final Measurements

- Reader Remarks

- Periodic Estimation

- Measurement Reprocessing

- Consumption Sync

Initial Measurement Data

Next in This Section

- About Initial Measurement Data

- Processing Initial Measurement Data

About Initial Measurement Data

Initial measurement data (IMD) is the term for measurement data in its initial (or raw) form.

Measurements read from a measuring component are referred to as "initial measurement data" (or initial measurements) and are used to record how much of the quantity (defined by UOM, TOU, and SQI) measured by the measuring component was consumed.

Initial measurement data for scalar measuring components contain a single "reading" or value, while initial measurement data for interval measuring components can contain multiple readings, one for each interval that falls between the start time and stop time of the measurement.

At a simple level, initial measurement data goes through the following process:

1. Initial measurements are loaded into the system.

2. Initial measurement data is validated, edited, and estimated (VEE). Please refer to About VEE for more details on the VEE process.

3. Initial measurements are converted into final measurements.

4. If using Oracle Utilities Meter Data Management, final measurements are used to calculate usage (bill determinants, etc.). Please refer to About Usage Calculation for more details on the usage calculation process.

Only initial measurements can be edited directly by end users.

Initial measurement data contains both the original and final versions of the quantities recorded by the measuring component.

- Pre VEE quantities are consumption values derived from the measurements recorded by the head-end system or meter reader with the appropriate installation and measuring component multipliers applied.

- Post VEE quantities are the "final" values, after VEE processing.

Pre VEE and Post VEE quantities in an initial measurement often differ based on a number of conditions, including:

- VEE rules have changed the quantities because they are missing or obviously wrong. In this, the Pre VEE values are adjusted based on the specifics of the VEE rules applied to the initial measurement to create the Post VEE values

- Manual changes by a user.

In addition to recorded consumption values, measurements also have condition codes, used to indicate the source and quality of a measurement. For example:

- Regularly recorded measurements might have a condition code of "Regular"

- Missing measurements might have a condition code of "Missing"

- Estimated measurements might have a condition code of "External Estimated" or "System Estimated" based on where the estimation was performed.

Both Pre VEE and Post VEE values have their own condition code, which can also change during VEE processing. For example, a measurement that was missing in the Pre VEE document will likely become "System Estimated" in the Post VEE document once VEE has been executed.

Processing Initial Measurement Data

Initial measurement data (IMD) received from external systems is processed through two major stages:

- IMD Seeder: This is the common interface point that receives all IMD information and performs critical validations and conversions. During this process the IMD Seeder identifies the appropriate specific IMD business object for further processing. The choice is made based on the category of IMD being processed (typically initial load) and the type of measuring component the IMD is for. For example, an IMD for an interval measuring component would result in the Initial Load IMD (Interval) business object being selected. If for some reason the IMD Seeder encounters an error an instance of the IMD Seeder will be created to manage the resolution of that error.

- Specific IMD: Each specific IMD has the appropriate calculation and validation logic for the type of data that has been received. An IMD containing scalar data will be processed differently than interval data or subtractive interval data. However, all types of data will have a similar set of steps taken:

- Any external system specific statuses for the measurement data are interpreted into the appropriate internal statuses

- An initial consumption calculation is performed

- VEE rules are executed

- Final measurements are created

IMD Seeder Processing

The IMD Seeder receives IMD data in a common structure, however, the content of the data (identifiers, date/times, etc) can vary depending on the system and the particular device that generated it. To accurately translate the external content to values understood by the system the IMD Seeder leverages the configuration of the service provider (aka head end or external system) and the device.

The service provider specifies the following inputs into IMD Seeder processing:

- Identifier Types: Each IMD must identify the device and measuring component the data has been generated from. The system supports a multitude of identifiers for both the device and measuring component. The service provider configuration specifies which identifier types are used for both the device and the measuring component which enables the IMD seeder to search for the correct destination for the measurement data. For example, a service provider might indicate that devices are identified by a serial number and measuring components are identified by a channel identifier.

- Date/Time Format: The service provider configuration will identify whether the date/times that were sent included specific time zone designations. This allows the system to accurately handle any time zone conversions that may be necessary.

- Processing Methods: A service provider has many processing methods that are used in the evaluation of the IMD.

- Initial Measurement Creation - Maps a given measuring component type to the initial measurement BO that should be created

- UOM Translation - Identifies the extendable lookup that should be used to map the service provider specific UOM to the internal UOM

- TOU Translation - Identifies the extendable lookup that should be used to map the service provider specific TOU to the internal TOU

- SQI Translation - Identifies the extendable lookup that should be used to map the service provider specific SQI to the internal SQI

- Time Zone Translation - Identifies the extendable lookup to be used in mapping the service provider specific time zone to the interval time zone.

The device specifies the following inputs into IMD Seeder processing:

- Incoming Data Shift: This value is either specified directly on the device or can be defaulted via fallback on the device type. It identifies whether the incoming date/time information has is "Shifted" meaning it has been adjusted for Daylight Savings Time (DST) when in effect, or it is "Not Shifted" which means it will never be adjusted for DST. This plays an important role in the date/time processing since all incoming IMD date/times will be stored without an adjustment for DST.

With these inputs the IMD Seeder is able to translate the external identifiers into the appropriate identifiers to tie the IMD data to a specific measuring component in the system.

Once a measuring component is identified it is then used to select the appropriate IMD business object using the "Initial Measurement Creation" processing method of the service provider.

IMD Seeder Critical Validations

For Initial Measurement Data (IMD) to continue on to specific IMD processing it must pass several critical validations:

- The measuring component must be identified.

- The IMD must contain the appropriate date/times for the type of IMD being processed: scalar must have an end date/time and interval must have both a start and end date/time.

- The interval list must match the number of intervals expected based on the IMD start and end date/times. Note: if there are too few intervals the missing intervals can be automatically added to the IMD without generating an error. How this is done depends on whether there are date/times for each individual interval. If there are date/times for each interval the missing intervals are placed where the gaps exist. Otherwise when there are no date/times for the individual intervals the missing intervals are added to the end of the interval list.

If any of the critical validations have failed the IMD processing will be halted and an instance of the IMD Seeder will be created

Note: There is special logic that exists for handling the situation where either the IMD start date/time or the IMD end date/time falls on the duplicate hour that occurs when a time zone transitions out of daylight savings time. Typically there are two 1AMs on that day, one is considered to be during DST and the other is not. To ensure that the appropriate hour is selected the IMD Seeder uses the count of intervals and final measurements that exist prior to the IMD to identify the appropriate hour.

Note: Additional detail on the logic to derive the service provider, device, and measuring component identification can be found on the D1-DER-SPRMC Algorithm Type.

IMD Seeder Time Zone Translation and Conversion

To provide the most accurate tracking of measurement data all initial measurement data is stored in a single time zone without an adjustment for Daylight Savings Time (DST). As utilities can have multiple head end systems that each send date/time information in different ways and some utilities operate in multiple time zones the IMD Seeder contains functionality to convert incoming date/times from a source time zone into the time zone of Oracle Utilities Meter Data Management (as indicated by the base time zone)

There are three components to identifying the source time zone of the incoming IMD:

- Service Provider IMD Import Date/Time Format: When the IMD date/times are sent in format that identifies the time zone for each date/time the date/times will be delivered to the IMD Seeder already converted.

- Incoming Data Shift: This indicates whether the date/times will be adjusted for DST while it is in effect. A value of "Always in Local Time" indicates that the date/times are adjusted for DST. A value of "Always in Standard Time" indicates that the date/times are not adjusted for DST

- Time Zone: The time zone of the incoming data is identified using the follow order of precedence:

1. The time zone as indicated by the IMD data

2. The service point time zone

3. The device configuration time zone

4. The measuring component time zone

5. The base time zone

Once the time zone and the data shift of the incoming date/times is identified all date/times will be converted from that time zone and shift into the base time zone in standard time.

Note: Additional detail on the logic for date/time adjustments and validation of undercount and overcount can be found on the D1-DODTTMADJ Algorithm Type.

Specific Initial Measurement Data Processing

There are several categories of initial measurement data:

Initial Load

When initial measurement data is received from external systems (e.g. Head End systems) it is processed using the initial load IMD type. These IMDs are configured to execute the VEE rules that as associated to the Initial Load VEE role on the measuring component (or measuring component type in the case of a fallback). For adapter specific variations of the Initial Load IMD there is logic to map external measurement statuses to measurement conditions.

Estimation

For various reasons a meter will not report measurement data for a certain period of time. When the system detects that a measuring component is missing final measurements, it can create an initial measurement to execute estimation rules. This type of initial measurement is referred to as an estimated initial measurement.

At a high-level, the estimation process is as follows:

- Missing final measurements are detected by the Periodic Estimation process

- Estimated initial measurements are created for the "missing" time period by the Period Estimation process

- Values and consumption for the estimated initial measurements are calculated by "estimation" VEE rules.

It's important to note that the processes that detect missing measurements do NOT themselves estimate consumption. Rather, these detection processes simply create an initial measurement and let the estimation VEE rules estimate the consumption for the initial measurement.

Estimation IMDs execute the VEE rules associated to the Estimation VEE role on the measuring component (or measuring component type in the case of a fallback).

Note: Refer to Periodic Estimation for additional functional information about how the periodic estimation can fill in missing reads for both interval and scalar measuring components.

Manual Override

Manual override IMDs are used when the creation of an IMD is user initiated as can be done from the various functions available on some of the 360 Degree zones (e.g., Final Values Overlay, Interval - Initial Measurement Overlay, etc.). Unlike other types of IMD manual override allow the user to edit the initial measurement data prior to performing VEE. These IMDs are used for more advanced tasks where a user must specify, either directly or through a measurement function, the values for the initial measurements.

These IMDs are systematically created during the reconciliation process that occurs when IMDs are finalized for measuring components with subtractive consumption calculations. They are used to recalculate the consumption on a measurement subsequent to an IMD when the start reading for that subsequent measurement has been changed.

Manual override IMDs execute the VEE rules associated to the Manual Override VEE role on the measuring component (or measuring component type in the case of a fallback).

System

A system is generated by internal system processes that need to recalculate measurement multipliers. They do not perform VEE but they can be configured to do so.

Note: Refer to About Measurement Reprocessing for additional functional information about how the system IMDs are created.

Data Conversion

This type of IMD has only the processing necessary to propagate converted measurement data into the system. The data provided to these IMDs is expected to be the quality of final measurements. Therefore no VEE rules will be executed.

Scalar Initial Measurement Data Processing

Initial measurement data for subtractive scalar measuring components contain start and stop readings in addition to Pre and Post VEE usage. For example, a set of initial measurements for a subtractive scalar measuring component might look like the following:

Date/Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Usage

Post VEE Condition

01/01/2010 12:00AM

0

1500

1500

Regular

1500

Regular

02/02/2010 4:11PM

1500

2100

0

Missing

600

System Estimate

03/03/2010 5:22 PM

2100

2900

800

Regular

800

Regular

04/01/2010 01:00PM

2900

3500

0

Missing

600

System Estimate

Subtractive measuring components can "rollover" when the reading exceeds the maximum value based on the number of dials. For example, a register with a 4 dials can record values up to 9999 before rolling over to 0000. When this occurs, consumption is calculated based on the following attributes and calculated values.

- Rollover Threshold is the percentage of the measuring component's dial capacity at which measurements for measuring components of this type are considered to have rolled over. Dial capacity is the largest value that can be recorded for the measuring component, based on the measuring component's number of dials. For example, a measuring component with 5 dials has a dial capacity of 99999.

- Max Dial Capacity is the maximum value for the number of dials, rounded up to the next whole multiple of 10 (or 10 raised to the power of the number of dials). For example, for a register with 4 dials, the max dial value is 10000.

- Max Acceptable Difference is the maximum acceptable consumption that can be recorded for the register. This is equal to the Max Dial Capacity multiplied by the rollover threshold. For example, the Max Acceptable Difference for a register with 4 dials and a rollover threshold of 90% would be 9000. If the consumption is greater than this value, the initial measurement is transitioned to the Error state.

- Difference: The difference between the Stop Reading and Start Reading, obtained by subtracting the Start Reading from the Stop Reading. If the Difference is less than zero (<0), then add the Max Dial Capacity to calculate Rollover.

- Rollover: The adjusted consumption for a reading on a register that has rolled over. Only applicable if the Difference (Stop Reading - Start Reading) is less than zero (<0).

- Consumption: The calculated consumption for the reading, equal to either the Difference or Rollover. If the Difference is greater than or equal to zero, consumption is equal to the Difference. If the Difference is less than zero (<0), and the Rollover is less than or equal to the Max Acceptable Difference, the consumption is equal to the Rollover.

Example: Consider an initial measurement with the following attributes:

- Number of Dials: 4

- Rollover Threshold: 90 (%)

- Start Reading: 8900

- Stop Reading: 0500

For this reading,

- Max Dial Capacity = 10000

- Max Acceptable Difference = 9000 (10000 * 90)

- Difference = 0500 (Stop Reading) - 8900 (Start Reading) or -8400

- Rollover = 10000 (Max Dial Capacity) + -8400 (Difference) or 1600

- Consumption is equal to 1600 (Rollover).

Each scalar IMD that is processed will perform a rollover validation based on the start reading. For those scalar IMDs that have measurements subsequent to the date being processed there will be an additional rollover validation forwards to ensure that the current IMD does not invalidate a future reading.

If the rollover validation fails when validating either backwards, forwards, or both then the system will attempt to automatically correct the situation by evaluating whether the measurements prior to or subsequent to the IMD can be removed. This analysis is done based on the condition of the measurement and the condition of the IMD. For example. If there is a rollover based on the start measurement and the start measurement is a system estimate but the IMD is regular then the start reading will be bypassed and the system will search backwards until:

- It identifies a measurement with a reading that does not cause a rollover when used as the start reading for the IMD

- It encounters a measurement that causes a rollover but is also regular and therefore cannot be bypassed. At this point the IMD would be placed in an error status.

When a rollover error is identified that cannot be automatically corrected there are a few options available for fixing the situation:

- The "Override Condition" functionality can be used. This is an action button available on the IMD from within the Error status. It allows the user to provide a higher quality condition for the IMD to force the rollover process to bypass the measurement (either prior to or subsequent to the IMD) that was the source of the rollover threshold error. For example, if the start read was a regular measurement and the IMD was also a regular measurement the user could update the IMD to have a condition of "Super" which would allow the regular start reading to be bypassed.

- A Manual Override IMD could be created to adjust the measurements surrounding the IMD to ensure that the rollover error is no longer encountered.

Note: When a measurement is bypassed by the rollover automatic correction logic it will be set to Do Not Use when the IMD is finalized.

A scalar IMD can generate a manual override IMD during the finalization process when the need for reconciliation is identified. This happens whenever an IMD is received that occurs prior to an already existing scalar measurement. Since the newly processed IMD will introduce a new start reading for the existing subsequent measurement it is necessary to use the manual override IMD to recalculate the consumption. For example, imagine a scalar measuring component had the following readings:

Date/Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Usage

Post VEE Condition

01/01/2010 12:00AM

0

1500

1500

Regular

1500

Regular

02/02/2010 4:11PM

1500

2100

0

Regular

600

Regular

04/01/2010 01:00PM

2100

3500

1400

Regular

1400

Regular

When the February reading is finally received it will spawn a reconciliation Manual Override IMD to correct the consumption of the April reading given the new start reading:

Date/Time

Start Reading

Stop Reading

Pre VEE Usage

Pre VEE Condition

Post VEE Usage

Post VEE Condition

01/01/2010 12:00AM

0

1500

1500

Regular

1500

Regular

02/02/2010 4:11PM

1500

2100

600

Regular

600

Regular

03/03/2010 5:22 PM

2100

2900

800

Regular

800

Regular

04/01/2010 01:00PM

2900

3500

600

Regular

600

Regular

Note: These reconciliation IMDs are generated during the finalization of the initiating IMD and must finalize themselves. If for some reason the reconciliation IMD does not complete it will prevent the initiating IMD from finalizing as well. Typically the reason for this issue will be a VEE exception that is being raised against the reconciliation IMD. The reason this rule is enforced is to ensure that the quantity of a measurement always aligns to the reading of that same measurement. If this situation arises the data source of the IMD can be used as an input to the VEE rule eligibility to skip certain rules when the IMD is a reconciliation IMD since the reconciliation process add a data source of "Generated by Reconciliation" to each reconciliation IMD.

Interval Initial Measurement Data Processing

Given the consumption calculation for interval channels is done using the consumptive method the Interval IMD variants do not contain much special processing outside of the general pattern described in Processing Initial Measurement Data.

Subtractive Interval Initial Measurement Data Processing

Initial measurement data for subtractive interval measuring components readings and usage for each interval in addition to Pre and Post VEE usage. Furthermore, there is a condition for both the reading and the usage which allows for more accurate recalculation of intervals. The start reading for each interval is considered to be the reading from the prior interval. For the first interval the start reading will be identified from the measurement data for the measurement immediately prior to the IMD. For example, an initial measurement for a subtractive interval measuring component might look like the following when we assume a start reading of 1490:

Date/Time

Pre VEE Reading / Condition

Pre VEE Usage / Condition

Post VEE Reading / Condition

Post VEE Usage / Condition

01/01/2010 01:00AM

1500 / Regular

10 / Regular

1500 / Regular

10 / Regular

01/01/2010 2:00AM

0 / Missing

0 / Missing

1520 / System Estimate

20 / System Estimate

01/01/2010 3:00AM

1525 / Regular

5 / System Estimate

1525 / Regular

5 / System Estimate

01/01/2010 4:00AM

1540 / Regular

15 / Regular

1540 / Regular

15 / Regular

Subtractive interval IMDs can validate for rollovers based on the configuration of the measuring component. See Scalar Initial Measurement Data Processing for more details on how rollovers are calculated.

How subtractive interval IMDs identify rollover errors is identical to scalar IMDs. However, the resolution of those errors is much different. With scalar any bypassed measurements are handled at the point of finalizing the IMD and the measurements are set to Do Not Use. With subtractive interval any bypassed measurements are added to the IMDs interval list so that they are processed along with the IMD that identified them as causing a rollover.

Subtractive interval IMDs also must initiate the reconciliation of an interval that comes directly after the IMD being processed. Unlike scalar this is not handled through a separate IMD. Rather the next measurement after the IMD being processed is added to the current IMD and the reconciliation of the usage for that measurement is computed as part of the IMD. This allows for any validation errors that are encountered in the recalculation of that measurement to be resolved along with the IMD.

Note: There is one scenario that does result in a reconciliation IMD being generated. When the last interval of an IMD has the reading changed during the VEE process it will require that a reconciliation IMD be generated to adjust the usage of the next measurement after the IMD (if applicable).

The subtractive interval IMDs are responsible for ensuring that the reading for each interval is in line with the usage calculated. This maintenance is performed each time the IMD is run through the VEE rules. After which the IMD will examine each interval and identify which intervals require an update to the reading or quantity.

Initial Measurement Data Valid Date Boundaries

A method to restrict the acceptable date range for IMDs is provided as part of Meter Data Management. The settings for this are controlled on the MDM Master Configuration. This provides a way to restrict either future measurements or very old measurements from being written to Meter Data Management.

Initial Measurement Data Prioritization

By default, initial measurements are created and/or received into the system in an initial state of "Pending" and are transitioned to subsequent states via the "IMD Monitor - Physical Devices" Monitor process. This Monitor process can be skipped by setting the Execution Method flag on the initial measurement to "Real Time" (D1RT), in which case an Enter algorithm transitions the initial measurement to the next state in its lifecycle immediately. This feature can be used to prioritize processing of certain types of initial measurements.

The Execution Method flag can be set in initial measurements sent from the head-end system, or can be inserted during Oracle Utilities Smart Grid Gateway Adapter processing.

Oracle Utilities Smart Grid Gateway Adapters set this flag to "Real Time" on all measurements created as the result of smart meter commands (Remote Connect, Remote Disconnect, or On-Demand Read) or completion events (including Field Activity Completion Events used with Service Order Management).

Final Measurements

Next in This Section

- About Final Measurements

About Final Measurements

Final measurements are measurements that have been validated, and if necessary, edited & estimated, and is ready for use in downstream processing such as bill determinants calculations.

When an initial measurement is considered "final," that is, it has passed all VEE processing and no additional modifications or changes need to be made, it is transformed into a Final Measurement, or simply a Measurement (the terms measurement, final measurement, and final consumption all reference this same "final" measurement data). Only one final measurement can exist for a given date/time for a given measuring component; one final measurement exists per interval, and likewise one final measurement exists for each scalar reading. In both cases, the final measurement value stored represents the amount consumed between its date/time and the prior final measurement's date/time.

When creating final measurements from initial measurement data:

- Final measurements are created using Post VEE quantities

- Each final measurement's condition is copied from the Post VEE condition

- Initial measurements are normalized into final measurements where each final measurement is for a specific date and time.

- Because a single initial measurement may contain many "readings," a separate final measurement is created for each interval in the initial measurement. For example, if an initial measurement contains 24 hours of 15 minute readings, 96 measurements will be created, each with a specific date and time.

The measurement date/time of a measurement represents the end of the period the measurement value covers. How the start of the period is defined varies slightly based on the type of measuring component associated to the measurement:

- Scalar Measuring Components: the measurement date/time represents the point at which the reading was taken. The period the measurement covers is defined as the previous measurements date/time through the measurement date/time.

- Interval Measuring Components: the measurement date/time represents the end of the interval period. No date/time is stored to represent the beginning of the interval period, rather it is implied by the interval size of the measuring component. For example an interval measuring component with an hourly interval size and a measurement date/time of 01/01/2010 12:00AM represents the measured quantity for the period of 12/31/2009 11:00PM through 01/01/2010 12:00AM.

- For scalar measuring components there exist special circumstances where a final measurement is not eligible for use in processing (e.g. consumption calculation, usage calculation, etc.). To prevent other processes from using these measurements they are marked with a usage flag of "Do Not Use." This is typically the result of the automatic correction of a rollover threshold error when lower quality measurements inaccurate measurements are removed to enable successful calculation of subtractive consumption.

Conditions

Conditions are used to describe the quality of a final measurement and is an important input into many of our processes. During initial measurement data processing these conditions help VEE rules identify the initial measurements that require more advanced validation or estimation. During usage calculations measurement conditions help to inform the billing system whether the billing determinants produced are based on actual data read from a meter or if it has been estimated (or in many cases a combination of the two).

Conditions follow a numeric sequencing that begins at 000000 and goes up to 999999. As the condition code rises numerically so does its perceived quality. Many areas the system take this into account:

- VEE rules use conditions to identify which initial measurement values need to be estimated or adjusted

- Rollover error automatic corrections allow higher quality data to bypass lower quality data in order to achieve a consumption calculation that does not produce an error.

- Usage rules can provide information about the quality of billing determinants based on the underlying measurement data that feeds into those service quantities.

Throughout the system functionality uses condition code ranges to make decisions. In general the ranges are considered to be:

Condition Range Start

Condition Range End

Description of Range

000000

199999

No measurement

200000

299999

Missing Measurement

300000

499999

Estimated measurement

500000

999999

Regular measurement

The ranges of "No Measurement" and "Missing Measurement" at first glance sound synonymous but there is an important distinction. With conditions that fall within the "No Measurement" range the expectation is that no measurement should exist. Whereas, the "Missing Measurement" range implies that a measurement was expected but never received.

Note: in some circumstances, like rollover threshold errors, the regular range is further divided to include a "Superior" range of 9000000 - 999999 which can be used to select the appropriate reading to be used to resolve the error.

During initial measurement processing the Final Measurement Replacement VEE rule can be used to increase the perceived quality of a condition code. For example, the "No Read - Outage" condition which falls in the "No Measurement" range can be considered higher quality than "Estimated Measurements" for the purposes of measurement replacement.

Refer to About IMD Validations for more information on the Final Measurement Replacement VEE rule.

Derived Values

Final measurements can record up to 10 derived values in addition to the "as measured" value. The derivation formula for each value on a final measurement is controlled by the measuring component type.

Derived values are not reliant on consumption values, but can also come from factors, historical data, or another source. For example, a set of measurements can be adjusted or converted into other units of measure. In the below example the first derived value is the result of the application of a loss adjustment factor and the second derived value is the result of applying a pre set formula against the loss adjusted value to compute BTU.

Date/Time

As Measured UOM: CCF SQI: N/A

Loss Adjusted UOM: CCF SQI: N/A

Thermal Units UOM: BTU SQI: N/A

01/01/2010 3:00PM

10

10.1

10.11

01/01/2010 4:00PM

15

15.15

15.165

01/01/2010 5:00PM

10

10.1

10.11

Refer to Understanding Measuring Component Types in the Administration Guide for additional information about configuring derivation algorithms.

Reader Remarks

Initial measurements for manually-read scalar meters can create reader remarks. Reader remarks are a specific type of device event used to capture and/or record specific events or circumstances encountered when a meter reader is manually reading scalar meters.

Reader remark types are submitted with scalar initial measurements when received from a headend system or meter read collection system. Reader remarks are NOT uploaded along with other device events. Reader remarks are always associated with a scalar initial measurement.

Reader remarks can be passed onto to other subscribing systems such as a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

Like other device events, reader remarks can create service issue monitors.

Note: Refer to About Service Issue Monitors for more information on Service Issue Monitors.

Creating Reader Remarks Manually

Use this procedure to create a new reader remark for an existing initial measurement.

Reader remarks must always be associated with an initial measurement.

Reader remarks are most often imported into the application with an initial measurement. However, users can also create reader remarks using the following procedure.

1. Search for and select the initial measurement that the new reader remark is to be associated with.

2. Click the Add link on the Reader Remarks of Initial Measurement zone on the Initial Measurement portal.

3. Select the reader remark type for the reader remark from the Reader Remark Type drop-down list.

4. Optional. If you need to create more than one reader remark for the initial measurement, click the plus sign, and select the reader remark type for the reader remark from the Reader Remark Type drop-down list. Repeat as needed.

Note that only a single reader remark of any given type can be associated with a single initial measurement.

5. Click OK. The new reader remark is displayed in the Reader Remarks of Initial Measurement zone on the Initial Measurement portal.

Periodic Estimation

Next in This Section

- About Periodic Estimation

About Periodic Estimation

Periodic estimation is a process that scans eligible devices and their measuring components for missing measurements that have not been received within a required amount of time. Once missing measurements are identified it then generates estimation initial measurements to fill in those missing measurements. It is important to note that the periodic estimation itself does not actually perform any estimations. It relies on the estimation initial measurement to generate the estimate through the estimation VEE rules that are executed.

The periodic estimation process is as follows:

1. Determine if measuring component is eligible for estimation.

2. Scan the eligible period for missing measurements.

3. Confirm missing measurements do not fall within a period where the device was not installed or was disconnected.

4. Confirm there are no in progress initial measurements that cover the period of the missing measurements.

5. Either generate an initial measurement or a To Do for each measurement gap that is found.

This process relies on an important date that is maintained on each measuring component:

- Latest Contiguous Measurement Date/Time: this represents the last time the measuring component had a complete history of measurements without any gaps. By nature it implies that the is a gap immediately after it.

This date allows the periodic estimation process to efficiently identify those measuring components that are missing measurements and need to be estimated.

Note: It is possible to disable periodic estimation for a given device by updating the periodic estimation eligibility on the service point it is associated to. This is useful if there are one-off service points that should either never be eligible for estimation or should temporarily have estimation turned off.

Interval Periodic Estimation

When missing measurements have been identified by the interval periodic estimation functionality an estimation initial measurement will be created for each contiguous set of missing measurements in the estimation period.

There are two methodologies available for estimating interval measuring components:

- Rolling Delay: In this method the execution time of the periodic estimation process is an important factor in which measuring components will estimate how far each measuring component estimate. This method supports a minimum number of hours that will be estimated (as defined by the "Hours to Estimate" on the measuring component type).

- Predictable Cut-off Time: In this method all measuring components for a measuring component type will estimate until a specified point in time (as defined by the "Cut-off Time" on the measuring component type). With this method the cut-off time determines how far estimations are made rather than the execution time of the periodic estimation process. There is no minimum estimation size for this method it will always estimate up until the cut-off date/time even if that is only a single interval.

The cut-off time takes into consideration daylight savings time (DST) when the device is configured as sending data in legal time (meaning the Incoming Data Shift has been set to Always in Local). In these circumstances the cut-off time will be considered to be adjusted for DST. This is important because measurement data is stored in standard. For example:

Cut-off Time: 12:00AM

Measurement Time in Standard

01/15/2010 12:00AM (DST not in effect)

01/15/2010 12:00AM

04/15/2010 12:00AM (DST in effect)

04/14/2010 11:00PM

Furthermore, the cut-off time defined on the measuring component type does not have a time zone associated to it and as such it is considered to be defined in the time zone of the particular measuring component being processed. For example a cut-off time of 12:00AM would be considered to be 12:00AM UTC -08:00 and 12:00AM UTC -05:00 based on the time zones of the respective measuring components. This allows a single measuring component to apply to many time zones and behave uniformly.

Note: Additional detail on the interval periodic estimation process can be found on the D1-CIITBIH Algorithm Type.

Scalar Periodic Estimation

Scalar periodic estimation is only available for automatically read scalar measuring component since it requires that the scalar measuring component be read on at least a daily basis to be eligible.

The scalar estimation process relies heaving on details from the measuring component type to identify when a measurement is missing. This is because scalar measurements are not required to fall on specific boundaries like interval data. For example, a scalar measuring component read on a daily basis around midnight could have measurements at 12:00AM, 11:55PM, 12:01PM or even at various other points during the day if a field reading or on demand read is performed.

Auto-read scalar measuring component types are configured to provide information that will:

- Identify at what point or points during the day the measuring component will be read. This is a combination of the Hours Between Measurements and the First Daily Measurement Time on the measuring component type.

- Identify the allowable tolerance for measurements that do not fall on the specific expected measurement date/times (e.g. 11:55PM and 12:05AM are OK but 9AM is not). This is defined by the Early and Late Threshold on the measuring component type.

This allows the scalar periodic estimation process to identify the points during the day that measurements are expected and if no measurement are found it will generate an estimation initial measurement.

Unlike interval periodic estimation each missing measurement will be created as a separate estimation initial measurement.

To determine if a measuring component is eligible for estimation the process will evaluate if the Last Contiguous Measurement Date/Time far enough in the past. Specifically the number of hours elapsed since the Last Contiguous Measurement Date/Time must be greater than or equal to the Hours Before Estimation from the measuring component type.

Note: The first daily measurement time takes into consideration daylight savings time (DST) when the device is configured as sending data in legal time (meaning the Incoming Data Shift has been set to Always in Local). In these circumstances the first daily measurement time will be considered to be adjusted for DST. This is important because measurement data is stored in standard. For example:

First Daily Measurement Time: 12:00AM

Measurement Time in Standard

01/15/2010 12:00AM (DST not in effect)

01/15/2010 12:00AM

04/15/2010 12:00AM (DST in effect)

04/14/2010 11:00PM

Furthermore, the first daily measurement time defined on the measuring component type does not have a time zone associated to it and as such it is considered to be defined in the time zone of the particular measuring component being processed. For example, a first daily measurement time of 12:00AM would be considered to be 12:00AM UTC -08:00 and 12:00AM UTC -05:00 based on the time zones of the respective measuring components. This allows a single measuring component to apply to many time zones and behave uniformly.

Note: Additional detail on the scalar periodic estimation process can be found on the D1-ARSPE Algorithm Type.

Measurement Reprocessing

Next in This Section

- About Measurement Reprocessing

- Reviewing Measurements for Reprocessing

About Measurement Reprocessing

One major problem utilities face today is when devices are installed with an incorrect consumption multiplier. When this occurs, the billing consumption and the bills are incorrect retroactively.

The Measurement Reprocessing module automatically corrects historical consumption when a change is detected for either a Measuring Component multiplier or Install Event installation constant. The system monitors for these changes and automatically reprocesses historical measurements if one of the values changes. When a Measuring Component has been triggered for Measurement Reprocessing, a new message will be recorded on the Log tab for the Measuring Component. The message will look similar to this example: "Measuring Component Multiplier updated from 1.000000 to 2.000000. Measurements will be examined for reprocessing". Also, a link to the activity created to perform the reprocessing will be shown in the Related Object column.

Two different Activities are leveraged to perform this reprocessing:

- Measurement Reprocess Activity - Interval: this activity reprocesses interval data by dividing existing measurements by the Combined Multiplier stored on each measurement record and creates new System IMDs.

- Measurement Reprocess Activity - Scalar: this activity reprocesses scalar data by creating new System IMDs from the Reading value stored on each measurement.

The new System IMDs that are generated will skip both VEE and Consumption Sync but will apply the new multiplier and installation constant. Once the activity is finished, a list of the spawned IMDs will be displayed on the Activity screen.

This process works in tandem with the Adjustment Notification process to trigger billing adjustment notifications to the CIS. If usage transactions have already been fulfilled once measurements are reprocessed, then each affected period will be sent to CIS to indicate that an adjustment is required.

If desired, an approval step can be set as required on the related Activity Type. If set, a To Do will be generated for review. The review steps for this To Do are covered in the Reviewing Measurements for Reprocessing section.

The diagram below helps to provide an overview of Measurement Reprocessing:

For information on configuration, reference the related section for Configuring Measurement Reprocessing in the Administration Guide.

Reviewing Measurements for Reprocessing

When the Measurement Reprocessing Activity Types are configured as "Yes" in the "Approval Required?" field, then a To Do will be generated for user review. The To Do Type for this is set on the Activity Type as well (the configuration for this is covered in detail in the section for Configuring Measurement Reprocessing in the Administration Guide).

This To Do provides an approval step for a user to examine the Measurement Reprocessing Activity and perform the following:

1. Determine if the multiplier change appears legitimate and accurate. Information on the type of change that occurred can be found on the Log tab for the Activity. If the change should be rejected, this can be performed using the Discard button.

2. Ensure that the period being examined for reprocessing (shown as the Activity Start Date and End Date) covers the period expected. If not accurate, the dates can be changed using the Edit button.

If all information on the Activity is correct, then press the Approve button to allow reprocessing to continue. Once the activity is finished, a list of the spawned IMDs will be displayed on the Activity screen.

Refer to About Measurement Reprocessing for additional functional information.

Consumption Sync

Next in This Section

- Introduction to Consumption Sync

Introduction to Consumption Sync

Traditional interval and smart meters are often configured with two channels of consumption data, one interval and the other scalar. Utilities configure their meters this way for several reasons, including:

- Two channels provide for a redundant reading in case of a failure.

- Two channels provide for an independent check reading to ensure the meter is working properly.

- Customers often need both types of data for their business processes.

When capturing and storing usage for smart meters with related measuring components, one potential challenge is keeping measurements from related scalar and interval channels synchronized. Measurements for interval and scalar channels for the same device may fall out of alignment for many different reasons, such as:

1. Some meters use different technologies for recording interval and register readings, so the physical readings can be different

2. Readings can vary because of different measurement times

3. Estimation processes can vary by channel and produce different results

4. There can be a mix of actual and estimated measurements

Having two sources of consumption data can cause many problems for utilities. Unfortunately, utilities often need both the scalar and interval data to satisfy their business requirements. For example, scalar register readings may be used for billing, while the interval data is used on a customer self-service portal.

Keeping measurement data aligned between two related measuring components is achieved in several ways:

- During the initial load of initial measurement data VEE rules estimate for missing measurements using measurement data from related measuring components when available. Please refer to About IMD Estimations for more information.

- When measurement data is missing for one or both of the related measuring components the periodic estimation process will generate estimation initial measurement data that will estimate one measuring component then estimate the second measuring component such that the second measuring component's data can be synchronized with the first. Please refer to About Periodic Estimation for more information.

- When new, more accurate, measurement data is received for only one of the measuring components the consumption synchronization process will be initiated to align the previously estimated data with the newly received data. Note: this process is what this section will be concentrating on.

Consumption synchronization is a process by which measurement data for related measuring component is kept synchronized by re-estimating existing measurements when measurement data for related measuring components is received.

For example, consider the following scenario:

- A meter has both scalar and interval channels, and the scalar register channel is considered the "primary" or more reliable channel. The total consumption for each channel should match the consumption for the other channel.

- For a particular day, the daily reading for the "secondary" (interval) channel is received before reads from the scalar register have been received. This reading contains two missing intervals, which are estimated during VEE.

- After the interval reading has been finalized, a scalar register reading for the same day is received. The total of this reading is slightly different than the total of the interval reading due to the estimation of the missing intervals.

- The consumption synchronization process can trigger a re-estimation of the two estimated intervals to adjust the total of the interval reading to match that of the scalar register reading.

Other examples of situations that can be resolved using the consumption synchronization process include the following:

- Register Readings whose start/stop times do not align with interval boundaries

- A broken meter for which estimated readings are created for several days

- Requirements that readings from both channels match exactly even if neither contains estimated measurements

Primary Versus Secondary Measuring Components

When measuring components are related, one is considered the "primary" measuring component, and the other is considered the "secondary" measuring component. How the consumption synchronization process works for a given meter is based largely on which measuring component is considered primary and which is considered secondary.

The following are important principles regarding the primary/secondary measuring components:

1. The primary measuring component has the more reliable data.

2. The secondary measuring component should validate that its consumption aligns with the primary measuring component.

3. If the secondary measuring component needs to be estimated, it should estimate using the available data from the primary measuring component.

4. When possible, initial measurements for the primary measuring component should be processed prior to those for the secondary measuring component (Note: the D1-IMD batch process will process initial measurements in this order). In some scenarios when the secondary measuring component is read more frequently than the primary measuring component, it can be advantageous to violate this principle in favor of being able to execute smaller more frequent loads of measurement data.

5. Periodic estimation should be performed on the primary measuring component first, and then the secondary measuring component.

Understanding Consumption Synchronization Processing

This section provides an overview of the process that supports keeping consumption for related measuring components synchronized.

Note that the process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

1. An initial measurement is received (via initial load or manual) for a measuring component whose device configuration is consumption synchronization enabled.

2. The consumption synchronization process evaluates the related "consumption reference measuring component" to identify any measurements for the time period of the initial measurement are consumption sync eligible (typically estimated).

If eligible measurements are found a consumption synchronization activity is created. Note: the activity will not immediately process it will remain in an initial status until a background process is executed.

3. When the consumption sync background process is executed the activity initiates the re-estimation process by creating estimation initial measurements for each measurement that must be synchronized:

- For scalar measuring components, this initial measurement contains no measurement value.

- For interval measuring components, this initial measurement can contain a combination of "Regular" measurements (based on existing final measurements) and measurements that require estimation (based on and corresponding to the measurements with condition codes that fell between the range defined for "consumption synchronization" in step 2).

4. Each estimation initial measurement that was created will execute the estimation VEE group rules to recalculate the synchronization eligible measurements.

VEE

Next in This Section

- Introduction to VEE

- Validations

- Estimations

- Editing

Introduction to VEE

Next in This Section

- About VEE

- Decision-making VEE Rules

About VEE

As measurements are received into Oracle Utilities Meter Data Management there is a need to ensure the data is accurate, fill in any missing data with estimations, and flag any failures for review by users. The VEE (Validation, Estimation, and Editing) process is the primary method for ensuring that these objectives are met.

VEE acts as a multi-layered filtration system for IMDs. Raw data is received from the Head End as Initial Measurement Data and only clean, validated data is received on the other end in the Measurement table. The IMD has both a Pre-VEE and Post-VEE section that details any data changes made as part of VEE.

Initial measurement data can come from different sources, such as a head-end system or estimation processes, or it can be manually created by a user (to override or estimate consumption). Measurement data from these different sources might use different VEE Rules. For example:

- Initial measurements sent a head-end system might use strict VEE Rules

- Initial measurements created by a user (to override or estimate consumption) may use less strict rules

- Initial measurements created by the system to estimate consumption have very few (if any) VEE Rules

To assist with this need, you can define different VEE Groups for different sources of IMDs. The base package roles are:

- Initial Load: Used for initial measurement data received from a head-end system or import process

- Manual Override: Used for initial measurement data manually created by a user or created by the reconciliation process for scalar or subtractive interval measuring component types

- Estimation: Used for initial measurement data estimated by the system

- Projection: Used for "what if" services that are projecting future energy use for a measuring component

Refer to About Initial Measurement Data for additional functional information about the reconciliation process.

A measuring component's Measuring Component Type can define "fallback" VEE groups for each of these roles. In addition, an individual measuring component can specific a VEE group for each role. If the measuring component doesn't have a VEE group specified for a role, the "fallback" VEE group defined for the measuring component type is used.

The VEE process has a number of different objects that are detailed below that allow for configurability and flexibility in how the process executes.

VEE Groups

VEE groups are collections of VEE Rules that are applied to initial measurement data. During the VEE process, the system executes the VEE Rules defined in each VEE group. The rules within a VEE group are defined in a specific sequence, allowing control over the order in which the rules are executed.

VEE groups can be associated to a specific measuring component, or to a measuring component type (or both). VEE groups associated with a measuring component type are applied to all measuring components of that type, while those associated to a specific measuring component are applied only to that measuring component. VEE groups associated to a measuring component override those assigned to a measuring component type.

For information on configuration, reference the related section for Configuring VEE Groups in the Administration Guide.

VEE Rules

The specific validation and estimation processing performed on initial measurement data is defined in individual VEE Rules, each performing a specific set of targeted logic. The base product contains many VEE Rules you can use in your implementation, but you can also create your own custom VEE Rules.

Some VEE Rules generate VEE Exceptions if the initial measurement data fails the conditions specified for the rule. Other rules override measurements, changing measurement values as dictated by the rule's parameters. Some rules can both create exceptions and override the measurement as part of a single process. By convention, VEE Rules change the Post-VEE quantities of initial measurement data, but VEE Rules can change anything on an initial measurement.

For a list of validation VEE Rules, reference the About IMD Validations section. For a list of estimation VEE Rules, reference the About IMD Estimations section. For a list of general VEE Rules that handle decision-making within the VEE process, reference the Decision-making VEE Rules section.

For information on configuration, reference the related section for Configuring VEE Rules in the Administration Guide.

VEE Exceptions

Each VEE Rule defines an exception type and severity that specify how exceptions are tracked by the system. When an initial measurement fails a validation, an exception of the type specified for the failed VEE Rule is created. A single initial measurement can have multiple exceptions, one (or more) for each rule the measurement fails. This allows users to see all of the problems detected during the VEE process.

There are three levels of severity for VEE Exceptions:

- Info: Used to highlight something interesting, but not sufficient to cause the initial measurement to be put into the Exception state. Exceptions of this category can be used to report on the frequency of interesting, but not fatal issues.

- Issue: Used to report a problem that will prevent the initial measurement from being finalized. Multiple "issue exceptions" can be created during VEE processing. If at least one issue exists after all rules have been applied, the initial measurement is transitioned to the Exception state.

- Terminate: Used to report a severe issue that will cause the VEE process to stop and the initial measurement to be transitioned immediately to the Exception state. Only one terminate exception can be issued (as the first one causes VEE to stop on an initial measurement).

Note that exceptions are not deleted when an initial measurement is adjusted or corrected. After any issues are corrected or the initial measurement is overridden (or manually completed), the exceptions persist in a closed state for reporting purposes.

For information on configuration, reference the related section for Configuring Exception Types in the Administration Guide.

VEE Rule Eligibility Criteria

Each VEE Rule may optionally have eligibility criteria that controls if the rule is applied. This feature can greatly reduce the number of VEE groups you need to create, because it allows a single VEE group to have conditional VEE Rules based on eligibility criteria (rather than requiring a distinct VEE group for every combination of VEE Rules). Below are a few examples of ways you can use eligibility criteria:

- You might create a rule that compares interval consumption against related scalar consumption (such as might be the case with a device with both interval and scalar measuring components). This rule might use eligibility criteria that specifies that the rule is only applied if the initial measurement's measuring component has a corresponding scalar register measuring component.

- You might want to have a common VEE group but only have certain rules execute to execute based on Unit of Measure. An eligibility criteria can be setup so that a VEE Rule only executed for kWh whereas is skipped for kVARh.

- Another example might be a rule that compares the current consumption against standard consumption for measuring components of a certain type for the first six months after installation. You might create eligibility criteria that specifies that the rule is only applied if the measuring component's Device Configuration has been installed at a Service Point for less than six months.

For information on configuration, reference the related section for Configuring VEE Rules in the Administration Guide.

Decision-making VEE Rules

In addition to the VEE Rule Eligibility Criteria, there are VEE Rules delivered as part of the base product that help with decision-making when executing VEE (listed below). For more information on how each rule executes and can be configured, follow the link provided on the rule.

VEE Rule Name

Purpose

Exception Handler

This rule allows you to terminate the VEE process based on a configurable set of exceptions being present for the IMD. This rule also allows a unique To Do Type to be generated based on a group of exceptions.

Execute VEE Group

This rule performs a call to execute a separate VEE Group which includes execution of all VEE Rules within that group.

Successful Termination

This rule allows VEE to be successfully terminated based on a list of exceptions.

VEE Group Matrix (Factor)

This rule provides a way to choose different instances of a VEE Rule using a Factor. This factor leverages characteristics that are defined on Service Point, Device, or Measuring Component.

Validations

Next in This Section

- About IMD Validations

- Reviewing and Resolving VEE Exceptions

- Usage Transaction Validations

About IMD Validations

Validation of the Initial Measurement Data on the way in to Oracle Utilities Meter Data Management occurs by leveraging the diverse library of VEE Rules. Below is a list of the validation VEE Rules that are provided as part of base product. For more information on how each rule executes and can be configured, follow the link provided on the rule.

VEE Rule Name

Applicable Data Type(s)

Purpose

Consecutive Interval Check

Interval

This validation rule flags any combination of consecutive intervals within Initial Measurement Data based on the values of the data or the condition codes of the data.

Duplicate IMD Check

Interval or Scalar

This rule allows for a duplicate IMD to be flagged.

Dynamic Comparison Validation

Interval or Scalar

This powerful, flexible validation rule compares measurements to historical statistics for the related Service Point. The system will maintain statistics such as the following: sum, min, max, average, median, zero value count, outage count, and standard deviation. Then you define formulas (no programming required) for the comparison of current measurements to these statistics.

Ensure IMD Exists for Sibling MCs

Interval or Scalar

This rule validates that an IMD exist for all of the other measuring components associated to the same Device Configuration as the current measuring component, for the same period of time.

Final Measurement Replacement

Interval or Scalar

This validation rule allows you to define a variety of configuration options to decide if new data should replace existing measurements. The options include value change thresholds, percentage change thresholds, as well as condition code ranking.

High/Low Check

Interval or Scalar

This validation rule compares the total consumption of the current IMD to historical values. The comparison is normalized based on average daily usage (ADU). If the current IMD is too high or too low compared to historical data then an exception is thrown.

Inactive Measurement Check

Interval or Scalar

This validation rule flags any Initial Measurement Data received on a device that is either disconnected, uninstalled, and/or not connected to a Usage Subscription.

Interval Size Validation

Interval

This rule validates that the interval size (in seconds) supplied with the Initial Measurement is equal to the interval size defined on measuring component's type.

Interval Spike Check

Interval

This rule checks for spikes within an IMD and generates an exception if one is found.

Multiplier Check

Interval or Scalar

This rule validates that the register multiplier supplied with the IMD is equal to the multiplier stored on the measuring component. If not, an exception is created using the register multiplier exception type and severity configured on the rule.

Negative Consumption Check

Interval or Scalar

This rule flags any IMD where the total consumption is negative.

Prolonged Estimation Check

Interval or Scalar

This validation rule will alert you when a device has been estimated for an extended period of time.

Raise Missing Quantity Exception

Interval

This rule flags any missing interval data.

Sum Check

Interval or Scalar

This rule is used to compare the difference between interval data to scalar data for a period of time, or between a set of TOU scalar reads to a "Sum" scalar reading.

Unit of Measure Check

Interval or Scalar

This rule checks the unit of measure (UOM) passed in with the Initial Measurement against the primary unit of measure configured on the measuring component's type.

Zero Consumption Check

Interval or Scalar

This rule checks if the total consumption for the IMD is zero. There is also a check for whether an outage occurred during the same time as the zero consumption to provide ways to avoid exceptions in that case.

Refer to About VEE for additional functional information.

Reviewing and Resolving VEE Exceptions

All To Dos generated by a VEE Exception will link back to the Initial Measurement Data that originally failed to create the VEE Exception.

Users have a number of options for dealing with initial measurements with exceptions.

- After correcting the cause of the issues that triggered the exceptions, a user can reinitiate the VEE process for the IMD using the Perform VEE button.

- A user can Discard the initial measurement.

- A user can use the Force Complete button on the IMD in the scenario that they want to approve the exception and the measurement information in the IMD. Note: No VEE processing is performed on initial measurement data that is force completed. Regardless of the action taken by the user, the system will complete any open To Do Entries that created when the initial measurement entered the Exception state.

Refer to About VEE for additional functional information.

Usage Transaction Validations

There are also validations available during the execution of usage calculation. For more information on these reference the Reviewing and Resolving Usage Transactions section.

Estimations

Next in This Section

- About IMD Estimations

- Usage Transaction Estimations

About IMD Estimations

Below is a list of the estimation VEE Rules provided as part of base product that are responsible for filling the missing data within an IMD. For more information on how each rule executes and can be configured, follow the link provided on the rule.

VEE Rule Name

Applicable Data Type(s)

Purpose

Interval Adjustment From Scalar

Interval

This rule performs adjustments to interval values based on the values from the associated scalar data on the same device.

Interval Averaging Estimation

Interval

This rule finds historical interval data from the same measuring component based on a variety of configuration options to use for estimating any missing data within an IMD.

Interval Create Estimation IMD for Gap

Interval

This estimation rule creates a new Estimation IMD to fill gaps between the interval data received from the Head End.

Note: this estimation rule acts differently from the other rules as it creates a new IMD rather than filling in missing values in an estimation IMD created from periodic estimations.

Interval Interpolation Estimation

Interval

This rule attempts to interpolate gaps within an IMD using prior and subsequent intervals as starting points for linear interpolation.

Interval Profile Estimation

Interval

This rule will estimate any missing interval data for the IMD based on a referenced Profile Factor.

Scalar Calculation From Interval

Scalar

This rule performs adjustments to scalar values based on the values from the associated interval data on the same device.

Scalar Estimation

Scalar

This rule finds historical scalar data from the same measuring component based on a variety of configuration options to use for estimating any missing data within an IMD.

Scalar Profile Estimation

Scalar

This rule will estimate any missing scalar data for the IMD based on a referenced Profile Factor.

Scalar Proration

Scalar

This rule will prorate the value of a scalar reading that has two valid scalar readings on either side as boundaries. It will also take into account any related interval data within the same period to exclude from the calculation.

Refer to About VEE for additional functional information.

Usage Transaction Estimations

There are also estimations available at the time of usage calculation. For more information on these reference the Reviewing and Resolving Usage Transactions section.

Editing

Next in This Section

- About IMD Editing

- Editing Initial Measurements

- Generating New Initial Measurements

About IMD Editing

At times, the values received in as Initial Measurement Data need to be edited by a user. This is covered in the Editing Initial Measurements section.

If measurement data is found to be incorrect, a new IMD must be generated to correct the data. This is covered in the Generating new Initial Measurements section.

Refer to About VEE for additional functional information.

Editing Initial Measurements

Initial measurements can be manually edited via functions available in the Interval Initial Measurement Lens or Scalar Initial Measurement zones in the Initial Measurement portal. Manual edits can include changes to the measurement values or condition codes.

By default, manual edits made by users of these zones are not logged on the Log tab.

Refer to Configuring Measurement Logging for additional information on how initial measurement changes can be logged.

Generating New Initial Measurements

The main location for viewing measurements and generating new IMDs for any discrepancies is through the 360 Degree View Measuring Component portal. On the portal many of the zones provide ways to apply measurement functions that will generate a new IMD.

360 Degree Search

Next in This Section

- Using 360 Degree Search

Using 360 Degree Search

The 360 Degree Search feature allows users to search for devices, measuring components, service points, and/or usage subscriptions using a variety of search criteria.

From the search results list, you can navigate to the 360 Degree View portal to view data on one of the following tabs:

- Measuring Component

- Device

- Service point

- Usage Subscription

- Contact

When accessed, the 360 Degree View opens on the tab corresponding to the type of object (device, measuring component, etc.) you select. For example, if you click the Measuring Component description, the Measuring Component tab opens.

Refer to 360 Degree Views for more details about 360 Degree View.

The following options are available for 360 Degree Search:

- Search by Name: Allows search by name/address OR contact identifier OR usage subscription identifier. To search by address, click Go To Search by Address. To search by device, click Device.

- Search by Address: Allows search by address/name OR service point identifier. To search by name, click Go To Search by Name. To search by device, click Device.

- Note: "Search by Address" search results contain service points with one or more active usage subscriptions only.

- Search by Device: Allows search by device identifier OR measuring component identifier. To search by name, click Go To Search by Name. To search by address, click Address.

360 Degree Views

Next in This Section

- 360 View Measuring Component

- 360 Degree View Device

- 360 Degree View Service Point

- 360 Degree View Usage Subscription

- 360 Degree View Contact

360 View Measuring Component

Next in This Section

- Using 360 Degree View Measuring Component

- Applying Measurement Functions

Using 360 Degree View Measuring Component

This portal is used to view a broad set of information related to a Measuring Component.

You can access the portal from the Main > 360 Search > [options]. You are provided with the option of searching by Name, Address, or Device. Once a Measuring Component has been selected you are brought to the 360 Degree View Measuring Component portal.

The following zones may appear as part of the portal's Measuring Component tab page:

- Measuring Component Overview: Displays the Service Point, device, Device Configuration, Install Event, and Usage Subscription for the selected device.

- Device Configuration Overview: Displays an overview of the measuring component's parent device's configurations over time, including the measuring components associated with each configuration, and Service Points (along with the relevant Install Events) at which the device's configurations have been installed over time, if any exist.

- To create a new reading for a scalar measuring component associated to a Device Configuration, click the New Reading link in the zone title bar.

- Interval - Initial Measurement Overlay: Overlays initial interval measurements (either pre-VEE or post-VEE) against the final measurements for a given period in graphic and tabular formats.

- Final Values Overlay: Graphs final measurements for a measuring component, and provides the ability to overlay the graphed data with final measurements from other measuring components. The zone also permits overlaying data from the same measuring component for different time periods, as well as data from measuring components that measuring different quantities, such as temperature.

- Interval - Audit View: Allows users to view an interval measurement curve for a given period overlaid with the count of audit records for each individual measurement. It also allows users to magnify a portion of the curve and see how the measurements looked at different points in time.

- Time of Use By Day: Displays daily TOU-mapped usage data for an interval measuring component based on a user- defined time period and TOU map.

- Time of Use Overlay: Displays an overlay of the TOU periods on a final interval measurement along with totalized TOU consumption based on a user-defined time period and TOU map.

- Scalar - Initial Measurement Overlay: Overlays initial scalar measurements (either pre-VEE or post-VEE) against the final measurements for a given period in graphic and tabular formats.

- Scalar - Audit View: Allows users to view a scalar measurement for a given period overlaid with the count of audit records for each individual measurement. It also allows users to magnify a portion of the measurement and see how the measurements looked at different points in time.

- Measurements: Displays measurement details for the current measuring component in a tabular format. (split into two zones for v2.2)

- Usage Subscriptions Directly Linked to MC: Displays Usage Subscriptions that are directly linked to current measuring component.

Functions are available in many of these zones that allow you to interact with the measurement data and/or create new data. For more information of these functions refer to the Applying Measurement Functions section.

Applying Measurement Functions

Many of the Interval measurement zones on the Measuring Component tab of the 360 Degree View provide access to the following functions:

- Create Scratchpad: Creates a scratchpad measuring component along with new initial measurement data by copying all or some of the final measurements from the measuring component displayed in the zone.

- Create / Override: Creates new initial measurement data for a selected measuring component for all or part of a selected time period. This function can either copy existing final measurements or create new measurement data for the initial measurement it creates.

- Export to Excel: Exports measurement data to a comma-separated values spreadsheet.

- New Reading: Creates a new interval initial measurement reading for the measuring component.

- Rederive Values: Rederives the measurement's values displayed in the zone.

- Save As: Creates new initial measurement data for a measuring component other than that being displayed by copying all or some of the final measurements shown in the zone.

Many of the Scalar measurement zones on the Measuring Component tab of the 360 Degree View provide access to the following functions:

- Convert to Interval: Converts scalar consumption into interval consumption. The converted consumption is held in a new scratchpad measuring component.

- Create / Override: Creates new initial measurement data for a selected measuring component for all or part of a selected time period. This function can either copy existing final measurements or create new measurement data into the initial measurement it creates

- Export to Excel: Exports measurement data to a comma-separated values spreadsheet.

- New Reading: Creates a new scalar initial measurement reading for the measuring component.

- Rederive Scalar Values: Rederives the measurement's values displayed in the zone.

360 Degree View Device

Next in This Section

- Using 360 Degree View Device

Using 360 Degree View Device

This portal is used to view a broad set of information related to a Device.

You can access the portal from the Main > 360 Search > [options]. You are provided with the option of searching by Name, Address, or Device. Once a Device has been selected you are brought to the 360 Degree View Device portal.

The following zones may appear as part of the portal's Device tab page:

- Device Overview: Displays the device, Service Point, Install Event, and Usage Subscription for the selected device.

- Device Configuration Overview: Displays an overview of the device's configurations over time, including the measuring components associated with each configuration, and Service Points (along with the relevant Install Events) at which the device's configurations have been installed.

- Scalar Readings: Displays a list of scalar readings for scalar measuring components associated with the current device and Device Configuration.

- To create a new reading for scalar measuring components associated with the Device Configuration, click New Reading.

- To edit an existing reading, click the edit icon for the reading you wish to edit. Editing a reading creates new initial measurements that are validated. If these edits do not pass validations, including VEE Rules, the changes are not saved.

360 Degree View Service Point

Next in This Section

- Using 360 Degree View Service Point

Using 360 Degree View Service Point

This portal is used to view a broad set of information related to a Service Point.

You can access the portal from the Main > 360 Search > [options]. You are provided with the option of searching by Name, Address, or Device. Once a Service Point has been selected you are brought to the 360 Degree View Service Point portal.

The following zones may appear as part of the portal's Service Point tab page:

- Service Point Overview: Displays the Service Point, device, Device Configuration, Install Event, and Usage Subscription for the selected Service Point.

- Measuring Component Types: Lists the measuring component types configured for the Service Point. To display consumption history for a measuring component, click the Broadcast icon next to the Measuring Component Type. Doing so will display either the Interval Consumption History or the Scalar Consumption History.

- Interval Consumption History: Displays a graph of interval consumption for a broadcast interval measuring component type.

- Scalar Consumption History: Displays a graph of scalar consumption for a broadcast scalar measuring component type.

- Timeline: Displays a timeline of events for the Service Point, including usage transactions, activities, and VEE exceptions. Each event is depicted as a button containing the date on which the event occurred. To search for a specific month and year in the Timeline zone, select the month and year from the drop-down lists and click the Search icon. To navigate forward and back along the timeline, use the left and right arrows.

- Service Issue Monitors Related to SP: displays a list of service issue monitors and related service investigative orders related to the current Service Point, in reverse chronological order.

360 Degree View Usage Subscription

Next in This Section

- Using 360 Degree View Usage Subscription

Using 360 Degree View Usage Subscription

This portal is used to view a broad set of information related to a Usage Subscription.

You can access the portal from the Main > 360 Search > [options]. You are provided with the option of searching by Name, Address, or Device. Once a Usage Subscription has been selected you are brought to the 360 Degree View Usage Subscription portal.

The following zones may appear as part of the portal's Usage Subscription tab page:

- Usage Subscription Overview: Displays the Usage Subscription, main customer, Service Point, and direct channels for the selected Usage Subscription.

- Usage Transaction History: Lists usage transaction records for the Usage Subscription, including the start date/time, end date/time, description, and duration (in days) for each.

- Timeline: Displays a timeline of events for the Usage Subscription, including usage transactions, activities, and VEE exceptions. Each event is depicted as a button containing the date on which the event occurred. To search for a specific month and year in the Timeline zone, select the month and year from the drop-down lists and click the Search icon. To navigate forward and back along the timeline, use the left and right arrows.

360 Degree View Contact

Next in This Section

- Using 360 Degree View Contact

Using 360 Degree View Contact

This portal is used to view a broad set of information related to a Contact.

You can access the portal from the Main > 360 Search > [options]. You are provided with the option of searching by Name, Address, or Device. Once a Contact has been selected you are brought to the 360 Degree View Contact portal.

The following zones may appear as part of the portal's Contact tab page:

- Contact Overview: Displays contact information (name, phone number, email address, etc.) for the selected contact.

- Contact's Service Points: Lists the Service Points related to the contact, including the relationship type (main contact, main customer, etc.) for each.

- Contact's Usage Subscriptions: Lists the Usage Subscriptions related to the contact, including the relationship type (main contact, main customer, etc.) for each.

Usage

Next in This Section

- Introduction to Usage Calculation

- Usage Subscriptions

- Usage Transactions

- Time of Use Maps

- Dynamic Options

- Consumption Extract Requests

- Contacts

Introduction to Usage Calculation

Next in This Section

- About Usage Calculation

About Usage Calculation

Oracle Utilities Meter Data Management can calculate and publish usage calculated from measurement data to service providers on an ongoing basis. In addition, external systems can request usage whenever needed. Usage calculations derive a usage transaction's usage quantities using the measurements linked to a usage subscription's service points.

Before bill determinants can be calculated, you must first create a Usage Subscription. The Usage Subscription defines the external system to which the data should be sent as well as the Usage Group that will be used for calculation. The Usage Rules defined for the Usage Group are responsible for performing the specific calculations, validations, or estimations for bill determinants.

Usage Service Quantities (bill determinants) are derived from the Measurements of the measuring components installed at the Usage Subscription's Service Points during the calculation period. A Service Point is linked to measuring components through an Install Event linked to the measuring components' Device Configuration.

The results of all calculations performed by Usage Subscriptions are stored as a Usage Transaction.

At any instance in time:

- A Usage Subscriptions may be linked to multiple Service Points

- A Service Point may be linked to a single Device Configuration

- A Device Configuration may have multiple measuring components

The calculation period for bill determinant calculations can span many days and over this period:

- The Service Points linked to the Usage Subscription can change (Service Points can be added and removed)

- The Device Configurations installed at the Service Point can change (due to device reconfigurations and meter exchanges)

This means that values for each Usage Subscription can be calculated using multiple Service Points and measuring components.

The Usage Calculation process has a number of different objects that are detailed below that allow for configurability and flexibility in how the process executes.

Usage Groups

Usage Groups are collections of Usage Rules that are used to either calculate bill determinants or validate bill determinants. During the Usage Transaction process, the system executes the Usage Rules defined in the Usage Group referenced on the Usage Subscription. The rules within a Usage Group are defined in a specific sequence, allowing control over the order in which the rules are executed.

For information on configuration, reference the related section for Configuring Usage Groups in the Administration Guide.

Usage Rules

The specific calculation, validation, or estimation processing performed on a Usage Transaction is defined in individual Usage Rules, each performing a specific set of targeted logic. The base product contains many Usage Rules you can use in your implementation, but you can also create your own custom Usage Rules.

For a list of validation Usage Rules, reference the About Usage Validations section. For a list of estimation Usage Rules, reference the About Usage Estimations section. For a list of all other Usage Rules that handle calculation of bill determinants, reference the Inventory of Other Usage Rules section.

For information on configuration, reference the related section for Configuring Usage Rules in the Administration Guide.

Usage Transaction Exceptions

Each Usage Rule defines an exception type and severity that specify how exceptions are tracked by the system. When a Usage Transaction fails some part of a Usage Rule, an exception of the type specified for the failed Usage Rule is created. A single Usage Transaction can have multiple exceptions, one (or more) for each rule that failed. This allows users to see all of the problems detected during the Usage Calculation process.

There are three levels of severity for Usage Transaction Exceptions:

- Information: Used to highlight minor issues, but not sufficient to cause the Usage Transaction to be put into a failure state. Exceptions of this category can be used to report on the frequency of interesting, but not fatal issues

- Issues: Used to report a problem that will prevent the usage transaction from being sent. Multiple "issue exceptions" can be created during Usage Transaction processing. If at least one issue exists after all rules have been applied, the Usage Transaction is transitioned to a failure state requiring review and approval.

- Terminate: Used to report a severe issue that will cause the Usage Calculation process to stop and the Usage Transaction to be transitioned immediately to a failure state requiring review and approval. Only one terminate exception can be issued (as the first one causes calculation processing to stop on for a Usage Transaction). This should be used for cases where manual override / approval isn't accurate. For example, a "Curve Not Continuous" error that says the interval data doesn't cover the full usage period should always be set to Terminate as an Exception Severity.

Note that exceptions are not deleted when a Usage Transaction is adjusted or corrected. After any issues are corrected or the Usage Transaction is overridden (or manually completed), the exceptions persist in a closed state for reporting purposes.

In addition to exceptions, usage processing can also trigger the creation of To Do Entries related to failed validations. If Issue or terminate exceptions exist for an initial measurement, a To Do Entry is created when the usage transaction is transitioned to the Exception state. The To Do Type and default To Do Role of this To Do Entry are defined on the Enter system event for the Exception state of the business object used to define the usage transaction.

To Do Entries created in this way can be routed to different roles depending on the exception's message category and number (using the To Do Type's Message Overrides tab).

For information on configuration, reference the related section for Configuring Usage Transaction Exception Types in the Administration Guide.

Usage Rule Eligibility Criteria

Usage rule eligibility criteria are user-definable conditions that could cause a given Usage Rule to be applied or skipped. This can involve the evaluation of some attribute of the usage subscription or service point, or something else entirely. A Usage Rule can have multiple eligibility criteria for determining if the rule should be applied or skipped, based on a user-defined sequence.

For information on configuration, reference the related section for Configuring Usage Rules in the Administration Guide.

Usage Subscriptions

Next in This Section

- About Usage Subscriptions

- Maintaining Usage Subscriptions

About Usage Subscriptions

A Usage Subscription is an ongoing request to send one or more Service Points' usage to one or more external systems. The Usage Subscription defines which Usage Group should be used to calculate Service Quantities (often referred to as bill determinants).

Usage subscriptions must reference a:

- Service Provider. The service provider is used as the identity of the subscribing system. In other words, you must set up a service provider for any system that subscribes to bill determinants.

- Contact: Contacts are individuals or business entities with which a company has contact. A contact exists for every individual or business related to a usage subscription. A single usage subscription can have many contacts, and a single contact may be referenced on many different usage subscriptions. Contacts have a 1-to-1 correlation with a "person" in a customer information system (CIS) and the CIS is considered the system of record for contact information.

An Aside: No Account Object Exists

Oracle Utilities Meter Data Management is not considered the system of record for accounts or Usage Subscriptions. The customer information system (or some other system) is considered the system of record for this type of information. In order to minimize the amount of data that must be synchronized between systems, account and service agreement oriented attributes used by the meter data products are held on Usage Subscriptions. For example, if an account's ID and its customer class are relevant to usage calculations, each Usage Subscription must reference both elements. This is an important distinction to keep in mind when creating custom Usage Subscriptions for your implementation.

Refer to About Usage Calculation for a broader functional view of the overall process.

Maintaining Usage Subscriptions

This portal is used to display and maintain a Usage Subscription.

Refer to About Usage Subscriptions or About Usage Calculation for additional functional information.

You can access the portal from the Main > Usage > Usage Subscription. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Usage Subscription: Defines basic information about the usage subscription, including factor overrides, usage groups, and service points.

- Sub Usage Subscriptions: Lists the first fifty "sub" usage subscriptions for the master usage subscription displayed in the Usage Subscription zone. This zone is only displayed for "master" usage subscriptions.

Usage Transactions

Next in This Section

- About Usage Transactions

- About Usage Validations

- Reviewing and Resolving Usage Transactions

- Triggering Adjustment Notifications

- Inventory of Other Usage Rules

About Usage Transactions

Usage Transactions are records of bill determinant calculations for a Usage Subscription. All of the Service Quantities calculated are stored as part of the Usage Transaction.

Most requests for usage result in the creation of a usage transaction, but it is possible for an external application to invoke the usage calculation engine real-time. In other words, usage can be retrieved for a usage subscription real-time without creating a usage transaction. This technique is only recommended for online requests, not as part of batch processes.

Usage Group Determination

The first step in calculating the usage is to determine the usage group holding the rules set used in calculating or validating the bill determinants. There are two ways of configuring the usage group to use in the processing. It may be specified on the usage subscription during its creation with an effective and expiration date. If there are no usage groups in effect for the usage transaction, the fallback usage group specified in the usage subscription type will be used. The other way is to specify an algorithm – Determine Usage Group Override, on the usage subscription type. This option provides flexibility in cases where special or custom logic will be required to identify the usage group. Base product delivered an algorithm that identifies the usage group based on the rate and installed device. Additional details can be found in the Detailed Description of the D2-DRVUSGGRP Algorithm Type.

Calculation Period

Usage transaction requests must specify the date range for the usage transaction. This date range is referred to as the calculation period for the usage transaction. The dates that define the calculation period are specified by a subscribing system when it requests a usage transaction.

Multiple Device Configurations and the Calculation Period

In situations where a meter exchange has taken place at a service point, more than one device configuration can be in effect during the usage transactions cutoff period (the time period between the End Date/Time From and End Date/Time To values).

To account for this, the Meter Exchange Option on the Usage Subscription Type can be used to specify how the usage calculation should handle multiple device configurations in effect during the cutoff period. If the flag is set to 'Defer Calculation', new device configurations are excluded in the current usage transaction. If the flag is blank or set to 'Calculate Usage', new device configurations are included in the current usage transaction.

Date Breaks

As noted above, date breaks are used to break up a usage period into sub-periods based on the dates on which rate changes took place for the service point. For example, suppose a subscribing system requests usage for the month of January. The customer for this request has an interval meter, and the customer's usage is calculated by applying a TOU map to their interval consumption. The subscribing system detects that the customer's rate changed in the middle of January (on January 16) and wants the TOU consumption calculated in two "chunks" (before and after the rate change). Because the customer has an interval meter, the exact consumption amounts before and after the rate change can be precisely calculated (as opposed to calculating each period's amount by dividing the total usage by the number of days in each period).

One approach to this situation would be for the subscribing system to request two usage transactions (where each has the desired date range). Another approach is for the subscribing system to request a single usage transaction with date breaks that define the date ranges before and after the rate change. To continue the above example, a usage transaction could be created with a date break on January 16.

If a usage transaction has date break(s), the usage calculation engine segregates the usage into multiple usage periods based on the date breaks. If there are no date breaks in the usage transaction, a single usage period is created for the entire calculation period.

As of the v2.0.0 release, the only way a usage transaction can have date breaks is if the subscribing system supplies these when it requests usage (only the subscribing system knows if and when its prices and pricing rules change during the billing period). If an implementation has additional criteria that causes date breaks, these criteria can be easily added to the usage transaction's business rules.

Service Quantities

Every usage period created for a usage transaction contains one or more service quantities. Service quantities are calculated by the usage group's rules specified for the usage subscription from which the usage transaction is created. For example, a usage transaction might have service quantities calculated by a single rule that applies a TOU map to the kWh channel on the device configuration installed at the service point.

Each service quantity lists details about that quantity, including a UOM (or TOU or SQI as appropriate) and a quantity. In addition, each service quantity also references the source (measuring component) of the quantities (for audit purposes).

Quality Assessment for Bill Print Options

Usage transaction service quantities can also contain information about the quality of the measurements used in their calculations and other information that can be sent to an external customer information or bill print system. This information is included in both the usage transaction and its related outbound message.

Quality Assessment

The Get Interval Data, Get Scalar Details, and Get Time of Use Mapped Usage usage rules include a "Perform Measurement Quality Assessment" option that indicates (yes or no) if the measurement conditions of the measurements used when calculating usage should be evaluated and included in the resulting usage transaction and outbound message. When enabled (set to "Yes"), the usage rule algorithm evaluates the condition codes of the measurements used in the calculation to determine if they fall within a "Regular" range of conditions (this range is defined by the "Bottom Regular Condition Range" and "Top Regular Condition Range" algorithm parameters). The result of this assessment is displayed in the "Data Quality Assessment" column in the Usage Periods section which indicates if the service quantity is based on "regular" or "non- regular" data. (If the "Perform Measurement Quality Assessment" option is disabled, the "Data Quality Assessment" column displays "No Assessment Done). In addition, the "Source Measurement Quality List" column contains XML that contains a list of measurements aggregated by condition/quality.

Maximum/Minimum Dates and Times

The Get Interval Data, Get Time of Use Mapped Usage, and Vector and Service Quantity Math usage rules can be configured to identify the date/time of the maximum or minimum measurement value used when calculating the service quantity. For these functions, if "Max" or "Min" is selected as the "Calculation Function" (or the "Comax" and "Comin" functions for the "Vector and Service Quantity Math" rule), the date/time of the maximum/minimum value will be included in the resulting usage transaction and outbound message. The "SQ Highlight Date/Time List" column contains XML that contains a list of maximum/minimum date/times, based on condition/quality.

Usage Transaction Export Configuration

Usage transactions can also include additional information about its related meters and service points, as well as an indication if the service quantity is based on estimated usage. The "Usage Transaction Export Configuration" master configuration is used to control the export of this data. It holds the device and service point business objects used to supply meter and service point information included in the usage transaction and outbound message.

The "Usage Transaction Export Configuration" master configuration also defines the threshold percentage above which a service quantity being exported via the usage transaction outbound message is marked as an estimate. For example, of the "Estimation Threshold Percentage" is set to 35%, any service quantity being exported that was calculated from measurements containing more than 35% estimated usage is marked "estimated".

Service Quantities for Scalar Usage

Usage transactions and service quantities for scalar usage differ in some ways from those created from interval usage. For example, suppose a subscribing system requests usage for the month of January for a customer with a scalar meter that has been exchanged mid-month. In this case, the customer's usage is calculated by finding the scalar readings in the requested period (including all meter exchanges), and the subscribing system requires a record of all scalar readings AND a total of their consumption

Scalar rules cannot use date breaks because the system doesn't store interval values so it cannot accurately compute the amount in each period. In this case, scalar usage rules retrieve scalar readings for the service points linked to the usage subscription, and then creates a single usage period for the usage transaction's entire calculation period. The individual scalar readings are captured as "scalar details" in the usage transaction.

To continue the example above, there would be 2 entries in the Scalar Details, one for each meter, and a single usage period that contains the total consumption for the entire calculation period. The tables below illustrate what this might look like.

Usage Estimation

When calculating usage for monthly read scalar meter, the end read may not be available by the end of the bill cycle window. If the request indicated that estimated measurement is allowed, the Get Scalar Details usage rule creates an estimated end read that will be used to calculate the scalar usage.

Calculating Usage for Items

Usage transactions can also calculate usage for items installed at service points. Usage for items is calculated through use of Get Item Counts and Consumption usage rule. This rules calculate usage based on the number of items installed at each service point and the average daily service quantity defined for each item's type. The specifics of how usage is calculated for items is based on the service point category (defined on the service point type) at which the items are installed (item or multi-item).

Hypothetical Calculations - Rate Comparisons

When Oracle Utilities Meter Data Management is integrated with Oracle Utilities Customer Self Service, customers can perform rate comparison calculations to see the impact to their usage and billing charges based on a set of user-defined usage adjustments. Rate comparison usage transactions are flagged "Hypothetical Calculation" in the Calculation Mode field.

Profile Accumulation Usage Rules and Usage Adjustment Profile Factors

Rate comparison usage transactions can be created through the use of Profile Accumulation usage rule. This rule combine a service point's measurements with "usage adjustment" measurements derived from measurement data for profile measuring components defined as characteristic values for one or more profile factors.

Usage adjustment profile factors are associated to usage adjustment types defined in the Usage Adjustment Type extendable lookup and rates defined in the CC&B Rate Schedule extendable lookup (this association is defined in the Self-Service Master Configuration). When the usage transaction is created, the rate determines the usage group to execute and usage adjustment profile factors to include in the calculation based on the CC&B Rate Schedule extendable lookup.

Note: The Profile Accumulation usage rule should be configured with eligibility criteria such that they are only executed when the Calculation Mode for the usage transaction is set to "Hypothetical Calculation" (D2HC).

Including Summary Service Quantities and Interval Data Snapshots with Usage Transactions

Usage transactions can be configured to include summary service quantities and an interval data "snapshot" along with service quantities and other information sent to external systems. This used when sending usage to a billing system that performs interval-based pricing calculations.

Only usage transactions created (in whole or in part) by either the Get Interval Data or Vector and Service Quantity Math usage rules can include interval data snapshot information. These rules use the Extract Interval Data flag to indicate ("Yes" or "No") if a "snapshot" of the interval data resulting from the usage rule should be sent to external systems when usage from the usage transaction is sent to external systems.

In the base package, the Usage Transaction Outbound Message (D2-UsageTranOutboundMesg) business object is used to create outbound messages containing usage transactions. This business object includes the "Build Summary SQs" (D2-BLDSUMSQ) Pre-Processing algorithm which calculates and creates the interval data snapshot and other summary service quantities.

How Summary Service Quantities and the Interval Data Snapshot is Calculated

As noted above, the "Build Summary SQs" (D2-BLDSUMSQ) algorithm builds the Summary Usage Periods List based on the usage transaction's details. For every usage period within the usage transaction:

An entry is inserted into the summary service quantity list for every distinct UOM/TOU/ SQI combination in the usage period service quantity list.

An entry is inserted into the service point service quantity list for every distinct service point ID/UOM/TOU/SQI combination in the usage period service quantity list.

Interval data for multiple service quantities are combined into a single interval data curve per UOM/TOU/SQI combination. Intervals are summarized and scaled based on a common SPI

The "Build Summary SQs" (D2-BLDSUMSQ) algorithm uses the "Target Interval Size" parameter to define the interval size of the combined curve when one or more curves are combined with different interval sizes. For example, when combining interval data with 15 minutes intervals (SPI 900) and data with 60 minute intervals (SPI 3600), a Target Interval Size of 60 minutes (SPI of 3600) would result in combined data with an interval size of 3600 (the 15 minute intervals would be scaled up to 60 minute intervals before being combined with the 60 minute interval data).

Refer to About Usage Calculation for a broader functional view of the overall process. For information on how to configure the request and response process for Usage Transactions, reference the Integrating Usage Transactions section of the Admin Guide.

About Usage Validations

For the sake of keeping the volume of To Dos to a manageable level it may make sense to shift certain validations to the usage transaction process rather than the IMD load process. The validation should be done on a usage transaction when the result is only crucial for the systems receiving usage transactions rather than more real time needs such as online presentation to a customer. Below is a list of the Usage Rules used for validating usage transactions that are provided as part of base product. To get more information on how each rule executes and can be configured, follow the link provided on the rule.

Usage Rule Name

Applicable Data Type(s)

Purpose

Usage High/Low Rule

Interval or Scalar

This validation rule compares the Service Quantities of the Usage Transaction to historical values. If the current value is too high or too low compared to historical data then an exception is thrown.

Validate Against Tolerance

Interval or Scalar

This Usage Rule is used to validate the calculated usage against a tolerance value. The tolerance value may either come from the specified value or tolerance factor defined in the Usage Rule.

Business Flag Hold

Interval or Scalar

This Usage rule can stop a usage transaction from proceeding when there have been business flags for the applicable service points. The hold can either be indefinite or set to expire a configurable amount of time prior to the calculation window ending.

Refer to About Usage Transactions or About Usage Calculation for additional functional information.

Reviewing and Resolving Usage Transactions

This portal is used to review and/or resolve a Usage Transaction.

Refer to About Usage Transactions or About Usage Calculation for additional functional information.

You can access the portal from the Main > Usage > Usage Transaction. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Usage Transaction: Defines basic information about the usage transaction, including usage period date ranges, date breaks within the usage period, scalar usage details, and usage quantity details.

- Service Quantity Overlay: Displays interval data for each service quantity for the usage transaction's usage period

- Time of Use By Day: Displays TOU-mapped interval data by day for the usage transaction's usage period

A number of important actions are available for a Usage Transaction depending on its status:

Action

Allowed Statuses

Details

Approve

Approval In Progress

Issue Detected (only when the exceptions are marked to require approval)

Allows a user to bypass any exception or failure message for the Usage Transaction and attempt to send it to the requesting system.

Re-Calculate

Approval In Progress

Issue Detected

Reruns the entire process of calculation along with any validations (all Usage Rules) for the Usage Transaction.

Subsequent Correction

Sent

Allows a user to indicate that the usage transaction was corrected after being sent. Sets the status of the usage transaction to Subsequent Correction.

Resend

Send Error

Allows a user to re-send a usage transaction (via its related outbound message) to an external system. Used when an error occurs when sending usage transactions.

Triggering Adjustment Notifications

If any new Measurements are received from a device after that period has been calculated in a Usage Transaction then a discrepancy exists between Oracle Utilities Meter Data Management and the external system (often a customer information system or CIS). As a result, Oracle Utilities Meter Data Management provides a method to notify external systems of these adjustments to Usage Transactions. A Usage Transaction Correction Processor activity is created for each usage transaction that may have been impacted by an initial measurement. The Usage Transaction Correction Monitor batch (D1-UTCRN) is used to process these activities.

On the Service Provider for CIS, a processing method of "Usage Trans Subsequent Correction Notification" must be configured to specify the message that should be sent to notify CIS when an adjustment occurs for a Usage Transaction in Oracle Utilities Meter Data Management.

The IMD process handles the logic to look for existing Usage Transactions to determine if an adjustment will be required. The Usage Transaction will be moved to a "Subsequent Correction" status once this adjustment occurs.

Inventory of Other Usage Rules

Beyond validations and estimations Usage Rules, the Usage Transaction process involves many other important rules that prepare and calculate Service Quantities. A list of these rules is provided below. For additional detail, follow the provided link that will take you to the Configuration Guide.

Pre-Calculation Usage Rules

Below is a list of the pre-calculation Usage Rules provides as part of base product. For more information on how each rule executes and can be configured, follow the link provided on the rule.

VEE Rule Name

Applicable Data Type(s)

Purpose

Alignment and Delay Usage Rule

Interval or Scalar (Frequently Read)

This rule can be used to handle two main needs:

1) aligns all measuring components for a Usage Subscription to the same date (whether on the same device or separate devices)

2) delays the usage transaction until the end of the retry window based on

Check Existence of Installed Device

Interval or Scalar

This algorithm checks for the existence of a device installed on the Usage Subscription's Service Point for the usage period. In the case of multi-items this rule also checks that they are effective for the usage period.

Calculation Usage Rules

The following is a list of the calculation Usage Rules provided as part of the base product. For more information on how each rule executes and can be configured, follow the link provided on the rule.

Usage Rule Name

Applicable Data Type(s)

Purpose

Apply Math (Interval Data)

Interval

This rule is used to perform calculations on interval data and it stores the results in the usage transaction's service quantities. A variety of options are available on this rule that include defining the calculation type, variables to use, as well as the equation to use (math functions and expressions).

This rule provides aggregated usage for all selected interval measuring components (filter by TOU, SQI & UOM) associated to a usage subscription.

This rule can also multiply total usage by a factor using a custom formula.

Daily Scalar Usage Rule

Scalar

This rule is used to calculate usage of daily scalar measuring components installed in the Service Points associated with a Usage Subscription for the specified usage period. Create bill determinants by taking the difference between the beginning and ending reading for the bill period.

This rule can also be used to provide register readings by measuring component.

For consumption values, only the beginning and ending readings are exported

This rule supports date breaks (the normal Get Scalar Data rule does not).

Get Interval Data

Interval

This rule is used to get interval quantities from interval measuring components installed in the Service Points linked to the Usage Subscription for the specified 'Interval' usage period.

This rule retrieves the interval data for measuring components associated to a usage subscription by TOU, SQI and UOM.

This rule converts the interval data to another interval length or unit of measure.

Get Item Counts and Consumption

Scalar

This rule finds item-based and multi-item-based Service Points linked to the Usage Subscription for the current usage transaction, summarizes the item counts by item type and Service Point, and calculates item-based consumption.

Get Scalar Details

Scalar

This rule is used to get usage from scalar measuring components installed in the Service Points linked to the Usage Subscription for the specified 'Scalar' usage period.

This rule creates bill determinants by summing all scalar readings for the bill period. This rule can also be used to provide register readings by measuring component. All readings are exported by this rule.

Note: This rule is used for traditional monthly read meters.

Get TOU Mapped Usage

Interval

This rule is used to get time of use quantities from interval measuring components for devices installed at the Service Points linked to the Usage Subscription for the specified 'Interval' usage period.

Interval Tier Calculation

Interval

This rule calculates the difference between a source and reference vector.

This rule will loop through each tier that is configured and calculate the imbalance amount associated to that tier level.

This rule breaks down that difference into one to many positive or negative tiers, and create a service quantity for each tier calculated.

Profile Accumulation

Interval or Scalar

This rule is used to manipulate a customer's interval data by adding other vectors to it. Those other vectors are derived from a list of profile factors and corresponding characteristic values stored in a list on the usage transaction.

Round and Adjust Usage

Interval or Scalar

This rule copies identified source and target Service Quantities and inserts these as Service Quantities that are rounded and adjusted.

Vector and Service Quantity Math

Interval

This rule is designed to facilitate configuration of complex vector calculations. It is based on a series of underlying services with vectors configured as input to the calculations.

Typical uses:

Perform math using interval data, e.g., take the difference between two curves, find max values, find coincident peaks, multiply a curve by a value, apply TOU maps, etc.

Define complex formulas using various interval curves, profile factor values or calculated service quantities (bill determinant values).

Support math functions: sin, cos, square root, etc.

Store derived curves in memory that can be used in subsequent calculations

Please note, this rule is not as efficient as other rules.

Decision-making Usage Rules

There are Usage Rules delivered as part of the base product that help with decision-making when executing running the usage calculation process. For more information on how each rule executes and can be configured, follow the link provided on the rule.

Usage Rule Name

Purpose

Execute Usage Group

This rule performs a call to execute a separate Usage Group which includes execution of all Usage Rules within that group.

Exception Handler

This rule evaluates the exception list that was accumulated during the execution of the calculation rules against exception criteria configured on this rule.

Time of Use Maps

Next in This Section

- About Time-of-use Processing

- About TOU Maps

- Maintaining TOU Maps

About Time-of-use Processing

A type of rate used at many utilities is known as a "time of use" rate. For these rates, the price is based on when the usage occurs. For example, prices are typically higher during peak consumption periods (commonly referred to as "On Peak" periods) to encourage lower use during these times. The time range when a given price is applicable is known as a time-of-use (TOU) period.

Time of use periods can (and often do) change during the year. For example, in the summer, TOU periods might be defined as follows:

Time Of Use Period

Time Periods

On Peak

8:00 AM - 9:00 PM Monday - Friday

Off Peak

12:00 AM - 8:00 AM Monday - Friday

9:00 PM - 12:00 AM Monday - Friday

12:00 AM - 12:00 AM Saturday, Sunday, and Holidays

While winter TOU periods might be defined as follows:

Time Of Use Period

Time Periods

On Peak

11:00 AM - 5:00 PM Monday - Friday

Off Peak

12:00 AM - 11:00 AM Monday - Friday

5:00 PM - 12:00 AM Monday - Friday

12:00 AM - 12:00 AM Saturday, Sunday, and Holidays

This is an example of a "simple" mass-market time-of-use schedule. Commercial and industrial schedules can be much more complex.

Generally speaking, there are two different types of meters that can be installed at service points that participate in TOU rates:

Scalar meters with dedicated registers for each TOU period. For this type of meter, the scalar measurements are the TOU consumption and no special derivation is necessary. The assumption is that the TOU schedule is programmed into the device and no TOU Map is required within Oracle Utilities Meter Data Management.

Interval meters that measure how much is consumed each interval. For this type of meter, the interval measurements are used to derive the consumption in each TOU period based on the TOU Map defined in Oracle Utilities Meter Data Management.

For information on configuration, reference the related section for TOU Mapping in the Administration Guide.

About TOU Maps

Interval consumption is mapped into time-of-use periods using a TOU map. TOU maps define the TOU periods for each interval. TOU map data is structured in a format very similar to final measurement data, with specified intervals of time each designated to a TOU period (instead of a measurement value). For example, the table below lists a set of TOU map data and corresponding final measurements for a period of 4 hours on January 1, 2010.

TOU Map

Measuring Component

Date/Time

TOU Code

Date/Time

Consumption

1-Jan-10 3:00pm

ONPEAK

1-Jan-10 3:00pm

14.678

1-Jan-10 4:00pm

ONPEAK

1-Jan-10 4:00pm

29.12

1-Jan-10 5:00pm

ONPEAK

1-Jan-10 5:00pm

12.12

1-Jan-10 6:00pm

OFFPEAK

1-Jan-10 6:00pm

17.16

Any type of final measurement can be mapped to a TOU period, including derived quantities. While the principal requirement for TOU Maps is to aggregate interval consumption into TOU periods for a Usage Transaction, the system has many zones in the user interface that display interval consumption using TOU periods.

Maintaining TOU Maps

This portal is used to display and maintain a TOU Map.

Refer to About TOU Maps for additional functional information.

You can access the portal from the Main > Usage > TOU Map. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- TOU Map: Defines basic information about the TOU map, including dynamic options

- TOU Map Data List: Lists TOU map data created from the TOU map

The Time Of Use Map Data Generation Monitor batch (D1-TOUTR) is used to generate TOU Map data automatically based on the TOU Configuration. TOU Map data can also be generated manually through the TOU Map Portal in the UI.

Dynamic Options

Next in This Section

- About Dynamic Options

- About Dynamic Option Events

- Maintaining Dynamic Options

- Maintaining Dynamic Option Events

About Dynamic Options

Dynamic Options specify terms that override how usage is normally calculated, such as a critical peak period that affects the TOU mapping of interval consumption.

There are circumstances and conditions during which the rules for creating TOU map data might need to be calculated differently than according to the utility's standard rules. Examples of this might include critical peak periods, curtailment requests or other demand response events. During these types of events, the TOU rules defined for a TOU map may be overridden. This is done through the use of dynamic options and dynamic option events.

Dynamic options allow flexibility for ad-hoc and special events that might impact how usage calculations are performed. For example, if a utility requests that its customers curtail their usage for a specific time period, a dynamic option and corresponding dynamic option event could be used to represent the curtailment request. During the time period of the curtailment request, usage might be calculated differently (with a different set of TOU periods, for example), which in turn might impact how the customer's bill is calculated.

Dynamic Options and TOU Maps

To apply a dynamic option (and one or more of its related dynamic option events), you reference the dynamic option on a TOU map, along with a corresponding "dynamic" TOU map to be used during the dynamic option event.

For example, with Critical Peak Periods you might add a new TOU period (called "Critical Peak"), and create a new TOU map that is the same as your standard TOU map, but that also includes your Critical Peak TOU period. For example, in the summer your new set of TOU periods might be defined as follows:

Time Of Use Period

Time Periods

Critical Peak

10:00 AM - 2:00 PM Monday - Friday

On Peak

8:00 AM - 10:00 AM Monday - Friday

2:00 PM - 9:00 PM Monday - Friday

Off Peak

12:00 AM - 8:00 AM Monday - Friday

9:00 PM - 12:00 AM Monday - Friday

12:00 AM - 12:00 AM Saturday, Sunday, and Holidays

If a dynamic option event occurs during a usage transaction period, the standard TOU map is overridden with the "dynamic" TOU map. In our example, a usage transaction period that includes August would use the dynamic TOU map when generating TOU map data for the time between 10:00 AM and 2:00 PM on August 2, but would use its standard TOU map for the rest of the month.

About Dynamic Option Events

Dynamic Option Events are specific periods of time during which a dynamic option is applicable.

There are circumstances and conditions during which the rules for creating TOU map data might need to be calculated differently than according to the utility's standard rules. Examples of this might include critical peak periods, curtailment requests or other demand response events. During these types of events, the TOU rules defined for a TOU map may be overridden. This is done through the use of dynamic options and dynamic option events.

A dynamic option may have many dynamic option events over time.

Maintaining Dynamic Options

This portal is used to display and maintain a Dynamic Option.

Refer to About Dynamic Options for additional functional information.

You can access the portal from the Main > Usage > Dynamic Option. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Dynamic Option: defines the basic information about a Dynamic Option.

- Dynamic Option Event List: provides a list of the Dynamic Option Events that have been created for this Dynamic Option.

Maintaining Dynamic Option Events

This portal is used to display and maintain a Dynamic Option Event.

Refer to About Dynamic Option Events for additional functional information.

You can access the portal from the Main > Usage > Dynamic Option Event. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zone may appear as part of the portal's Main tab page:

- Dynamic Option Event: defines the basic information about a Dynamic Option Event.

Consumption Extract Requests

Next in This Section

- About Consumption Extract Requests

- Maintaining Consumption Extract Requests

About Consumption Extract Requests

Consumption Extract Requests are created every time interval data is extracted for Oracle Utilities DataConnect. The consumption extract request can be created manually, typically to initiate an initial load type of extract, or created automatically, typically for an incremental type of extract, based on a configuration on the consumption extract type.

The Consumption Extract Request is responsible for submitting and monitoring the actual batch jobs that perform the data extract. In addition, it can be used to store any additional filters to further trim down data that will be extracted.

Refer to the Oracle Utilities DataConnect integration section for more details on how this object is specifically put into use.

Maintaining Consumption Extract Requests

This portal is used to display and maintain a Consumption Extract Requests.

Refer to About Consumption Extract Requests for additional functional information.

You can access the portal from the Main > Usage > Consumption Extract Requests. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Request: displays the main attributes of a Consumption Extract Request.

- Request Log: displays all log information related to the Consumption Extract Request.

Contacts

Next in This Section

- About Contacts

- Maintaining Contacts

About Contacts

Contacts are individuals or business entities with which a company has contact. Service Points can have associated contacts which define the individual or business entity that uses the service (electricity, gas, water, etc.) delivered at the Service Point. A contact is optional for Service Points, but Usage Subscriptions must reference contacts.

Note: The base-package name search on the 360 Degree Search looks for Usage Subscription-related contacts. Use the Service Point Query portal to find a Service Point using a Service Point-related contact.

Maintaining Contacts

This portal is used to display and maintain a Contact.

Refer to About Contacts for additional functional information.

You can access the portal from the Main > Usage > Contact. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Contact: defines the basic attributes of the contact

Communications

Next in This Section

- Device Events

- Activities

- Communications

- Completion Events

- Notification Suppressions

Device Events

Next in This Section

- About Device Events

- Processing Device Events

About Device Events

Device events are developments that have taken place relative to a device, and can include power outages, power restorations, tampering alerts, command completions, among others.

Attributes used to define device events include the following:

- Device Event Date/Time: the date and time of the event. This date/time is flexible in its interpretation. For single events it is the moment the event took place. For events that are paired, like a power up and a power down, it will represent the start of the event when received with the first of the pair and the end of the event when received with the second of the pair. For an event that includes the duration, where the device event end date/time is also supplied, this date/time represents the start date/time.

- Device Event End Date/Time: the end date and time of events with durations. This will only be populated if the device event date/time is also populated.

- In addition, device events also reference details specific to the head-end system that sent the event, including the following:

- Sender: the head-end system (defined as a service provider in Oracle Utilities Smart Grid Gateway) from which the event was sent.

- External Sender ID: the external ID for the head-end system that sent the event.

- External Event Name: the external, head-end-specific name for the event. This name is translated into a "standard" event name within Oracle Utilities Smart Grid Gateway.

- External Source Identifier: an identifier for the source of the event.

Standard Event Names

When the system is loading a device event, it first determines which head-end system sent it, and then determines which device produced it. The system then maps the device event name sent by the head-end system to a standard event name that corresponds to the event. Standard event names are beneficial because the event names sent by head-end systems vary, even when the events are essentially the same. What one head-end system calls "Primary Power Down," another system may call "Last Gasp." Creating a standard event name, such as "Power Outage - Device," makes it easier to send the device events to an external system such as Oracle Utilities Network Management System. In this way, the external systems that receive the events do not need to be configured to accept all of the possible names for a single type of event.

Refer to Understanding Device Event Types for additional information about how the device events are mapped using standard event names.

Processing Device Events

Device Events received from external systems are processed through two major stages:

- Device Event Seeder: This is the common interface point that receives all device event information and performs critical validations and conversions. During this process the device event seeder identifies the appropriate specific device event business object for further processing. The choice is made based on the originating external system and the type of event being received. For example, a device event for a "Last Gasp" would result in the paired event first device event being selected.

- If for some reason the device event seeder encounters an error an instance of the device event eeder will be created to manage the resolution of that error.

- Specific Device Event: Each specific device event has the appropriate logic for the type of event that has been received. A tamper event might create a service issue monitor while a "Last Gasp" might create an outage activity.

Device Event Seeder Processing

The device event seeder receives device event data in a common structure, however, the content of the data (identifiers, date/times, etc) can vary depending on the system and the particular device that generated it. To accurately translate the external content to values understood by the system the device event seeder leverages the configuration of the service provider (aka head end or external system) and the device.

The service provider specifies the following inputs into device event seeder processing:

- Identifier Types: Each device event must identify the device the event has been generated from. The system supports a multitude of identifiers for the device. The service provider configuration specifies which identifier type is used for the device which enables the device event seeder to search for the correct destination for the device event. For example, a service provider might indicate that devices are identified by a serial number.

- Date/Time Format: The service provider configuration will identify whether the date/times that were sent included specific time zone designations. This allows the system to accurately handle any time zone conversions that may be necessary.

- Processing Methods: A service provider has the following processing methods that are used in the evaluation of the device event:

- Device Event Mapping - Maps a given external device event name to a standard event name. That standard event name is eventually used to identify the appropriate device event for specific processing.

- Time Zone Translation - Identifies the extendable lookup to be used in mapping the service provider specific time zone to the interval time zone.

The device specifies the following inputs into IMD Seeder processing:

- Incoming Data Shift: This value is either specified directly on the device or can be defaulted via fallback on the device type. It identifies whether the incoming date/time information has is "Shifted" meaning it has been adjusted for Daylight Savings Time (DST) when in effect, or it is "Not Shifted" which means it will never be adjusted for DST. This plays an important role in the date/time processing since all incoming device event date/times will be stored without an adjustment for DST.

With these inputs the device event seeder is able to translate the external identifiers into the appropriate identifiers to tie the device event to the originating device in the system..

Device Event Seeder Critical Validations

For device events to continue on to specific device event processing they must pass the critical validations:

- The device must be identified.

- The device event must have an event date/time.

If either of the critical validations fails the device event processing will be halted and an instance of the device event seeder will be created

Note: There is special logic that exists for handling the situation where either the device event date/time or the device event end date/time falls on the duplicate hour that occurs when a time zone transitions out of daylight savings time.

Device Event Seeder Time Zone Translation and Conversion

To provide the most accurate tracking of device events all device event data is stored in a single time zone without an adjustment for Daylight Savings Time (DST). As utilities can have multiple head end systems that each send date/time information in different ways and some utilities operate in multiple time zones the device event seeder contains functionality to convert incoming date/times from a source time zone into the time zone of Oracle Utilities Meter Data Management (as indicated by the base time zone)

There are three components to identifying the source time zone of the incoming device event:

- Service Provider IMD Import Date/Time Format: When the device event date/times are sent in a format that identifies the time zone for each date/time the date/times will be delivered to the device event seeder already converted.

- Incoming Data Shift: This indicates whether the date/times will be adjusted for DST while it is in effect. A value of "Always in Local Time" indicates that the date/times are adjusted for DST. A value of "Always in Standard Time" indicates that the date/times are not adjusted for DST

- Time Zone: The time zone of the incoming data is identified using the follow order of precedence:

1. The time zone as indicated by the device event data

2. The service point time zone

3. The device configuration time zone

4. The base time zone

Once the time zone and the data shift of the incoming date/times is identified all date/times will be converted from that time zone and shift into the base time zone in standard time.

Specific Device Event Processing

Types of Device Events

Standard

Momentary device events, such as a tamper alert, are processed using the standard device event. These device events do not provide any special processing.

Paired Device Events

Device events with a duration are defined using paired event device events: paired event first and paired event last. With the first of the pair representing the start of the event, and the last of the pair representing the end of the event. Events of this type can be configured to create or complete activities that represent the event. For example, a "Last Gasp" event might create an outage activity that is completed when "Power Restoration" event is received.

When pairs of events arrive in rapid succession (such as a last gasp followed quickly by a power restoration), these "paired event" business objects are designed to prevent them from being sent to subscribing applications.

Communication Response

The communication response is a special type of event used for head end systems that respond to smart meter commands with device events. When received these events create a communication in that will initiate the completion of the originating smart meter command.

Refer to About Communication In for more information on a communication in.

Sending Device Events to Subscribing Systems

When device events are received, they are typically passed onto to another subscribing system, such as Oracle Utilities Meter Data Management, a customer information system (such as Oracle Utilities Customer Care and Billing), an outage system (such as Oracle Utilities Network Management System), or some other application.

The means of sending device event information to subscribing system is defined in the "How to Send Device Event Related Information" processing method for the service provider representing the subscribing system. Device event information can be sent via outbound communication business object, outbound communication, or batch process.

The method for sending device events to subscribing systems (business object, outbound message, or batch process) can be defined for each device event category, and can be overridden for individual device event types (including the ability to exclude specific device event types within a category. In addition, a default event processing method can be also be configured that applies when methods of transmission aren't specified at the individual category level.

The "Subscribe to Device Event" business service is used to process device event subscription requests, and allow external applications to manage the categories of events they receive.

Refer to About Device Event Notification Suppressions for more information on a suppression device event notifications.

Creating Service Issue Monitors and Service Investigative Orders

Device events can be configured to create service issue monitors and service investigative orders. The service issue monitor type to create is defined on the device event type. When a device event is received, an Enter algorithm on the device event's Processed state creates the service issue monitor, based on the Service Issue Monitor Type specified for the device event type.

Refer to Understanding Service Task Types for more information on configuring service issue monitor types.

Device Event Prioritization

By default, device events are created and/or received into the system in an initial state is "Pending" and are transitioned to subsequent states via the batch processing. This batch processing can be skipped by setting the Execution Method flag on the device event to "Real Time" (D1RT), in which case an Enter algorithm transitions the device event to the next state in its lifecycle immediately. This feature can be used to prioritize processing of certain types of device events.

The Execution Method flag can be set in in unsolicited device events sent from the head-end system, or can be inserted during Oracle Utilities Smart Grid Gateway Adapter processing.

Oracle Utilities Smart Grid Gateway Adapters set this flag to "Real Time" on all device events created as the result of smart meter commands.

Activities

Next in This Section

- About Activities

- Maintaining Activities

About Activities

Activities cover a range of functional process within the system from smart meter commands, synchronization of consumption between related measuring components, service order management activities, and statistics and aggregations.

The table below provides the full list of activity type categories supported and a brief description of how they are used:

Activity Type Category

Activities of this type category are used to

Bulk Activity

Initiate a smart meter command for a group of meters using Oracle Utilities Smart Grid Gateway

Command Request

Initiate a smart meter command for an individual meter using Oracle Utilities Smart Grid Gateway

Consumption Sync

Trigger related measuring component estimation synchronization

Device Event Activity

Represent a device event. These are used when viewing usage and events with the Oracle Utilities Meter Data Management 360 Degree View.

Dimension Scanner

Trigger dimension scanning when aggregating usage, statistics, and other data.

Error Activity

Represent errors in activity processing.

Extract Request

Retrieve usage and device events from a head-end system using Oracle Utilities Smart Grid Gateway

Field Activity

Initiate field work via a message to a field work external system, such as Oracle Utilities Mobile Workforce Management. Activities of this type are most often created by a request orchestration activity.

Meter Read Download Activity

Download a list of meters to be read.

Multi Device Command Request

Initiate a smart meter command for multiple meters (for head-end systems that support multi-device commands) using Oracle Utilities Smart Grid Gateway

Non-Dispatchable Activity

Represent steps or stages in a larger process in which the system is waiting for a resolution from another system. Examples include "Wait for Measurement" or "Wait for Scheduled Read."

Orchestration Maintenance

Update or cancel an active service order activity.

Payload Statistics

Calculate processing statistics for usage and device event import processing

Request Orchestration

Orchestrate the steps necessary to fulfill a service request, based on the current state of the service point related to the request.

Suppression

Suppress sending of device events to subscribing systems (such as Oracle Utilities Network Management System)

Usage Transaction Correction Processor

Trigger correction processing for usage transactions when corrected usage is received that would impact an existing usage transaction

Maintaining Activities

The Activity portal is used to maintain activities.

Refer to About Activities for additional functional information.

You can access the portal from the Main > Communication > Activity. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

This portal includes the following zones:

- Activity: defines the basic attributes of the Activity

- Activity Hierarchy: a tree that displays the activity and related activities (including field activities and smart meter commands), inbound and outbound communications, and completion events.

Communications

Next in This Section

- About Communication Out

- About Communication In

- Maintaining Communications

About Communication Out

These transactions are typically created from an activity and are tasked with sending a message to an external system. They follow one of two communication patterns:

- Two-way: these messages are sent to the external system without an expectation of an immediate response, or a response is received but it is only an acknowledgement of a successful receipt of the message. The true response to the message is expected to be received in a process detached from the communication out. For the full lifecycle of the communication to be complete a communication in must be received.

- One-way: these messages are sent to the external system and responded to in full within a single transaction. No communication in will be received.

The format of the message sent to the external system is typically driven by a processing method for that external system and the transportation method is controlled by the external system's message options.

If an error is encountered sending the message to the external system the communication out can perform automated retry of the messages for a configurable rate of retry and number of retry attempts.

For one-way communications the communication out will be responsible for creating the completion event.

Once the message has been communicated and a response received the outbound communication will update the initiating activity with the result.

Note:
Refer to the following topics for additional information on communications functionality:

- Understanding Processing Methods for additional information on how processing methods are configured.

- See About Completion Events for details on completion events.

- See External Systems in the Oracle Utilities Application Framework Administrative User Guide for additioal information on configuring communication between your system and external systems.

About Communication In

These transactions represent a message sent from an external system and are received in two situations:

- In response to a communication that had been sent to the external system. This is the most common usage of the communication in.

- An unsolicited message received from an external system such as a real time event. Note: this is not a common pattern.

- Upon receipt the communication in will link itself to the communication out that initiated it. The response message will then be validated to ensure that it is technically and functionally correct.

- For many smart meter commands and field activities executed by service order management the communication in is responsible for creating the appropriate completion events. For example, if the response was for the On Demand Read smart meter command a completion event will be created that will generate the appropriate initial measurement data.

- Similar to the communication out a communication in that encounters an error can perform an automated retry with a configurable rate of retry and number of retry attempts.

Maintaining Communications

The Communication portal is used to maintain communication in and communication out records.

Refer to About Communication Out and About Communication In for additional functional information.

You can access the portal from the Main > Communication > Communication. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

This portal includes the following zones:

- Communication: defines the basic attributes of the Communication

- Communication Hierarchy: a tree that displays the communication and related activities (including field activities and smart meter commands), inbound and outbound communications, and completion events.

Completion Events

Next in This Section

- About Completion Events

- Maintaining Completion Events

About Completion Events

Completion events are used to implement the outcome of an activity. They are created by either the communication out (for one-way communication) or the communication in (for two-way communication). Completion events are executed by the activity orchestrating the communication with the external system.

Some examples of the tasks a completion event will perform are:

- Commissioning, decommissioning, connecting, disconnecting a smart meter

- Installing or Removing a meter or item

- Creating initial measurement data

- Updating a device or service point

Maintaining Completion Events

The Completion Event portal is used to maintain completion events.

Refer to About Completion Events additional functional information.

You can access the portal from the Main > Communication > Completion Event. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

This portal includes the following zones:

- Completion Event: defines the basic attributes of the Completion Event

- Completion Event Related Objects: displays data related to the completion event such as a device, service point, or initial measurement.

Notification Suppressions

Next in This Section

- About Device Event Notification Suppressions

- Maintaining Notification Suppressions

About Device Event Notification Suppressions

When a device event is processed by the system it can be sent to one or many external applications interested in being notified about the event. A prime example of this is the Outage Management System subscribing to any device events related to a meter either losing power or regaining power.

There are situations, such as a field worker performing maintenance on a meter or on a node that impacts many meters, that will result in a large amount of device events being created, processed, and distributed to subscribers.

Device event notification suppressions provides a way for a subscribing system, in anticipation of scheduled maintenance, to suppress notification of certain device events (power down, power up, tamper, etc) from one or more meters.

Maintaining Notification Suppressions

The Activity portal is used to maintain notification suppressions records.

Refer to About Device Event Notification Suppressions for additional functional information.

You can access the portal from the Main > Communication > Notification Suppression. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

This portal includes the following zones:

- Activity: defines the basic attributes of the Notification Suppression

Integrations

Next in This Section

- Business Flags

Business Flags

Next in This Section

- About Business Flags

- Maintaining Business Flags

About Business Flags

Business flags provide a view into the status of a service point across applications (e.g. Oracle Utilities Meter Data Management, Oracle Utilities DataRaker, Oracle Utilities Customer Care and Billing). Business flags are currently available in two forms:

- Service Point Business Flags: are often informational in nature but also allow for manual investigation to be taken.

- Service Point Monitor Business Flags: are seen as symptomatic of an issue that needs to be investigated. These business flags feed into a service issue monitor and may result in a service investigative order being created.

For additional details see About Business Flags in the Oracle Utilities Application Framework Administrative User Guide.

Business Flag Allowed Actions

Allowed actions are implemented presented to the user as selectable options that will guide the user through a particular method of investigating or resolving the business flag. The following actions are supported:

- Create Field Activity: This will initiate a field activity associated to the business flag's service point. The type of field task will be selected by the user. Note: this option requires Oracle Utilities Service Order Management.

- Request Customer Notification: This will initiate a message to the appropriate external system (e.g. Oracle Utilities Customer Care and Billing) that will identify a notification to be sent to the customer. The type of communication will be determined by the notification type selected by the user.

Note: not all business flags support allowed actions and not all business flags that support allowed actions support all allowed actions.

Maintaining Business Flags

Information for this functionality is available in the Business Flags section in the Oracle Utilities Application Framework Administrative User Guide.

Aggregations

Next in This Section

- About Aggregations

- Creating Aggregators

- Base Product Aggregators

- Maintaining Aggregations

About Aggregations

Aggregations are measurements that represent a summarization of other measurements from a set of devices, items, and/or measuring components. For example, an aggregation may be based on the sum of the electric consumption of all residential customers in a particular postal code within the utility's service territory. The group of related measuring components for which measurements are summarized are referred to as constituent measuring components.

Every type of aggregation has one or more dimensions. For example, an aggregation might be defined with three dimensions as follows:

- Substation

- Feeder

- Transformer

Aggregations are defined by aggregator measuring components. A separate aggregator measuring component should be defined for every distinct combination of dimensions for a given type of aggregation. For example, the transformer aggregation described above would require an aggregator measuring component for every distinct combination of substation / feeder / transformer found among the electric Service Points.

Aggregations can also be aggregated. For example, the aggregator measuring components for each substation / feeder / transformer combination can in turn be used to aggregate consumption at each substation / feeder combination. In this case, a distinct aggregator measuring component would be defined for each unique substation / feeder combination. Likewise, the aggregator measuring components for each substation / feeder combination could be used to aggregate consumption at each substation, in which case, distinct aggregator measuring components would be defined for every unique substation. Finally, the aggregator measuring components for each substation can be used to aggregate total consumption for all substations, with an aggregator measuring component defined to represent the entire service area.

Aggregation Calculations

The system periodically aggregates consumption via batch process, using a deferred monitor on the aggregator measuring components. In addition, users can re-aggregate data in real-time if they don't wish to wait for the batch process, or if the original aggregation needs to be re-calculated due to incorrect data. Users can also create ad hoc aggregations "on the fly" and these will persist in the database in the same manner as other aggregations.

Understanding Aggregation Periods

The start and end dates and times for aggregation calculations are based on the following:

- Aggregation Horizon

- Aggregation Lag

- Aggregation Cut Off Time

Whenever aggregation is performed for an aggregator measuring component, consumption is aggregated for every day in its "Aggregation Horizon." The "Aggregation Horizon" is the number of days during which there's a potential change in measurement data for one or more of the measuring components associated an aggregator measuring component.

Aggregation calculations typically lag behind the current date by a few days to give the system time to upload and perform validations and create final measurements. The amount of lag time is referred to as the "Aggregation Lag" and is the number of days between the date on which aggregation calculations are performed and the end date of the aggregation period. This defines the time period between the aggregation calculation date and the end of the aggregation horizon that serves to allow all measurements to arrive. This together with the Aggregation Horizon is used to determine the start and end dates of an aggregation period. For example, with an Aggregation Horizon of 5 and an Aggregation Lag of 2, aggregation calculations performed on January 9 would be for an aggregation period of January 3 through January 7. The next day (January 10), the aggregation period would shift to January 4 through January 8.

Aggregation is always performed through a given "through time" (such as 12:00 AM) rather than through the actual time of the aggregation calculation. This time is referred to as the "Aggregation Cut Off Time." For example, the stop time for aggregation calculations with an Aggregation Lag of 2, and an Aggregation Cut Off Time of 10:00 PM will always be 10:00 PM 2 days prior to the date on which the calculations are performed. In the above examples, aggregations performed on January 9 would have an end date/time of 10:00 PM on January 7, and aggregations performed on January 10 would have an end date/time of 10:00 PM on January 8.

Aggregation and Re-Aggregation

The use of the aggregation horizon means that aggregated totals for some days will be re- aggregated until those days are no longer covered by the aggregation horizon. For example, with an aggregation horizon of 5 days and an aggregation lag of 2 days, on the night of January 9 the aggregation period would be January 3 through January 7 (as in the above example).

On the night of January 10, the horizon will shift 1 day (to January 4 through January 10, again as above). This means the following:

- The totals for January 3 calculated on January 9 will be untouched (January 3 now falls outside the aggregation horizon)

- The totals for January 4 through January 7 will be re-derived because corrections may have occurred (and they still fall within the aggregation horizon)

- The totals for January 8 will be calculated for the first time (because it now is within the aggregation horizon).

Manually Read Meters and Aggregation Lag

Aggregations that include manually read meters often have much longer aggregation lags than those for automatically read meters. This allows more time for manual meter readings to be imported into the system for use in aggregations.

For example, suppose a situation where manual meter reads arrive approximately 1 month after the date of the reading. In this case, it wouldn't be until a meter read upload on February 7 that the last manual reads including consumption from January 6 will exist. Since we don't want to perform aggregations for January 6 until there's a decent chance that all consumption for that date exists, an aggregation lag of 32 days ensures that the data for January 6 is in the system when the aggregation is performed on February 7.

When An Aggregator Measuring Component Contains Both Manual and AMI Measuring Components

The previous section suggests that if an aggregator measuring component contains both manually read and AMI measuring components, the aggregator measuring component should have a long lag time rather than the short time shown in the earlier example.

While this is one possible approach, an alternative approach could allow users to see timely aggregations of the AMI channels and only lag the manual channels. To do this they could configure the system as follows:

- Create an aggregator measuring component that only aggregates manual measuring component types (horizon: 5 days, lag: 31 days)

- Create a separate aggregator measuring component that only aggregates interval measuring component type: 5 days types (horizon: 5 days, lag: 2 days)

- Create a third aggregator measuring component that aggregates the above aggregator measuring component types (horizon: 5 days, lag 31 days)

Expanding The Aggregation Horizon Periodically

Even with a 30-ish day aggregation lag, it's possible for an account with several months of estimated consumption to have its consumption "invalidated" when real readings arrive whose dial readings are less than the estimated readings (or when major retroactive data change takes place). Another similar situation is when a user manually corrects consumption after the aggregation horizon has moved forward.

To address situations like these, the use of ad-hoc aggregations with a user-specified aggregation horizon supports the notion of periodically (such as once a month or once a week) aggregating with a long aggregation horizon (up to 90 days) to catch as many retroactive changes as possible.

A Note About Using Non-Effective Dated Dimensions

Be aware that whenever aggregation takes place, the system uses master data that exists as of that date. For example, if an aggregation is performed using non effective-dated master data attributes (for example, aggregating by measuring component type) and a measuring component's type is changed, all days in the aggregation horizon will reflect the change regardless of when the user makes the change, because the measuring component type relationship is not effective-dated.

The impact of this depends on the nature of the change:

- If the master data was wrong, this provides a way to re-aggregate the data to accurately reflect the master data.

- If the change occurred effective as of a given date (but there's no effective dated attribute), this can result in incorrect aggregation values.

Because of this, it is recommended that where possible dimensions used in aggregations be effective-dated.

For information on configuration, reference the related section for Aggregations in the Administration Guide.

Creating Aggregators

There are two ways in which aggregator measuring components are created:

- Automatically: The system will periodically create new aggregator measuring components when new "dimensional values" are detected. For example, if a new substation is added to the system, a new aggregator measuring component will be created for the substation.

- Manually: An end-user can create an aggregator measuring component at their discretion

Automatic Creation of Aggregator Measuring Components

The system automatically creates aggregator measuring components when it detects new instances of the dimension(s) being aggregated. This activity is referred to as dimension scanning. For example, if the system is configured to aggregate individual substations, a user will NOT have to manually set up an aggregator measuring component when a new substation if referenced on a service point. Rather, the system will create the new aggregator when it detects a substation on a service point that doesn't have an aggregator measuring component.

Similarly, if is configured to aggregate distinct combinations of rate class (on usage subscription type) and postal code (on service point), the system will create an aggregator measuring component when it detects new combinations of rate class and postal code.

The periodic monitoring to ensure sufficient aggregation measuring components exist is implemented via monitoring algorithms on a related activity business object that references a corresponding measuring component type. This means that there must be a separate activity type / activity combination for every type of aggregation performed. These monitor algorithms include:

- A Monitor algorithm on the Active state that simply transitions the activity to the transitory Scan state. Users can manually transition the activity to the Scan state by clicking the "Scan" button on the activity.

- An Enter algorithm on the Scan state finds the distinct combinations of dimensional values for this type of aggregation and checks that an aggregator measuring component that references the activity's aggregator measuring component type exists for every instance and creates new aggregator measuring components as appropriate. The algorithm also populates the dimensional values on the new measuring components (mapped to searchable characteristics), and sets the Consumption Aggregated Through Date/Time field on the new aggregator measuring components to the current date and the Aggregation Cut Off Time on the aggregator measuring component type.

Hard-Wiring Service Types for Aggregations

If the dimensions used for aggregation do not include at least one service type-specific dimension (for example, in the case of aggregating by postal code only) AND the aggregation should not commingle measurements of different service types, it's important to:

- Declare the specific service type for the aggregation on the dimension scanner activity instance

- Declare the desired service type-specific measuring component types on the aggregator measuring component type

For example, if an electric and gas implementation aggregates consumption by postal code, they will need 2 activities: one will reference the Electric service type and the desired aggregator measuring component type, the other will reference the Gas service type and its aggregator measuring component type. The aggregator measuring components will have two dimensional attributes: postal code and service type.

Manual Creation Of Aggregator Measuring Components

Users can also create aggregator measuring component manually. This is useful when an ad hoc aggregation for an ad hoc time period is required, or when there is no activity that automatically creates instances of a given combination of dimensions. To do this, the user simply clicks the "Add" link on the Aggregator Search zone title bar. The BPA script:

- Prompts the user to define the type of aggregation (this will present a list of measuring component types whose measuring component category is aggregator)

- Prompts the user to define the dimensional value(s), the desired aggregation time, and if this aggregation should be performed indefinitely or if it is a "one time"

Base Product Aggregators

A number of standard aggregation processes are delivered as part of the base product. These provide a means of aggregating measurement data by postal code and service type for both physical meters and items.

Aggregator Name

Description

Aggregator - Postal and Service Type

Aggregates measurement quantities for constituent measuring components from physical meter based on postal code and service type dimensions.

Item Aggregator - Postal and Service Type

Aggregates measurement quantities for constituent measuring component from items based on postal code and service type dimensions.

Other aggregators shown below are delivered for use by Oracle Utilities Analytics. These aggregate measurement data (including quantities and counts) for constituent measuring components based on the following dimensions: Postal, City, Head-End, Device Type, Usage Calculation Group, Market and Service Provider, and Service Type.

Aggregator Name

Description

Measurement Measured Quantity Aggregator

Aggregates measurement quantities and distributes the constituents' measurements across Value Identifiers based on condition codes.

Measurement Quality Count Aggregator

Aggregates measurement counts and distributes the constituents' counts across Value Identifiers based on condition codes.

Measurement Timeliness Count Aggregator

Aggregates measurement counts that arrived on time or are late.

Measurement Timeliness Quantity Aggregator

Aggregates measurement quantities that arrived on time or are late.

Maintaining Aggregations

This portal is used to display and maintain Aggregations.

Refer to About Aggregations for additional functional information.

You can access the portal from the Main > Totals and Trends > Consumption Statistics. You are brought to a query portal with options for searching. Once your record has been selected you are brought to the maintenance portal to view and maintain the selected record.

The following zones may appear as part of the portal's Main tab page:

- Measuring Component: defines the basic attributes of the aggregator measuring component.

- Measurements: displays aggregated measurement data for the selected aggregator measuring component.

- Interval - Audit View: allows users to view an interval measurement curve for a given period overlaid with the count of audit records for each individual measurement.

- Final Values Overlay: displays final measurements for a measuring component, and provides the ability to overlay the graphed data with final measurements from other measuring components.

- Time of Use Overlay: displays an overlay of the TOU periods on a final interval measurement along with totalized TOUconsumption based on a user-defined time period and TOU map

A few functions are available in many of these zones that allow you to interact with the measurement data. For more information of these functions refer to the Applying Measurement Functions section.

Master Data Sync

The synchronization of master data into Oracle Utilities Meter Data Management is covered in detail in the Integrations section of the Oracle Utilities Meter Data Management / Smart Grid Gateway Administrative User Guide.

Outage Storm Mode

Next in This Section

- About Outage Storm Mode

- Reviewing Widespread Outages

About Outage Storm Mode

Unfortunately, utilities and their customers are often subject to natural disasters that cause disruptions to AMI networks. These outage events can be related to hurricanes, tornadoes, ice storms, earthquakes, tsunamis, etc. During these severe outages, AMI systems do not always provide outage and restoration events from the devices. Without these outage and restoration events, Oracle Utilities Meter Data Management processes could estimate measurements that would be billed by the CIS. This will lead to unhappy customers, potentially bad press, and lots of manual cleanup work after the fact.

While this is a problem for major outage events, this can also occur with smaller outages (smaller blackouts, planned outages, etc.). This can potentially become an issue anytime the AMI network has a significant number of devices failing to communicate.

This module includes outage processing to improve estimation accuracy during major outages. The system will automatically stop estimations when the number of meter readings coming is less than a user defined tolerance. This tolerance is based on a significant drop in the read percentage for all devices in a similar postal code, service type, and Head End. Estimations will automatically resume when the device returns to normal operation. This can occur through a number of actions: read percentage for the surrounding area returns to normal, regular data is received from the device, or a power restoration device event is received from the device.

Oracle Utilities Meter Data Management also includes the ability to manually override "storm mode". This override will allow estimations to resume even if the outage hasn't been fully resolved. This will be useful if network fixes take too long and the utility has decided that customers should be billed on an estimate after a few days pass.

Note: For information on configuration, reference the related section for Outage Storm Mode in the Administration Guide.

The diagram below illustrates the primary flow for Outage Storm Mode processing. The steps include:

1. The Dimension Scanner batch (D1-ADS) monitors the Meter Communication Tracking Dimension Scanner business object. New Aggregator Measuring Components will be created for every applicable Service Type, Postal Code, and Head End in the system.

2. The Aggregation Monitor batch (D2-AGG) runs to execute the logic for the Meter Communication Tracking Aggregator Measuring Component. This logic will aggregate all meters for the defined Service Type, Postal Code, and Head End. Once the read percentage is found for that day then a measurement will be created for the Aggregator Measuring Component.

3. The Widespread Outage batch (D2-WSO) runs to determine if any of the "Meter Communication Tracking Aggregator" Measuring Components have dropped below the defined threshold on the MDM Master Configuration. If it has dropped enough, then an Estimation Suppression Activity is created for each of the affected Service Points and the "Meter Communication Tracking Aggregator" Measuring Component is set to an "Active Outage" indicator.

4. If the Smart Meter Monitor batch (D1-SMMTR) runs to generate estimates while an Estimation Suppression Activity is active for a Service Point, then the Service Point will either be skipped for estimation or will have zero consumption filled for all data with a condition code of "No Read - Outage Fill".

5. There are a number of methods available to resume normal operation and close out the Estimation Suppression Activity. These include the following:

1. The read percentage reaches a "normal level" again as defined in the MDM Master Configuration. This will be detected by the Widespread Outage batch (D2-WSO).

2. When non-estimated data is received from a device, this will close out an open Estimation Suppression Activity.

3. If the Standard Event Name Extendable Lookup is configured with the End Estimation Suppression algorithm (D2-EN-ESTSUP), then any Power Up event this is configured for will close out an open Estimation Suppression Activity.

4. Estimation Suppression Activities can also be closed manually be a user by navigating to the Activity, using the "Edit" button", and add an End Date.

6. The Estimation Suppression Monitor batch (D2-ESTSU) runs for all Estimation Suppression Activities to determine if the related "Meter Communication Tracking Aggregator" Measuring Component is no longer in a state of "Active Outage". If the widespread outage has ended, then the Estimation Suppression activity will be set with an end date.

7. The next time the Smart Meter Monitor batch (D1-SMMTR) runs it will generate estimated data as normally configured.

In order to determine if an area is experiencing a widespread outage, the median read percentage of prior days is used as the basis for comparison. The median was chosen instead of the average to help reduce the impact of outlier values. This is illustrated in the example below.

Reviewing Widespread Outages

Anytime a Meter Communication Tracking Aggregator Measuring Component is marked with an indicator of "Active Outage", a To Do will be generated for user review. The base To Do Type for this is "Widespread Outage" (D2-WSOTD). This To Do is meant to serve as a warning to users that one of the areas in the service territory is experiencing a widespread outage.

If there is a desire to continue processing as normal and not have estimation suppressed, then you can override the Meter Communication Tracking Aggregator by hitting the "Force Complete Outage" button while reviewing the To Do. This will mark the Widespread Outage Indicator as "User Override" and will allow estimation to continue normally.

Reports

Next in This Section

- About Reports

- Running Oracle Utilities Meter Data Management Reports

About Reports

Reports include operational reports related to device events, validation exceptions, and other operational data. Reports can also be based on devices, measuring components, Service Points, service providers, and other data.

Oracle Utilities Meter Data Management reports are implemented using Oracle Business Intelligence Publisher (BI Publisher), and are administered via Oracle Business Intelligence Publisher and the Report functionality of the Oracle Utilities Application Framework.

Refer to the Oracle Business Intelligence Publisher documentation for more information about installing Oracle Business Intelligence Publisher and creating and defining reports. For additional details on how reports are defined and administered see Reporting and Monitoring Tools in the Oracle Utilities Application Framework Administrative User Guide.

Running Oracle Utilities Meter Data Management Reports

This portal is used to submit a new instance of a Report.

Refer to About Reports for additional functional information.

You can access the portal from the Main > Tools > Report Submission.

First, the appropriate Report code must be selected. The Reports provided out-of-the-box are:

- Device Events Report: this report generates a pie graph depicting the percentage of Device Events for each Device Event Type for the specific search criteria.

- Device VEE Exceptions Report: this report generates a pie graph depicting the percentage of VEE Exception for Exception Type and Market for the specific search criteria.

Next, enter the parameter values for the report as appropriate and submit the report.

Dashboards

Next in This Section

- About Dashboards

- Using the MDM Operational Dashboard

- Using the Service Order Operational Dashboard

- Using the Service Order Trends Dashboard

About Dashboards

Dashboards provide a broad view of numerous metrics used with Oracle Utilities Meter Data Management. The data presented on each dashboard is tailored to provide operational as well as analytical information for management. At times, drill down options are provided to retrieve more detailed information about the metrics provided.

For information on configuration, reference the related section for Dashboards in the Oracle Utilities Meter Data Management / Smart Grid Gateway Administrative User Guide.

Using the MDM Operational Dashboard

This portal is used to display the MDM Operational Dashboard.

You can access the portal from the Main > Dashboards > MDM Operational Dashboard. Once you've selected this menu option, you're immediately brought to the initial tab of the dashboard.

The Operations tab displays the following zones:

- IMD Loading Trend: displays the count of initial measurement data that's loaded each day by Head End system.

- Event Loading Trend: displays the count of device event data that's loaded each day by Head End system.

- Incomplete IMDs by Status: displays a set of counts for initial measurement data by status.

- Incomplete IMDs Trend: displays a set of counts for initial measurement data for each day by status

- Incomplete VEE To Dos by Exception Type: displays a set of counts for VEE Exceptions by Exception Type that also still have a To Do that's incomplete.

- Incomplete VEE To Dos Trend: displays a set of counts for VEE Exceptions by Exception Type for each day that also still have a To Do that's incomplete.

- Incomplete Usage Transactions by Status: displays a set of counts for usage transactions by status.

- Incomplete Usage Transactions Trend: displays a set of counts for usage transactions for each day by status.

- Incomplete Usage Transaction To Dos by Exception Type: displays a set of counts for Usage Transaction Exceptions by Exception Type that also still have a To Do that's incomplete.

- Incomplete Usage Transaction To Dos Trend: displays a set of counts for Usage Transaction Exceptions by Exception Type for each day that also still have a To Do that's incomplete.

The Batch Performance tab shows a series of zones related to any defined Performance Targets for batches. More information on Performance Targets can be found in the Framework guide.

The Map Views tab displays the following zones:

- Read Percentage Map: displays a geographical map that plots the percentage of devices communicating on a day by postal code. These percentages are split out by Head End system.

- Widespread Outage Map: displays any widespread outage that's detected by Outage Storm Mode. These results are shown by postal code and display the affected Head End systems.

Refer to About Dashboards for additional functional information. For information on configuration, refer to the related section for Configuring the MDM Operational Dashboard in the Oracle Utilities Meter Data Management / Smart Grid Gateway Administrative User Guide.

Using the Service Order Operational Dashboard

This portal is used to display the Service Order Operational Dashboard.

You can access the portal from the Main > Dashboards > Service Order Operational Dashboard. Once you've selected this menu option, you're immediately brought to the initial tab of the dashboard.

The following zones may appear as part of the portal's Main tab page:

- In-Flight Activities By Type: shows the distribution of in-flight Activities (in progress or in error) by Activity Type.

- In-Flight Activity Trend: shows the number of activities that are in-flight on a given day.

- In-Flight Activities with Issues: presents a bar chart that indicates the number of activities with issues.

- In-Flight Activity Status Distribution: presents a pie chart that displays the distribution of statuses of in-flight activities.

- Efficiency Trend for In-Flight Activities: presents a stacked bar chart that displays the distribution of in-flight activity processing efficiency relative to configurable tolerance.

- Service Order To Do Summary: this zone uses horizontal bars to highlight the relative number of open To Dos for a set of To Do Types related to Service Order Management.

Refer to About Dashboards for additional functional information. For information on configuration, refer to the related section for Configuring the Service Order Operational Dashboard in the Administration Guide.

Using the Service Order Trends Dashboard

This portal is used to display the Service Order Operational Dashboard.

You can access the portal from the Main > Dashboards > Service Order Trends Dashboard. Once you've selected this menu option, you're immediately brought to the initial tab of the dashboard.

The following zones may appear as part of the portal's Main tab page:

- Orchestration Issues Trend: contains a stacked bar chart showing issues by category and Activity Type.

- Issue Distribution Over Time: contains a pie chart showing the distribution of activity issues over a range of days.

- Activity Success Trend: shows successful activities over a range of days.

- Activity Creation Trend: shows activities created over a range of days.

- Activity Completion Efficiency Over Time: shows the efficiency of activity completion over a range of days.

Refer to About Dashboards for additional functional information. For information on configuration, refer to the related section for Configuring the Service Order Trends Dashboard in the Administration Guide.

Totals and Trends

Next in This Section

- Processing Statistics

- Consumption Statistics

Processing Statistics

Next in This Section

- About Processing Statistics

- About Head-end System Processing Statistics

About Processing Statistics

Upload statistics (or upload stats) are statistics related to the uploading of initial measurement data and device events sent from a head-end system.

Upload statistics are defined as activities in Oracle Utilities Smart Grid Gateway.

There are three types of upload statistics activities:

Payload Statistics: Contains statistics related to a specific payload (file) containing one or more initial measurements or device events. Payload Statistics activities contain:

- Basic information about the payload (head-end system, file name, and status

- Middleware statistics including specifics about the file, the total number of initial measurements or device events processed, the number of initial measurement or device events errors, and total processing time

- Initial measurement statistics including the number of initial measurements processed

- Device event statistics including the number of device events processed

Payload Error Notification: Contains details concerning processing errors encountered in an individual payload (file) containing one or more initial measurements or device events. Payload Error Notification activities are related to Payload Statistics activities.

Payload Summary: Contains processing summary statistics for an individual payload (file) containing one or more initial measurements or device events. Payload Summary activities are related to Payload Statistics activities, and are used to update related payload statistics upon the completion of payload processing.

Upload statistics activities are created during processing of payload files as follows:

- When processing begins for a payload, a Payload Statistics activity is created to record the process.

- If an error occurs during processing, a Payload Error Notification activity is created.

- When payload processing is complete, a Payload Summary activity is created, which in turn, updates the Payload Statistics activity with details concerning the processing of the payload, including (the start and end time of the processing, the total processing time, the number of initial measurements or device events processed, and the number of initial measurement or device event errors (if any).

About Head-end System Processing Statistics

Head-end system processing statistics are summarized processing statistics for payloads received from a given head-end system.

As Oracle Utilities Smart Grid Gateway processes payloads containing initial measurements or device events, statistics for each payload are captured in Payload Statistics activities. Over time, payload statistics for each head-end system are summarized to allow administrators to view statistics summary for the head-end system.

Head-end system processing statistics are stored as aggregated measurements for aggregator measuring components. A separate aggregator measuring component must be set up for each head-end system for which processing statistics will be aggregated.

Consumption Statistics

Please refer to the About Aggregation section for information on consumption statistics.

Time Zone Support

Next in This Section

- Daylight Savings Time Support

- Multiple Time Zone Support

Daylight Savings Time Support

This section describes how the Oracle Utilities Service and Measurement Data Foundation and its related products support Daylight Saving Time (DST).

All date/times in the system are displayed adjusted for daylight savings time (when in effect). However, not all date/times in the system are stored in daylight savings time:

- Stored in Standard (not adjusted for DST): data that is highly sensitive to DST shifts are stored in standard time without any shifts, this means they have a consistent 24 hour day each day all year and avoid issues that arise from a skipped hour when transitioning to DST and a duplicate hour when transitioning out of DST. For example: initial measurement data, final measurements, device events, TOU map data.

- These date/times are adjusted for daylight savings time prior to being displayed to a user.

- Stored in Legal (adjusted for DST): data that is not as sensitive to DST time shifts are stored in legal time. For example, device configurations, service points, installation events, usage subscriptions, usage transactions.

Adjusting Date/times Upon Receipt

The two largest sources of imported data to the system can be sent in a mixture of date/time formats some in legal time some in standard time:

- Initial Measurement Data

- Device Events

Since both sets of data are sent by head end systems and each head end system handles date/times differently, potentially even differing by device, the interface must be extremely flexible in how it handles date/times. In order to ensure data is accurately stored and processed the system must know how a given meter sends date/time information. This is defined on the device through the Incoming Data Shift Flag:

- Always in Standard Time: No special handling is required.

- Always in Legal Time: All date/times for the initial measurement data or device event will be converted from legal time into standard time.

- In circumstances where a date/time is received in legal time and it falls on the duplicate hour that occurs when DST ends special logic will be executed to identify whether that hour is the first (still in DST) or second (no longer in DST) of the duplicate hours. If for some reason it cannot be identified which hour it is the transaction will go into error.

Daylight Savings Time Interval Conversion Examples

The following examples show how data received legal time will be shifted into standard time for an interval meter that is read on an hourly basis.

Daylight Savings not in Effect

Date/Time Received in Legal

Date/Time Stored in Standard

01/14/2010 12:00AM

01/14/2010 12:00AM

01/14/2010 1:00AM

01/14/2010 1:00AM

01/14/2010 2:00AM

01/14/2010 2:00AM

01/14/2010 3:00AM

01/14/2010 3:00AM

01/14/2010 4:00AM

01/14/2010 4:00AM

01/14/2010 5:00AM

01/14/2010 5:00AM

Daylight Savings Starts (Spring Forward) - No 2AM interval

Date/Time Received in Legal

Date/Time Stored in Standard

03/14/2010 12:00AM

03/14/2010 12:00AM

03/14/2010 1:00AM

03/14/2010 1:00AM

03/14/2010 3:00AM

03/14/2010 2:00AM

03/14/2010 4:00AM

03/14/2010 3:00AM

03/14/2010 5:00AM

03/14/2010 4:00AM

03/14/2010 6:00AM

03/14/2010 5:00AM

Daylight Savings in Effect

Date/Time Received in Legal

Date/Time Stored in Standard

06/14/2010 12:00AM

06/13/2010 11:00PM

06/14/2010 1:00AM

06/14/2010 12:00AM

06/14/2010 2:00AM

06/14/2010 1:00AM

06/14/2010 3:00AM

06/14/2010 2:00AM

06/14/2010 4:00AM

06/14/2010 3:00AM

06/14/2010 5:00AM

06/14/2010 4:00AM

Daylight Savings Ends (Fallback) - Duplicate 1AM

Date/Time Received in Legal

Date/Time Stored in Standard

11/7/2010 12:00AM

11/6/2010 11:00PM

11/7/2010 1:00AM

11/7/2010 12:00AM

11/7/2010 1:00AM

11/7/2010 100AM

11/7/2010 2:00AM

11/7/2010 2:00AM

11/7/2010 3:00AM

11/7/2010 3:00AM

11/7/2010 4:00AM

11/7/2010 4:00AM

Daylight Savings Impact on Periodic Estimation

In periodic estimation both the interval and scalar versions can be impacted by daylight savings time:

- Interval periodic estimation using the "Predictable Cut-off" method.

- All scalar periodic estimation

Refer to About Periodic Estimation for more information about the impact of Daylight Savings Time on periodic estimation.

Multiple Time Zone Support

Some utilities have operations in more than a single time zone. When operating in multiple time zones, Oracle Utilities Meter Data Management and Smart Grid Gateway provide the following high level functionality:

- The ability to receive data in any time zone and convert it to the common time zone used by Oracle Utilities Meter Data Management (as defined by the base time zone)

- The ability to display functional date/times in the time zone of a given device, service point, usage subscription

- The ability to define what time zone a measuring component, device configuration, service point, or usage subscription resides in

- The ability to aggregate data across time zones into a single time zone or without respect to a time zone (see Aggregations on page E-17 for more information).

- The ability to export data to an external system with the appropriate time zone information to enable the external system to consume data from different service points in different time zones

By default, the system assumes only a single time zone is supported. To enable support for multiple time zones it requires that adding the appropriate entry to the general system configuration feature configuration.

Refer to Configuring Feature Configurations for additional on the feature configuration options available.

Date/Time Storage and Display

All date/times in the system are stored in the base time zone. Date/times are stored in either standard time or legal time and this determination is made based on the type of data (e.g. measurements are in standard but installation event date/times are in legal).

All date/times are displayed in legal time. Those date/times that are key functional date/times related to a device, service point, or usage subscription will be displayed in the legal time of the time zone the device resides in.

Refer to the Glossary of Terms for a more detailed definition of Standard and Legal time.

Time Zone Hierarchy and Maintenance

A time zone can be defined at many points within the device to usage subscription hierarchy. This enables the time zone to be accurately portrayed based on the installation status of that device (e.g. not installed, installed but not billed, billed). At each stage of the hierarchy the time zones must match.

Once the hierarchy has been established no one portion of that hierarchy can be changed to a time zone that differs from the other levels of the hierarchy. In order to change the time zone for an established device to usage subscription hierarchy the change must be done to the service point. Once the service point time zone has been changed the system will cascade that change to all other levels of the hierarchy.

If a device has been installed at a service point in order for it to be moved to a different service point in a different time zone. It will require that a new device configuration be created for time zone of the new service point since a device configuration cannot be associated to two different service points each with a different time zone from the device configuration.

Note: If the time zone for a device that has existing measurements has been changed there will be no automatic adjustments made to the underlying measurement data. If the measurement data must be changed it will require manual intervention.

Note: Although measuring component has time zone it is not populated on physical devices that are installed at service points. This time zone is used for standalone measuring components.

Impacts on Aggregations

In aggregation there are two use cases for how data should be aggregated for service points that exist in differing time zones:

- Absolute Time: If a time zone is provided on the measuring component or measuring component type, then the aggregation horizon date/times will be used across service points of differing time zones. For example the 4/1/2010 12AM interval in US/Pacific would be combined with the 4/1/2010 3AM interval in US/Eastern. Since all date/times are stored in the base time zone there is no need to do time zone conversions.

- Local Time: If no time zone is specified, consumption is aggregated by converting the aggregation horizon to the appropriate time zone for each service point. For example the 4/1/2010 12AM interval in US/Pacific would be combined with the 4/1/2010 12AM interval in US/Eastern.

Aggregation Measuring Components in general do not have any time zone related dependencies with other master configuration objects. However, when an aggregator is listed as a direct channel measuring component on a usage subscription it share the same time zone as the Usage Subscription.

Impacts on TOU Map Generation

The date and times defined on a Time of Use Mapping Templates (TOU) do not have a time zone associated to them and will be interpreted based on the time zone of the TOU map type of the specific TOU Map being processed. This allows for a single definition of a TOU schedule that can be applied across many different time zones.

During the generation of the TOU map data for a given TOU map template the date/times will be converted from the time zone of the TOU map to the time zone defined in the base time zone defined on the installation options - framework. For example, if 1/1/2010 5:00PM was considered to be "On Peak" and the system time zone was UTC -08:00 and the TOU map time zone was UTC -05:00 then the TOU map data entry would be written as 1/1/2010 2:00PM.

Impacts on Factors

Factor effective dates do not have a time zone associated to them and are assumed to be in the local time zone of the data being validated. For example a factor effective 4/1/2010 12:00AM would be considered to be effective 4/1/2015 12:00AM UTC -08:00 and 4/1/2010 12:00AM UTC -05:00 based on the time zones of the respective meters. This allows a single factor to apply to many time zones and behave uniformly.

Impacts on Holidays

Holiday effective dates do not have a time zone associated to them and are assumed to be in the local time zone of the data being validated. For example a holiday on 12/25/2010 would be considered to be effective beginning 12/25/2010 12:00AM UTC -08:00 and 12/25/2010 12:00AM UTC -05:00 based on the time zones of the respective meters.

Impacts on Periodic Estimation

Refer to About Periodic Estimation for more information about the impact of Daylight Savings Time on periodic estimation.

Impacts on Initial Measurement Creation Online

When creating initial measurements online from the 360 Degree View portals, initial measurements are created as appropriate for measuring components with time zones other than the base time zone.

For example, if you copy measurements from a measuring component in one time zone to a measuring component in a different time zone, the measurements are being moved in absolute time (i.e. the 3:00 PM in UTC -08:00 would be changed 6:00PM in UTC -05:00).

Impacts on Items

The consumption for "badged" and "unbadged" items is driven by configuration on the device type service quantity and the multi-item section of the service point:

- Device Type Service Quantity: the effective date of the service quantity does not have a time zone and is assumed to be in the local time zone of the service point it is associated to (whether through a install event for "badged" items or by being directly configured on the service point). For example an effective date time of 1/1/2010 5:00PM would be considered to be effective beginning 1/1/2010 5:00PM UTC -08:00 and 1/1/2010 5:00PM UTC -05:00 based on the time zones of the respective meters

- Service Point Multi-Item: the start date time and end date time of the multi-item list are stored in legal time of the base time zone and displayed in the legal time of the service point's time zone.

Service Issue Monitors

Next in This Section

- About Service Issue Monitors

- About Service Investigative Orders

About Service Issue Monitors

Service Issue Monitors are service tasks that analyze service points to determine if service is needed. If service is determined to be needed, the Service Issue Monitor creates a Service Investigative Order.

Device events, VEE exceptions, and failed smart meter commands can trigger the creation of a service issue monitor (the type of service issue monitor created is based on the Service Issue Monitor Type specified on the device event type, exception type, or activity type). Once created, service issue monitors analyze the service point where the device associated with the device event, VEE exception, or failed command, based on evaluation criteria specified on the service issue monitor's type. If the criteria are met (in other words, if a specified number of command failures, device events, or VEE exceptions are found for the service point), the service issue monitor creates a service investigative order.

Service Order Monitor Creation

This section provides an overview of the process that takes place when service issue monitors are created.

Note: The process outlined below has been simplified for illustrative purposes, and does not reference every step performed in this process.

1. One (or more) of the following takes place:

- A device event or reader remark is received, whose type specifies a Service Issues Monitor Type

- A VEE exception whose type specifies a Service Issues Monitor Type is generated during VEE processing

- A usage exception whose type specifies a Service Issues Monitor Type is generated during usage calculation

- A smart meter command fails whose type specifies a Service Issues Monitor Type

- A business flag is received whose type specifies a Service Issue Monitor Type

2. The object received in item (1) creates a service issue monitor based on the referenced Service Issue Monitor Type

3. The service issue monitors analyzes the service point based on the Discard Rules and Evaluation Criteria defined on the service issue monitor's type to determine if a service investigative order should be created or if the service issue monitor should be discarded.

The "Discard Rules" on the service issue monitor's type are evaluated to determine if the new service issue monitor should be discarded (new service issue monitors are always discarded when created if an existing service investigative order created by an service issue monitor of the same type exists for the service point.)

If the service issue monitor type was configured to require approval, the service issue monitor generates a To Do to notify the appropriate individuals that approval is necessary.

If the service issue monitor is approved or if no approval was necessary the service investigative order will be continue.

4. The service issue monitor then executes the evaluation criteria defined on the service issue monitor's type. If those criteria are met the Service Investigative Order activity is created. If the criteria are not met the service issue monitor is discarded.

5. If the service issue monitor has completion criteria defined the service issue monitor will wait for the service investigative order to complete. Once complete the the service issue monitor will execute the completion criteria to evaluate if the service investigative order achieved the desired results.

If either there were no completion criteria or they were satisfied the service issue monitor will complete.

If the completion criteria were not satisfied the service issue monitor enter an inconclusive investigation state from which manual intervention will be required.

About Service Investigative Orders

Service investigative orders are activities created by a service issue monitor when a specified set of events have occurred at a service point. The type of activity created by the service issue monitor is defined on the service issue monitor's type.

Service issue monitors are often configured to create field activities that are in turn sent to an external field work system, such as Oracle Utilities Mobile Workforce Management.

Service Order Management

Next in This Section

- About Service Order Activities

- About Field Activities

- About Appointments

About Service Order Activities

Service order activities represent specific service order requests either received from an external system or created from within Oracle Utilities Smart Grid Gateway.

Service order activities are created when specific types of requests for service are received in the system. These activities orchestrate the steps necessary to fulfill the request, based on the current state of the service point related to the request. For example, the system creates an "enable service" activity when a request is made to enable service at a particular service point. This activity examines the current state of the service point, and creates one or more additional activities if appropriate. For example:

- If there is no meter currently installed at the service point, the service order activity would create an "install meter" field activity and send it to a field work system (such as Oracle Utilities Mobile Workforce Management).

- If there is a meter installed, but the meter is not currently registered with the head end system, the service order activity might create a "commission meter" smart meter command.

- If the meter is active and commissioned, but not currently connected, the service order activity might create a "remote connect" smart meter command.

- Etc.

Service order requests are typically received from the customer information system such as Oracle Utilities Customer Care and Billing, but can also be created from within Oracle Utilities Meter Data Management or Oracle Utilities Smart Grid Gateway.

The base package provides the following types of service order orchestration activities:

- Enable Service: Used to enable service at a service point.

- Disable Service Used to disable service at a service point.

- Cut for Non-Payment: Used to cut off service at a service point due to non-payment of past due amounts.

- Reconnect Service for Payment: Used to restore service at a service point after receipt of past due payment.

- Exchange Meter: Used to orchestrate the exchange of meters at service point, such as in the event that a customer upgrades their meter.

- Back to Back Service: Used to orchestrate a change of service when the customer at a service point changes (such as when owners/tenants change).

Service order orchestration activities are defined by the following:

- Activity Type: The service order's activity type.

- Service Date/Time: The date and time the service order request was received.

- Service Point: The service point associated with the service order request.

- Service Agreements: A list of one or more service agreements related to the service order request (not used with all service order orchestration activities).

- Request Information: Details of the service order request, including requester and external system information.

- Collection Data Details: Details regarding past due balances (used with Cut for Non-Payment activities only).

- Contact Details (or Customer Information): Contact details for the customer associated with the service order request.

Note: Some service order activities use additional data.

In the event that an active service order activity needs to be updated and/or cancelled, the system also supports the following maintenance service order activities:

- Cancel Orchestration: Used to cancel a currently active service order activity.

- Update Orchestration: Used to update a currently active service order activity.

Service order maintenance activities are defined by the following:

Activity Type: The service order's activity type.

Orchestration Activity: The original orchestration activity related to the maintenance activity.

Related Activity: A specific activity (such as a field activity or smart meter command) related to the maintenance activity.

Cancel Reason: The reason for cancelling the original activity (for cancel activities only).

Comments/Instructions: Specific comments and/or instructions applicable to the maintenance activity (for update activities only).

Start Date/Time: The date and time the maintenance activity was initiated (for update activities only).

Request Information: Details of the service order request, including requester and external system information.

Activity Hierarchy: A tree that displays the activity and related activities (including field activities and smart meter commands), inbound and outbound communications, and completion events.

About Field Activities

Field activities are specific types of tasks performed by field personnel. Examples include installing meters, repairing/replacing meters, etc.

Field activities are created when completing specific types of requests for service requires field work. Once created, field activities are sent to a field work system (such as Oracle Utilities Mobile Workforce Management) where they are scheduled and assigned to a field work crew. When the task is completed by the crew, the field work system sends an response to the system and the field activity is updated as appropriate.

When communicating with field work systems, field activities create outbound communications to send the required information to the field work system. When the field work system sends its response, the system creates an inbound communication. See About Communications for more information about communications.

Field activities are created when a service order orchestration activity examines the current state of the service point, and determines that field work is required to completed the service request. For example, if an "enable service" activity determines that there is no meter currently installed at the service point, the service order activity would create an "install meter" field activity and send it to a field work system.

Field activities are defined by the following:

- Activity Type: The field activity type.

- Status: The current status of the field activity.

- Service Date/Time: The date and time the field activity was created.

- Service Point: The service point associated with the field activity.

- Field Task Type: The field task type for the field activity.

- Recipient: The service provider to which the field activity is sent for scheduling and assignment.

- Device: The device related to the field activity (if applicable).

- Request Information: Details of the service order request, including requester and external system information.

- Contact Details (or Customer Information): Contact details for the customer associated with the service order request.

- Address Information: The address of the service point associated with the field activity.

About Appointments

The Appointment Booking portal is used to request and track appointments related to field activities that have been scheduled in an external field work scheduling system such as Oracle Utilities Mobile Workforce Management.

When field activities send outbound communications to the field work system, appointments are created in field work system so that the work can be assigned to a crew. Requests for appointments are most often requested automatically when the field activity is created, but if needed, users can request appointments manually.

Users work with the Appointment Query portal to search for activities and related appointments.

Users work with the Appointment Booking to request and track appointments for field activities. This portal includes the following zones:

- Service Point Activities: Displays a list of activities and related appointments for the current service point in date descending order. This zone also includes a filter area which allows the user to define the inclusion or exclusion of activities according to certain criteria

- Activity Summary: Displays details of a selected activity in the Service Point Activities zone (indicated by a star).

- Appointment Booking Results: Displays a list of available appointment slots as returned by the scheduler. This zone allows the user to book an appointment by selecting a slot and subsequently updating the orchestration or field activity.

Data Access Restrictions

Next in This Section

- Using Data Access Restrictions

Using Data Access Restrictions

The focus for multi-jurisdiction support in Oracle Utilities Meter Data Management is on restricting access to the user interface. This occurs through defining different Access Groups by operating company which then marks the Service Point with the access capabilities. The Service Point has a field named Access Group which allows you to define specific access to the Service Point.

If Access Group is set on the Service Point, then the user interface search screens within Oracle Utilities Meter Data Management will only allow users that are assigned to the proper Access Role to be able to access that Service Point.

For additional information see Defining Access Groups.

Defaulting Access Groups on Service Points

If there is a desire to set a default Access Group by jurisdiction, then this can be accomplished on configuration for Markets. When defining a Market there is an option to add a Default Access Group. This value will be used to mark any newly created Service Point with the same Access Group value defined on the related Market.

Example Scenarios

Below are some examples of how Data Access Restrictions can be implemented:

Example 1: Split Access by Market - an example utility "ABC Energy" that has 3 operating companies.

Example 2: Isolating Important Customers - an example utility "XYZ Energy" that has 2 operating companies but would also like to isolate access to Large commercial customers for one of the companies.

To Do Processing

There are numerous events that trigger the creation of email-like messages describing work that requires human attention. For example, if a bill segment has an error, a message is created to highlight such. We refer to each message as a To Do Entry. In this section, we describe how to view, manage and work To Do entries.

Fastpath: We recommend familiarizing yourself with the topics described in The Big Picture of To Do Lists to fully appreciate how To Do entries are managed by the system.

Next in This Section

- The Big Picture of To Do Processing

- Managing To Do Entries

- How To

The Big Picture of To Do Processing

The topics in this section provide background information on To Do processing functionality.

Next in This Section

- To Do Role

- To Do Priority

- Work Distribution

- A User's Current To Do

- Related To Do Entries

- Complete A To Do

To Do Role

Each To Do entry is assigned a specific To Do Role. The role defines the users who may work on the entry. The permissible roles that may be assigned to a To Do entry are defined on the entry's To Do type. Refer to To Do Entries Reference A Role to learn more about initial role assignment.

After an entry is created, its role may be changed to any role defined as valid for the entry's To Do type. Manual changes of a To Do entry's role are recorded on the To Do entry log.

To Do Priority

A To Do entry is associated with a priority level representing its processing order compared to other entries. Refer to The Priority Of A To Do Entry for more information on how an entry's priority is initially assigned.

A user may manually override a To Do entry's priority at any time. Once overridden, automatic recalculation of the priority is no longer performed so as not to override the value explicitly set by the user. Manual overrides of a To Do entry's priority are recorded on the To Do entry log.

Work Distribution

To Do entries may be manually assigned to users either by their supervisors or picked up by the users themselves. The system can also be configured to dynamically assign the highest priority work to users on demand whenever they are available for fixing errors.

Note: Assignment on demand is in a plug-in. You can customize the next assignment plug-in on the installation options to follow your organization's work distribution rules. For example, when a user asks for the next assignment, business rules may be used to only consider To Do entries the user has the proper skills to resolve, prioritizing them based age, impacted dollar amount, etc.

One of the main benefits of the assignment on demand approach is that work is allocated real-time based on most current information such as skills, priority, user availability, etc. This also means that work remains unassigned until a user is actually going to work on it making it available to any qualified user.

Manual assignments of To Do entries are possible as follows:

- Supervisors may use the supervisor function pages to review and assign To Dos to users.

- A user may use the To Do list pages to review and assign To Dos to themselves or forward any of their To Dos to someone else.

- All of the above assignment functions may also be performed using the To Do Search page.

Assignment "on demand" is possible from the Current To Do zone on the Dashboard portal. Refer to this zone to learn about all the functions it provides.

A User's Current To Do

Users have the option of drilling down on an entry from various list queries in the system. Refer to Working On A To Do Entry for more information on drilling into an entry.

Drilling down on an entry from the following To Do list queries (using the entry's message description only) also sets the entry as the user's Current To Do entry:

- To Do List

- To Do Search

Additionally, users may have the option to click on the Current To Do icon, , on the Current To Do dashboard zone to request their next task. The returned To Do entry automatically becomes the user's Current To Do.

Regardless of how a To Do entry became current its information is displayed on the Current To Do zone.

Fastpath: Refer to Current To Do zone to learn about all the functions it provides to efficiently resolve the current To Do and other entries that may potentially be related to it.

If a To Do entry becomes current as a result of drilling down from a list query, the system supports the ability to drill down to the Next and Previous entries respective to the Current To Do entry in that list.

Note: The Previous To Do button and Next To Do button in the Current To Do zone allow you to scroll through additional To Do items in your current work list without returning to the list query transaction. These buttons set the respective To Do entry to now being current and take you to its related transaction or to a script associated with the To Do Entry's message (not to the To Do entry itself). This is yet another way of drilling down on an entry.

If a To Do entry becomes current using the Current To Do zone’s next assignment functionality, that entry is not associated with any work list to scroll through. The Next and Previous To Do buttons are therefore disabled in this case.

Note: Current Work List. Current work list refers to the list from which the current To Do entry was selected. Each new election of a current To Do overrides the previous work list with the new list the entry was selected from. If not selected from a list then the current work list is considered empty.

Related To Do Entries

A user working on a To Do may want to know of other To Dos that may be related to the same problem. If can be worked by the same user they may get resolved faster. It seems almost impossible to programmatically determine whether two To Dos really stem from the same problem. The user should therefore be presented with a list of potentially related To Dos from which he/she can select the truly relevant ones.

A To Do entry is considered potentially related to a given To Do if they reference a common entity. For example, if a given To Do references a certain account then any To Do referencing that same account is considered related to it.

Note: The system considers any To Do characteristic of Foreign Key type to represent a reference to an "entity". In other words, if a To Do has at least one common Foreign Key characteristic type / value with a given to do it is considered related to it.

The To Do Search page supports a Related To Do filter that lists all related To Dos for a given entry. Various pages showing To Do information often provide an indication as to how many non-complete entries may be related to a given To Do entry. Clicking on the indication's hyperlink transfers the user to the To Do Search query pre-populating it to list the related entries for the specific To Do entry.

Fastpath: Refer to the To Do Search page for more information on all the functions it supports.

Complete A To Do

After you finish working on an entry, you can mark it as Complete. At this point, you may want to review potentially related To Do entries and complete those that have been addressed by resolving the problem associated with the current entry.

If you cannot resolve the problem, you can forward the To Do to another user, thus assigning the To Do to another user.

Fastpath: Refer to How To Complete To Dos for more information.

Note: It is possible for the system to automatically mark an entry as Complete. Refer to The Lifecycle Of A To Do Entry for more information.

Managing To Do Entries

This section describes the various pages available to view and work on To Do entries.

Next in This Section

- To Do Supervisor Functions

- To Do List Functions

- To Do Entry

- To Do Search

To Do Supervisor Functions

This section describes To Do transactions that aid supervisors in the monitoring and assignment of To Do entries.

Next in This Section

- Supervisor To Do Summary

- Supervisor User Summary

- Supervisor To Do Assignment

Supervisor To Do Summary

This Supervisor To Do Summary page summarizes To Do entries by To Do Type. Only entries that are Open (i.e., not assigned to a specific user) or Being Worked On are summarized.

Note: Only To Do entries that are assigned to a role to which you belong are summarized on this page. Refer to To Do Entries Reference A Role for more information.

Use Menu > To Do > Supervisor To Do Summary to open this page.

Description of Page

This page summarizes all To Do entries that are Open or Being Worked On.

- To Do Type contains the description of the To Do type.

- Priority provides a total count of To Do entries of a given type by priority. For each distinct priority the description includes the priority value followed by the corresponding number of entries. If all entries are of the same priority no additional count is displayed.

- Total contains the total of Open and Being Worked On entries. The hyperlink navigates to the Supervisor To Do Assignment transaction, setting it to display all Open and Being Worked On entries for the given To Do Type.

- Open contains the number of To Do Entries whose status is Open. The hyperlink navigates to the Supervisor To Do Assignment transaction, setting it to display all Open entries for the given To Do Type.

- Being Worked On contains the number of To Do entries whose status is Being Worked On. The hyperlink navigates to the Supervisor To Do Assignment transaction, setting it to display all Being Worked On entries for the given To Do Type.

The "age bars" that appear to the right of the totals highlight the age of the To Do entries. The colors red, yellow and green are used to highlight the relative number of old, middle-aged and new To Do entries. The age associated with each of these colors is user-configurable.

Supervisor User Summary

The Supervisor User Summary page summarizes To Do entries by the user who is assigned to work on the entries. Only entries that are Being Worked On are summarized.

Note: Only To Do entries that are assigned to a role to which you belong are summarized on this page. Refer to To Do Entries Reference A Role for more information.

Use Menu > To Do > Supervisor User Summary to open this page.

Description of Page

This page contains a grid that displays all assigned To Do entries by User ID and To Do type. It indicates how many To Do entries of the displayed Type are assigned to the user (Assigned this Type) and how many To Do entries in total are assigned to the user (Assigned Total).

Clicking the hyperlinks transfer you to the Supervisor To Do Assignment transaction. On this transaction, you can assign / reassign To Do entries to a specific user. The difference is that clicking the To Do Type hyperlink causes only Open entries to be displayed on the Assignment transaction. Clicking the count in the Assigned this Type column causes Being Worked On entries assigned to the displayed user to be shown.

Supervisor To Do Assignment

This page lists To Do entries of a given type and allows a supervisor to assign / reassign them to a designated user. Use Menu > To Do > Supervisor To Do Assignment to open this page.

Description of Page

This page contains Open or Being Worked On To Do entries of a given type. These entries can be assigned to a specified user one-by-one or several at a time. The following points describe this functionality:

- You can select a different To Do Type by typing in a value or pressing the search button in the upper right corner. An Info description of the To Do type appears on the left.

- You can change the list of entries displayed according to their status. Select the Filter by status to be All (blank), Open, or Being Worked On.

- For Being Worked On entries, you may also Filter by User to limit the search to a specific user assigned to the To Do entries.

- If you want to re-sort the entries by a different value, click the search button adjacent to Extra Information. Each row's respective sort value is displayed in the Extra Information column.

Note: Extra Information. Each To Do list's default Extra Information is defined on the list's To Do Type. Also note that each To Do list's available Extra Information differs.

- Click the Select All button to select all entries displayed in the grid. Click the Clear All to remove the selections in the grid.

- Use the checkbox if you want to assign specific entries.

- Entries are further sorted by their Priority. Highest in priority are listed first.

- Create Date/Time contains the date and time the To Do entry was created by the system. Click the Create Date/Time hyperlink to:

- View more detailed information about the entry.

- Add comments to the To Do entry.

- Add a log entry of type User Details to record information about the To Do entry.

- Forward the To Do entry to another user.

- Send Back a To Do entry that was forwarded to you by another user.

- Click the number of Related entries hyperlink to navigate to the To Do Search query to list potentially related entries to the current entry.

- Worked By shows the user currently assigned to the To Do entry.

- To Do Entry Status is the current status of the To Do entry.

- Message contains a description of the To Do entry. Use the message description hyperlink to drill into the page on which the entry's respective object is displayed. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched. Refer to Working On A To Do Entry for more information.

- You can assign entries to a user:

- Enter a user ID or search for a user using the Assign To User field. You can only select a user that is associated with a role that is associated with this To Do Type. Note that the current number of assignments is displayed adjacent.

- Select one or more entries to assign to this user and click the Assign button. The entries' status becomes Being Worked On.

To Do List Functions

This section describes To Do pages that aid users in the assignment and working of entries in To Do lists.

Next in This Section

- To Do Summary

- To Do List

To Do Summary

This page summarizes To Do entries that meet the following qualifications:

- The entry is Open and you belong to the entry's To Do role. Refer to To Do Entries Reference A Role for more information about roles.

- The entry is Being Worked On and you are the user to which it is assigned.

Use Menu > To Do > To Do Summary to open this page.

Keyboard Shortcut

Alternate Shortcut

Alt+X

Alt+Shift+X

Note: Refer to Shortcut Key Summary for information about the alternate shortcut.

Fastpath: Refer to The Big Picture of To Do Lists for an overview of To Do functionality.

Description of Page

This page is dedicated to a grid that summarizes the To Do entries on which you can work. The following information is displayed:

- To Do Type contains the description of the To Do type.

- Priority provides a total count of To Do entries of a given type by priority. For each distinct priority the description includes the priority value followed by the corresponding number of entries. If all entries are of the same priority no additional count is displayed.

- Total contains the total of Open and Assigned to You entries. The hyperlink navigates to the To Do List transaction, setting it to display all Open and Being Worked On entries assigned to you for the given To Do Type.

- Open contains the number of To Do Entries whose status is Open. The hyperlink navigates to the To Do List transaction, setting it to display all Open entries for the given To Do Type.

- Assigned to You contains the number of To Do entries that are assigned to you whose status is Being Worked On. The hyperlink navigates to the Supervisor To Do Assignment transaction, setting it to display all Being Worked On entries for the given To Do Type.

The "age bars" that appear to the right of the totals highlight the age of the To Do entries. The colors red, yellow and green are used to highlight the relative number of old, middle-aged and new To Do entries. The age associated with each of these colors is user-configurable.

To Do List

This page lists To Do entries of a given type that are either Open (e.g., not assigned to a specific user) or are assigned to you.

Note: Restricted by role. Only those entries assigned to a role to which you belong may be seen on this page. Refer to To Do Entries Reference A Role for more information.

Fastpath: We recommend familiarizing yourself with the topics described in The Big Picture of To Do Lists to fully appreciate how To Do entries are managed by the system.

Use Menu > To Do > To Do List to open this page.

Description of Page

This page contains a grid that summarizes the To Do entries of a given type on which you can work.

The Info section contains a concatenation of the To Do Type's description and the user's name.

The area beneath Info provides you with options that control which To Do entries appear and the order in which they are displayed. The following points describe the various options:

- Use Sort By to define how you want the To Do entries sorted. The following options are available:

- Assigned Date - On or After. This option sorts the To Do entries in chronological order (based on the date the entry was assigned to you) starting from the input Date. If you choose this option, the system assumes you want to start from the earliest To Do entry. If you want to start from a date other than the earliest To Do entry, enter the desired Date and click the adjacent search button.

- Assigned Date - On or Before. This option sorts the To Do entries in reverse chronological order (based on the date the entry was assigned to you) starting from the input Date. If you choose this option, the system assumes you want to start from the today's date. If you want to start from a date other than today's date, enter the desired Date and click the adjacent search button.

- Create Date - On or After. This option sorts the To Do entries in chronological order (based on the date the entry was created) starting from the input Date. If you choose this option, the system assumes you want to start from the earliest To Do entry. If you want to start from a date other than the earliest To Do entry, enter the desired Date and click the adjacent search button.

- Create Date - On or Before. This option sorts the To Do entries in reverse chronological order (based on the date the entry was created) starting from the input Date. If you choose this option, the system assumes you want to start from the today's date. If you want to start from a date other than today's date, enter the desired Date and click the adjacent search button.

- Extra Information. This option sorts the To Do entries by the value of the Extra Info.

- Use Extra Info to choose data related to the To Do Entry that should be used to sort the To Do entries. This information is displayed in each entry's Extra Information column.

Note: Extra Info. Each To Do list's available Extra Info is defined on the list's To Do Type Sort Keys. Also note that each To Do list's available Extra Info differs based on the configuration of the To Do Type.

- Use Filter by to restrict the To Do entries based on their status. The following options are available:

- All. This option shows all entries that are Open or Being Worked On.

- Being Worked On. This option shows all entries that are Being Worked On (and assigned to you).

- Open. This option shows all entries that are Open.

The grid that follows contains the To Do entries that match your criteria. The following information appears:

- Click the Select All button to select all entries displayed in the grid. Click the Clear All button to remove the selections in the grid.

- Use the checkbox if you want to mark specific entries as Completed or Being Worked On using the Complete or Assign buttons at the bottom.

- A Comments icon appears if there are comments on the To Do item and a Log Entry icon appears if there is a log entry of type Forwarded, Sent Back or User Details on the To Do item. This column appears if at least one To Do has either comments or a special log entry.

- Entries are further sorted by their Priority. Highest in priority are listed first.

- Create Date/Time contains the date and time the To Do entry was created by the system.

- Click the Create Date/Time hyperlink or either of the special icons to navigate to the To Do entry page.

- Click the number of Related entries hyperlink to navigate to the To Do Search query to list potentially related entries to the current entry.

- Assigned Date/Time contains the date and time the To Do entry was assigned to a user. This field is only populated on entries that are Being Worked On. If a user assigned the To Do entry, the user ID and name of the user who assigned the To Do entry are displayed beneath the Date/Time.

- Message contains a description of the To Do entry. Use the message description hyperlink to drill into the page on which the entry's respective object is displayed. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched. Refer to Working On A To Do Entry for more information.

Note: Current To Do. Drilling into an entry from this page sets it to be the user's current To Do. Refer to A User's Current To Do for more information on how to efficiently scroll through additional entries in your current work list.

CAUTION:

Automatic Assignment! When you drill into an entry using the message description hyperlink from this page, the system changes the status of the entry to Being Worked On and assigns it to you.

- To Do Entry Status is the current status of the To Do entry.

- Extra Information contains the data for the entry that corresponds to the Extra Info chosen in the sort options above.

- To Do ID contains the unique identifier of the To Do entry.

- If you want to mark one or more entries as Being Worked On, check the desired entries and then click the Assign button.

- If you want to mark one or more entries as Completed, check the desired entries and then click the Complete button. Completed entries do not appear on the To Do list (but they are retained on the database for audit purposes).

To Do Entry

The topics in this section describe the pages on which a To Do entry and its associated To Do log are maintained.

Next in This Section

- To Do Entry - Add Dialog

- To Do Entry - Main

- To Do Entry - Keys/Values

- To Do Entry Actions

To Do Entry - Add Dialog

The To Do Entry transaction features a dialog that can add new To Dos (if the system is configured with manual To Do types). This dialog appears if you open the Menu > To Do > To Do Entry > Add (it also appears if you click the clear button when on the To Do Entry page).

Description of Page

The To Do Type is the type of To Do entry that you want to create. Only To Do types that are set up for manual usage appear in the list.

The default To Do Type Priority is displayed adjacent. Use Override Priority to override the default priority assigned by the system.

Type a Subject for your To Do entry. Depending on how the To Do type is set up, the subject may appear as the message in the To Do entry and To Do lists.

Enter a Comment to provide a longer description of and more details about the To Do entry.

Send To indicates whether the new To Do will be assigned to a Role (the default) or User.

The Role indicates the role to which this To Do entry will be assigned. Only users of the specified role will be able to view and work on the To Do entry. The role is defaulted from the To Do type. If you want to assign the To Do to a different role, change the specified role. You can only assign the To Do entry to one of the roles specified on the To Do type.

User appears if Send To is set to User. Use this option if you want to assign the To Do to a specific user. The user must be a member of the selected role.

If the To Do type defines valid characteristic types, the Characteristics collection is visible. If any of the characteristic types are flagged as Default on the To Do type, the characteristic type with its default value (if applicable) are displayed. If applicable use the characteristics to define other information related to this new To Do entry. In Oracle Utilities Customer Care and Billing, for example, you can link the account and premise that you are attempting to start service for.

Click OK to add the To Do Entry.

To Do Entry - Main

You use this page to perform various actions or modify details about a To Do entry. Use Menu > To Do > To Do Entry > Search to open this page.

Note: Restricted by role. You may only change To Do entries that are assigned to you or ones that are Open and assigned to a role to which you belong. Refer to To Do Entries Reference A Role for more information about roles.

Description of Page

To Do contains a concatenation of important information about the To Do entry. To Do ID is the system-assigned unique identifier of the entry. These values only appear after the case is added to the database.

Note: Formatting may be performed by a plug-in. Refer to To Do Info May Be Formatted By An Algorithm for more information.

To Do Type displays the entry's To Do Type and its description. Refer to To Do Entries Reference A To Do Type for more information about To Do types.

Role displays the role of the users who may be assigned to the entry along with a description of the role. Refer to To Do Entries Reference A Role for more information about roles.

Message is a display-only field that describes why the entry exists. If the To Do entry is in the status of Open or Being Worked On, the message description allows you to drill into the page on which the entry's respective object is displayed. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched. Refer to Working On A To Do Entry for more information.

Status indicates if the entry is Open, Being Worked On, or Complete. Refer to The Lifecycle Of A To Do Entry for more information status.

Use Priority to manually override the To Do entry's current priority. Any manual change to the priority is recorded on the To Do entry log.

Assigned To displays the user who is working the entry.

Sent By displays the user who assigned this To Do to the current user.

Created By only appears if a background process that uses To Do entries to report object-specific errors created the To Do entry. The field displays the background process description and batch run number in which the entry was created. Refer to To Dos Created for Object-Specific Error Conditions for more information.

Extract Info only appears if the To Do is being sent out of the system. Extract Info describes the status of the extract (for example whether it has been processed or not). Refer to To Do Entries May Be Routed Out Of The System for more information.

Use Comments to describe anything interesting or unusual about the To Do entry. The Comments field is disabled if the To Do entry is complete.

If the To Do entry has non-complete related entries a summary description appears below the comments line. The description states the total number of related entries, how many are still Open, how many are assigned to you and how many assigned to others. Use this hyperlink to navigate to the To Do Search query to list these entries.

The Actions buttons allow you to Complete the To Do, Forward the To Do to another user or Role, or Send Back a To Do that has been forwarded to you by another user. All buttons are disabled once a To Do is complete. Refer to To Do Entry Actions and the How To section for more information on using these actions.

The Characteristics collection is visible for manual To Do entries or for automatic To Do entries that have characteristics. Characteristic Type indicates the type of characteristic. Specify a valid Characteristic Value for the characteristic type.

Note: Only characteristic types defined as permissible on a To Do entry may be linked to a To Do. Refer to Setting Up Characteristic Types & Their Values for more information about characteristic types. In addition, for manual To Do types, the characteristic type must also be defined as valid for the To Do entry's To Do type.

The Log grid displays log entries (in reverse chronological order) that audit the progress of a To Do entry. You cannot modify or delete log entries that have been created by the system. You can manually add a log entry of type User Details and you may remove a log entry before it is saved. Once a User Details log entry is saved, you cannot modify or delete it.

The Log grid displays the following information:

Log Date/Time displays the date and time when the log entry was created.

Log Type indicates the To Do entry event for which the log entry was created. For example, when the To Do entry is created, the Log Type indicates Created. For more information refer to the Log Entry Events table below.

The Details column contains user-specified or system-generated information about the log entry. This field is blank for some types of log entries.

Log User displays the user who caused the log entry to be created.

Assigned To displays the user to whom the To Do entry was assigned (if any).

To Do Entry - Keys/Values

The Keys / Values page contains detailed information about the sort keys and drill keys associated with a To Do entry. This information may not be modified. It is shown to assist support personnel.

Use Menu > To Do > To Do Entry > Search to search for the desired To Do entry, then navigate to the Keys/Values page.

Description of Page

The Sort Keys grid contains an entry's sort keys and values. This information is display-only.

Fastpath: Refer to To Do Type - Sort Keys for more information.

The Drill Keys grid contains an entry's drill keys and values. This information is display-only.

Fastpath: Refer to To Do Type - Drill Keys for more information.

To Do Entry Actions

You can perform the following actions on a To Do Entry.

Next in This Section

- Complete

- Forward

- Send Back

- Log Entry Events

Complete

Clicking Complete causes the To Do entry's status to be Completed. When you complete a To Do, a log entry is created that indicates when the To Do was completed and by whom. This button is enabled for To Do entries with a status of Open or Being Worked On.

Fastpath: Refer to The Lifecycle Of A To Do Entry for more information.

Forward

Clicking Forward causes the Forward To Do Entry dialog to appear, allowing you to forward the To Do to another user or role. This button is enabled for Open To Do entries assigned to a role to which you belong or Being Worked On To Do entries assigned to you.

Send To indicates whether the To Do will be forwarded to a Role or User (the default).

User appears if Send To is set to User. The User indicates the user to which this To Do entry will be forwarded. The user must be a member of one of the roles specified for the To Do type.

Role is enabled if Send To is set to Role or if set to User and a User is specified. It indicates the role to which this To Do entry will be forwarded. Only users of the specified role will be able to view and work on the To Do entry. The role is defaulted from the To Do type. You can only forward the To Do entry to one of the roles specified on the To Do type. If forwarding to a user the role must also be valid for the specified user.

The Details field provides an explanation of why a user is forwarding the To Do. This information appears in the To Do log.

Click OK to forward the To Do entry.

Send Back

Clicking Send Back causes the Send Back To Do Entry dialog to appear, allowing you to send back the To Do to the user who forwarded it to you. This button is enabled if the To Do entry's status is Being Worked On and it was forwarded to you by another user.

User is a display only field that indicates the user who assigned you the To Do.

Role may be used to also change the entry's To Do Role. The role must be a permissible role specified on the To Do type that is also valid for the user this entry is sent back to. By default, if the sent to user is not a member of the entry's current role, the system automatically defaults the role to the first permissible role that is also valid for the user.

The Details field provides an explanation of a why the user is sending back the To Do or any other desired information. This information appears in the To Do log.

Click OK to send the To Do back to the assigning user.

Log Entry Events

The following table contains the events that cause a log entry to be created by the system.

Event

Log Type

To Do Entry Status

Content of Details

Content of Assigned To (on To Do entry and To Do Log)

Log User ID

Contents of Sent By (on To Do entry)

A To Do is created (by the system or by a user)

Created

Open

ID of user who created the To Do

A To Do is created (by the system or by a user) in Being Worked On status

Created

Being Worked On

User ID of user who was assigned this To Do

ID of user who created the To Do

Creating user's ID

A To Do is completed (by the system or by a user)

Completed

Complete

ID of user who completed the To Do

A user takes an open To Do

Assigned

Being Worked On

Selected by user

Assigned To User ID

Assigned To User ID

ID of user who assigned the To Do

A supervisor assigns a To Do to a user (also happens if they reassign)

Assigned

Being Worked On

Assigned to user

Assigned To User ID

ID of user who assigned the To Do

ID of user who assigned the To Do

A user forwards an entry to a user

Forwarded

Being Worked On

Log details entered by user

Forwarded To User ID

ID of user who forwarded the To Do

ID of user who forwarded the To Do

A user forwards an entry to a role

Forwarded

Open

Forwarded to role Role Description (Role ID) + Log details entered by user

ID of user who forwarded the To Do

ID of user who forwarded the To Do

A user sends back a To Do

Sent back

Being Worked On

Log details entered by user

Sent Back To User ID

ID of user who sent back the To Do

ID of user who sent back the To Do

A user adds a log entry

User Details

Status remains the same

Log details entered by user

ID of user who added the entry

A user manually overrides priority

Override Priority

Status remains the same

Priority changed from < old value> to < new value>

Assigned To User ID

ID of user who made the change

To Do Search

This page allows you to search for To Do entries using various search criteria, and perform various actions on selected ones.

Note: No restriction by role. This page returns all To Do entries that meet the search criteria, regardless of the To Do entry's role. Using the search, a user may drill into the details of a To Do entry even if the To Do is not assigned to the user. Refer to To Do Entries Reference A Role for more information about roles.

Fastpath: We recommend familiarizing yourself with the topics described in The Big Picture of To Do Lists to fully appreciate how To Do entries are managed by the system.

Next in This Section

- To Do Search - Main

- To Do Search Actions

To Do Search - Main

Use Menu > To Do > To Do Search to open this page.

The top half of the page is where you enter the criteria used to search for To Do entries.

Note: Multiple search criteria may be specified. You can search for To Do entries using a combination of search criteria. For example, if you enter both a To Do Type of TD-NOMR and a Status of Being Worked On, only those To Do entries for To Do type TD-NOMR that are currently Being Worked On are displayed.

CAUTION:

Try to be as specific as possible when entering search criteria. Why? Because entering open-ended search criteria may have a severe impact on response times.

The following table describes each of the different search filters.

Search Filter

Description

Related To Do

If you're searching for potentially related entries for a given To Do entry, choose Specific To Do for the Related To Do Filter. Enter the To Do ID.

A filter value of Not Applicable defaults.

To Do Type

If you're searching for a To Do entry and you know the value of a To Do Type linked to the To Do entry, choose Specific To Do Type for the To Do Type Filter. Enter the To Do Type.

A filter value of All defaults.

Char Type

If you're searching for a To Do entry and you know the value of a characteristic linked to the To Do entry, choose Specific Char Type for the Char Type Filter. Enter the Characteristic Type and Characteristic Value.

A filter value of Not Applicable defaults.

Only characteristic types that include a characteristic entity of To Do Entry and that have been marked to allow searching by characteristic value are available.

User

Use this search method if you know the Created By User, Assigned To User or Completed By User for the To Do entry. Enter the appropriate User Id.

A filter value of Not Applicable defaults.

Date Range

Use this field if you're searching for a To Do entry and know the Date Created or Date Completed.

A filter value of Date Created defaults. The Start Date/Time defaults to the current date, 12:00AM and the End Date/Time defaults to the current date, 11:59PM.

If you enter a Date Range Filter of All, the system ignores this search method.

Status

Use this search method to restrict the search to To Do entries with a specific status value. You may search for To Do entries in the status of Open, Being Worked On or Completed. You may also perform a combination search for To Do entries that have a status value of either Open or Being Worked On.

A filter value of All defaults.

Note: The system allows any combination of values. The system does not try to validate your search combinations, even if they do not make sense. For example, if you enter a User Filter value of Completed By User and a Status Filter value of Open, you will not get an error. In this case, the system will find no records that match your criteria (because To Do entries that are Open do not have a Completed By User).

The system shows the total number of To Do entries that satisfy your search results immediately below the grid.

The first group of To Do entries is displayed in the grid at the bottom of the page.

- Click the Select All button to select all entries displayed in the grid. Click the Clear All to remove the selections in the grid.

- Use the checkbox if you want to assign, reopen or complete specific entries. Only Open or Being Worked On entries may be selected.

Fastpath: Refer to To Do Search Actions and the How To section for more information on using these actions.

- A Comment icon appears if there are comments on the To Do item and a Log Entry icon appears if there is a log entry of type Forwarded, Sent Back or User Details on the To Do item. This column appears if at least one To Do item has either comments or a special log entry. Use either icon to navigate to the To Do entry page.

- Entries are sorted by their Priority. Highest in priority are listed first.

- Create Date/Time contains the date and time the To Do entry was created by the system. Use the hyperlink to navigate to the To Do entry page.

- Click the number of Related entries hyperlink to redisplay this page listing potentially related entries to the current entry.

- Last Assigned Date/Time contains the date and time the To Do entry was most recently assigned to a user, if applicable, along with the Assigned To user.

- Message contains a description of the To Do entry. If the To Do entry is in the status of Open or Being Worked On, the message description allows you to drill into the page on which the entry's respective object is displayed. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched. Refer to Working On A To Do Entry for more information.

Note: Current To Do. Drilling into the page by clicking the Message hyperlink does not automatically assign Open To Do entries to the user (as the To Do List page does when clicking on the Message). But it does treat this as the user's current to do, enabling To Do related toolbar icons. Refer to A User's Current To Do for more information.

- Status contains the current status of the To Do entry.

- Completion Date/Time contains the date and time the To Do entry was completed and the user who completed the entry, if applicable.

- To Do Type contains a description of the To Do type for the To Do entry.

To Do Search Actions

You can perform the following actions on selected To Do Entries.

Next in This Section

- Assign Selected Entries

- Reopen Selected Entries

- Complete Selected Entries

Assign Selected Entries

Use the Assign button to assign or reassign the selected entries to a user. Enter a user ID or search for a user using the Assign To User field. By default this field is populated with the current user's ID. Note that the user's current number of assignments is displayed adjacent.

Upon successful processing, the selected entries are assigned to the specified user and the status of Open entries becomes Being Worked On. Additionally, a corresponding log entry is added to each To Do.

Note: Only users with Supervisor Assignment access rights may reassign entries that are not currently assigned to them.

Reopen Selected Entries

Use the Reopen button to unassign the selected entries from their users forwarding them back to their role.

Upon successful processing, the selected entries become Open and a corresponding log entry is added to each To Do.

Complete Selected Entries

Use the Complete button to complete the selected entries.

Upon successful processing, the selected entries become Completed and a corresponding log entry is added to each To Do.

Fastpath: Refer to The Lifecycle Of A To Do Entry for more information.

How To

The following sections describe how to perform common tasks for To Dos.

Next in This Section

- How To Assign a To Do to a User

- How To Work on To Do Entries

- How To Add a New To Do

- How To Complete To Dos

- How To Forward a To Do

- How To Send Back a To Do

- How To Add a Log Entry to a To Do

How To Assign a To Do to a User

There are several ways to assign a To Do entry to a user:

- A supervisor can use the Supervisor Functions pages to review, assign and reassign To Dos to users.

- The Supervisor To Do Summary page summarizes by type the total, Open (unassigned) and Being Worked On (assigned) entries for roles to which you belong.

- The Total, Open or Being Worked On column hyperlinks transfers you to the Supervisor To Do Assignment page where you can assign / reassign one or more of the corresponding entries to a specific user.

- Use the To Do List Functions pages to review and assign To Dos to yourself.

- The To Do Summary page summarizes by type the total, Open (unassigned) and Being Worked On (assigned to you) entries for roles to which you belong.

- The Open column hyperlink transfers you to the To Do List page where you can assign one or more of the Open entries to yourself.

- You may also use the To Do Search page to find certain To Do entries based on various criteria and assign selected entries to a user.

- Forwarding an entry to a user using the To Do Entry page is yet another way of assigning an entry to a user.

- The Current To Do zone next assignment functionality can be configured to dynamically assign an Open To Do to the requesting user based on your organization's work assignment rules. Refer to this zone for more information.

How To Work on To Do Entries

Depending on your organization's work distribution practice, there are several ways to work on To Do entries.

When work is manually assigned, a typical approach may be to review the entries in a list and work them one entry at a time.

- You can use the To Do List page to review and work on To Do entries by list type.

- You may also use the To Do Search page to find certain To Do entries based on various criteria and work on selected entries. For example, you may want to review and work on entries related to a given To Do.

Regardless of the above methods to define your work list, when ready to work on a specific entry, drill into its respective page using the message description hyperlink. Drilling into an entry from the above work lists makes it your current To Do entry. This entry's key information is displayed on the Current To Do dashboard zone and you may use special action bar buttons to scroll through your work list to the next and previous entries respective to your current To Do.

Fastpath: Refer to Working On A To Do Entry for more information.

When work is assigned "on demand", click the Current To Do icon, , on the Current To Do dashboard zone to request your next task. The returned To Do entry automatically becomes your current To Do. The entry's key information is displayed on the zone but since the entry was no selected from a work list the next and previous action bar buttons are disabled.

Fastpath: Refer to Current To Do zone to learn about all the functions it provides to efficiently resolve the current To Do and potentially other To Do entries that may be related to it.

Resolve the current To Do by fixing the problem indicated in the message and mark the entry as Complete.

Fastpath: Refer to How To Complete To Dos for more information.

How To Add a New To Do

If your system is configured with manual To Do types, you can add a To Do entry online. Online To Do entries may be used like electronic help tickets in the system. In Oracle Utilities Customer Care and Billing, for example, if you are having a problem starting service, you can create a To Do that describes the problem. The To Do can be assigned to a help resolution group that could either resolve the problem or send the To Do back to you with information describing how to resolve the problem.

Fastpath: Refer to To Do Entry - Add Dialog for more information.

How To Complete To Dos

When you complete a To Do, a log entry is added that indicates when the To Do was completed and by whom.

There are multiple ways in which you can complete a To Do.

- The To Do List page allows you to complete one or more selected entries of a specific To Do Type.

- The To Do Search page allows you to search for To Do entries using various search criteria and complete selected ones.

- Use the To Do Entry page to complete a single To Do Entry.

- You may also use the Current To Do zone to complete the current entry you are working on and/or all related entries assigned to you.

- The system automatically completes some To Do entries. For To Do entries that are logically associated with the state of some object, the system automatically marks the entry Complete when the object is no longer in the respective state. In Oracle Utilities Customer Care and Billing for example, an entry that's created when an account doesn't have a bill cycle is completed when the account has a bill cycle.

Note: The automatic completion of To Do entries occurs when the To Do entry process responsible for creating entries of a given type is executed. Therefore, if these processes run only once per day, these entries remain Being Worked On even if the object is no longer in the respective state.

How To Forward a To Do

If you have been assigned a To Do that you are unable to resolve, you can forward it to another user or role for help or additional instructions. When a To Do is forwarded, a log entry indicates who forwarded the To Do, to whom it was forwarded, and the specified reason.

- Use the Forward button on the To Do Entry page to forward a To Do entry to a role or a user.

- You may also use the Reopen button on the To Do Search page to forward selected entries back to their current role.

How To Send Back a To Do

If you have been forwarded a To Do by another user, you may send back the To Do with instructions to the forwarding user. When a To Do is sent back, a log entry is created that indicates when the To Do was sent back and by whom.

Use the Send Back button on the To Do Entry page to send back a To Do entry.

How To Add a Log Entry to a To Do

You can use the Comments section of a To Do entry to add a comment to the To Do as long as the To Do is Open or Being Worked On. However, the Comments field is disabled if the To Do entry is complete.

Alternatively, you can add a User Details log entry to a To Do at any time (even after it's completed). Refer to To Do Entry page for more information.

Reports

The following section describes the functionality provided for submitting reports on-line and for viewing reports submitted through a third party reporting tool.

Fastpath: For information about this functionality, see The Big Picture of Reports.

Next in This Section

- On-line Report Submission

- Viewing Historic Reports

On-line Report Submission

The on-line report submission page enables you to request a specific report to be run. This is only available if your system is able to integrate with your third party reporting system on-line. The system comes configured to integrate with BI Publisher.

Next in This Section

- Report Submission - Main

Report Submission - Main

This page allows you to submit a report on-line. Navigate to this page using Menu > Tools > Report Submission..

Description of Page

To submit a report, choose the Report Code for the process you wish to submit. Refer to Defining Report Definitions for information about defining reports in the system.

A description of the report is displayed.

The parameters defined for the report on the report definition page are displayed in the grid. To see a description of a parameter, use the search button adjacent to the parameter label.

Note: Default note. The default values displayed for the parameters are defined on the report definition page.

When you have entered the appropriate parameter values, click the Submit button to submit the report. Refer to How To Request Reports for more information.

Note: Reports submitted via the on-line report submission page are not logged in the report history repository and are therefore not visible from the report history page. Only reports submitted through your third party reporting tool's batch scheduler are logged in the report history, if supported by the tool.

Viewing Historic Reports

If your third party reporting tool stores historic copies of reports in a repository, you may configure the system to allow a user to view these historic reports on-line.

Note: This page currently does not display historical reports for BI Publisher.

Next in This Section

- Report History - Main

Report History - Main

This page allows you to view a report stored in your third party reporting tool's report repository, if supported. Navigate to this page using Menu > Tools > Report History.

Description of Page

The top part of the page shows the Report Code, Description and Long Description for the selected report.

To select a report, search by either Report Code or Description and click the adjacent search button. The reports matching your search criteria are displayed. Choose the desired report from the selection list.

Note: Displaying Report History. When you choose a report, the system needs to interface with your reporting software to display a list of historical occurrences of this report.