SGG SOM Configuration Guide v2 1-0-3123

Oracle Utilities Smart Grid Gateway
Service Order Management

Configuration Guide
Release 2.1.0 Service Pack 3
E63089-01
May 2015
Oracle Utilities Smart Grid Gateway/Smart Grid Gateway Installation and Configuration Guide, Release 2.1.0
Service Pack 3
E63089-01
Copyright © 2011, 2015 Oracle and/or its affiliates. All rights reserved.
Primary Author: Lou Prosperi
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.
Contents
Chapter 1
Overview............................................................................................................................................................. 1-1
What Is This Book?........................................................................................................................................................ 1-2
Other Documentation................................................................................................................................... 1-2
Oracle Utilities Application Framework Configuration Tools................................................................................ 1-4
Chapter 2
Understanding Service Order Management..................................................................................................... 2-1
Service Order Management Overview ........................................................................................................................ 2-2
What is Service Order Management?.......................................................................................................... 2-2
How Does Service Order Management Work?......................................................................................... 2-2
Supported Service Order Processes ............................................................................................................ 2-3
Understanding Service Order Orchestration Activities............................................................................................ 2-7
Understanding Service Order Processing................................................................................................... 2-7
Are SP and Device Ready? - Algorithm Types.......................................................................................... 2-9
Service Order Management Service Providers ........................................................................................ 2-16
Understanding Field Activities ................................................................................................................................... 2-18
What are Field Activities? ........................................................................................................................... 2-18
How Do Field Activities Work? ................................................................................................................ 2-18
Field Task Types .......................................................................................................................................... 2-19
Field Activity Processing and Communication ....................................................................................... 2-20
Unrelated Pickup Orders ............................................................................................................................ 2-29
Understanding Smart Meter Commands .................................................................................................................. 2-30
Service Order Orchestration Activities In Detail .................................................................................................... 2-31
Smart Grid Gateway Base Package Service Order Orchestration Activity Business Objects ......... 2-31
Example Service Order Orchestration Activity - D1-EnableService .................................................. 2-32
Field Activities In Detail.............................................................................................................................................. 2-34
Service and Measurement Data Foundation Base Package Field Activity Business Objects........... 2-34
Example Field Activity - D1-FieldActivity .............................................................................................. 2-34
Base Package Field Task Types ................................................................................................................. 2-36
Field Activity Task Types - Base Package Processing Scripts............................................................... 2-37
Field Activity Task Types - Base Package Field Activity Completion Events ................................... 2-38
Example Field Task Type - D1-ConnectSPAtMeter.............................................................................. 2-39
Service Order Operational Dashboards.................................................................................................................... 2-40
Service Order Activity Aggregation .......................................................................................................... 2-40
Batch Processing .......................................................................................................................................... 2-42
Service Order Management Master Configuration................................................................................. 2-43
Service Order Management Integrations.................................................................................................................. 2-46
Oracle Utilities Customer Care and Billing to Service Order Management ....................................... 2-46
Service Order Management to Oracle Utilities Mobile Workforce Management ............................. 2-47
i
Chapter 3
Service Order Management Process Configuration ......................................................................................... 3-1
Data Setup for All Processes ........................................................................................................................................ 3-2
Customer Care and Billing............................................................................................................................ 3-2
Service Order Management.......................................................................................................................... 3-3
Mobile Workforce Management.................................................................................................................. 3-4
Enable Service for Meters ............................................................................................................................................. 3-5
Customer Care and Billing............................................................................................................................ 3-5
Service Order Management.......................................................................................................................... 3-6
Mobile Workforce Management.................................................................................................................. 3-8
Enable Service for Items ............................................................................................................................................. 3-10
Customer Care and Billing.......................................................................................................................... 3-10
Service Order Management........................................................................................................................ 3-11
Mobile Workforce Management................................................................................................................ 3-13
Disable Service for Meters .......................................................................................................................................... 3-15
Disable Service for Items ............................................................................................................................................ 3-20
Cut Service for Non-Payment for Meters ................................................................................................................ 3-24
Cut Service for Non-Payment for Items .................................................................................................................. 3-29
Reconnect Service for Payment for Meters.............................................................................................................. 3-34
Reconnect Service for Payment for Items................................................................................................................ 3-39
Meter Exchange............................................................................................................................................................ 3-44
Item Exchange .............................................................................................................................................................. 3-51
Back-to-Back for Meters ............................................................................................................................................. 3-56
Cancel Orchestration for Meters ............................................................................................................................... 3-61
Update Orchestration for Meters .............................................................................................................................. 3-62
ii
Chapter 1
Overview
This chapter provides an overview of this configuration guide and an introduction to the Oracle
Utilities Smart Grid Gateway adapter for Itron OpenWay, including the following:
• What Is This Book?
• Other Documentation
• Oracle Utilities Application Framework Configuration Tools
Overview 1-1
What Is This Book?
What Is This Book?

This guide describes how to configure the Oracle Utilities Smart Grid Gateway Service Order
Management It is intended for implementers and system administrators responsible for
configuration and initial setup of the application.
The Oracle Utilities Smart Grid Gateway Service Order Management is based on the Oracle
Utilities Application Framework (OUAF). For information about using and configuring basic
Framework functions, see the Oracle Utilities Application Framework documentation. This guide
only covers configuration of functions specific to the Oracle Utilities Smart Grid Gateway adapter
for Itron OpenWay.
The body of this guide presents conceptual information to help you understand how the system
works as well as how the various configuration options affect system functionality. Once you have
an understanding of the system's capabilities, you can plan your data setup and design any
customizations you want to implement.
This guide includes the following chapters:
• Chapter 1: Overview (this chapter) provides an overview of the Oracle Utilities Smart Grid
Gateway adapter for Itron OpenWay architecture and of the configuration tools and process
used in implementing the product.
• Chapter 2: Understanding Service Order Management describes the Service Order
Management functionality and provides an overview of the service order-related objects and
how they are used in the system, along with technical details concerning related maintenance
and business objects.
• Chapter 3: Service Order Management Process Configuration provides an overview of
configuration data required to support the service order processes available with Service
Order Management.
Other Documentation
This section describes other documentation provided with the Oracle Utilities Smart Grid
Gateway Service Order Management.
Installation Documentation
Installation documentation describes the steps involved in the installation and initial set up of the
system, and includes the following documents:
• Oracle Utilities Smart Grid Gateway Quick Install Guide
• Oracle Utilities Smart Grid Gateway DBA Guide
• Oracle Utilities Smart Grid Gateway Installation Guide
User Documentation
User documentation provides conceptual information and procedures related to working with the
various objects used in the system, and includes the following documents:
• Oracle Utilities Application Framework Business Process Guide
• Oracle Utilities Application Framework Administration Guide
• Oracle Utilities Service and Measurement Data Foundation User’s Guide
Supplemental Documentation
Supplemental documentation provides technical information related to system administration
tasks and include the following documents:
• Oracle Utilities Smart Grid Gateway Server Administration Guide
1-2 Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide
What Is This Book?
• Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

• Oracle Utilities Smart Grid Gateway Configuration Guide
The Oracle Utilities Smart Grid Gateway Service Order Management uses Oracle Business
Process Execution Language (BPEL) as middleware components. These tools are part of the
Oracle SOA Suite. See the Oracle SOA Suite Documentation library (http://www.oracle.com/
technetwork/middleware/soasuite/documentation/index.html) for more information about
using these tools.
Embedded Help
Oracle Utilities Smart Grid Gateway, like all Oracle Utilities Application Framework applications,
provides extensive internal documentation. For example, detailed descriptions of system objects
are included in the objects' maintenance portals. The lifecycle of each business object is described
on the Lifecycle tab and depicted in flow diagrams on the Summary tab. This information is
extremely useful for implementers and system administrators.
Embedded help is provided for all non-obvious fields in most portals and zones. If a field has
associated help text, a ? icon appears next to the field when the zone is displayed.
Online Help
Oracle Utilities Smart Grid Gateway also includes context-sensitive help for all the user interface
screens users will typically work with as they use the system. Online help contains conceptual
information and procedures related to working with the various objects used in the system.
The online help is divided into the following three sections:
• Oracle Utilities Application Framework: Describes the features and functions of the
application framework (F1)
• Oracle Utilities Service and Measurement Data Foundation: Describes the features and
functions provided in the service and measurement data foundation (D1)
Overview 1-3
Oracle Utilities Application Framework Configuration Tools
Oracle Utilities Application Framework Configuration Tools

Please refer to the general configuration guide for information on the Oracle Utilities Application
Framework (OUAF) configuration tools that can be used to create and customize system entities,
such as business objects, portals, zones, and UI maps. Refer to the Oracle Utilities Application
Framework configuration tools documentation for instructions on using tools such as:
• Configuration Process Overview
• Data Areas
• Algorithms
• Entity Naming Conventions
This configuration guide does not duplicate the concepts and procedures presented in the Oracle
Utilities Application Framework configuration tools documentation; rather, it will identify the
specific objects used by the Oracle Utilities Smart Grid Gateway adapter for Itron OpenWay that
can be configured and customized using the configuration tools, as well as application parameters
and objects that can be managed within the application components themselves.
This guide assumes that all individuals responsible for system configuration and implementation
will be familiar with the Oracle Utilities Application Framework and will have completed training
on the Oracle Utilities Application Framework Configuration Tools.
1-4 Oracle Utilities Smart Grid Gateway Adapter for Itron OpenWay Configuration Guide
Chapter 2
Understanding Service Order Management
This chapter provides a description of the Oracle Utilities Smart Grid Gateway Service Order
Management. This chapter includes:
• Service Order Management Overview
• Understanding Service Order Orchestration Activities
• Understanding Field Activities
• Service Order Orchestration Activities In Detail
• Field Activities In Detail
• Service Order Operational Dashboards
• Service Order Management Integrations
Understanding Service Order Management 2-1

Service Order Management Overview

This section provides an overview of Oracle Utilities Service Order Management, including:
• What is Service Order Management?
• How Does Service Order Management Work?
• Supported Service Order Processes
What is Service Order Management?

Service order management provides functionality that orchestrates field activities and smart meter
commands necessary to change the state of service at a service point. This can involve
complicated business logic due to numerous, often continually-changing variables, such as:
• The type of service order request (i.e. enable service, disable service, cut, reconnect, back-to-
back)
• Whether the service point is connected to the source of power
• If there is a device installed, and if so, whether it's a non-smart or a smart meter, OR item
• The state of the device that is installed at the service point (e.g., pre-commissioned,
connected, disconnected)
• For smart meters, the head-end system that manages the device at the service point
• For non-smart scalar meters, the proximity of the scheduled read date to the start date
Additionally:
• Every implementation performs field work request differently (e.g., a cut service for non-
payment is done differently in every locale)
• Every head-end vendor requires different messages (both in terms of the number and type of
messages) and these requirements change over releases of their software
• Field workers may perform different efforts other than those requested by the system. For
example, the system might request a simple reading and the worker may decide to do an
exchange because the meter is old / broken.
• The source system may cancel the service order request after it is scheduled or even after it
has been dispatched
Service order management has been designed to address all of the above concerns, and provides a
flexible and configurable solution to the challenge of managing customer service requests.
How Does Service Order Management Work?

At a high level, service order management handles requests for service as follows:
Receive / Create Service Order Request

A service order request is created and/or received. This can be as a result of a customer requesting
a change to their service such as enabling or disabling service when moving into or out of a
residence, but can also be the result of other business processes, such as a request to cut service
due to non-payment.
Regardless of the origin of the request, a service order request is created in a customer
information system (CIS) such as Oracle Utilities Customer Care and Billing), which in turn is sent
to Service Order Management.
2-2 Smart Grid Gateway Configuration Guide

Create Service Order Activity

When Service Order Management receives the service order request, a service order orchestration
activity is created. This activity will manage and orchestrate any/all other activities needed to fulfill
the original service request.
Evaluate Service Point and/or Meter

The service order orchestration activity then evaluates the current state of the service point, meter,
or item, and determines the appropriate action(s) to take to fulfill the service request.
Create Activities as Needed / Appropriate

Based on the evaluation of the service point/meter/item, the orchestration activity creates one or
more activities as needed.
• Field Activities involve sending workers into the field to perform service. This can include
meter installation, meter replacement, and other activities.
• Command Activities are smart meter commands used to remotely change the state of the
meter. This can include connect, disconnect, checking the device status (ping), or requesting
an on-demand reading.
Following each of activities, the orchestration activity re-evaluates the state of the service point/
meter/item to determine the next appropriate action(s) required to fulfill the original service
request.
For example, when enabling service at a service point with a smart scalar meter, a typical scenario
might involve the following:
1. Field Activity - Install Meter
2. Command Activity: Commission Device
3. Command Activity: Remote Connect
4. Command Activity: On Demand Read - Scalar
Update Requesting System

When the orchestration activity determines that everything necessary to satisfy the service order
request is ready, the orchestration activity will inform the requester and complete the original
request.
Send Notification to Subscribing Systems

The orchestration activity can also be configured to send notifications to other subscribing
systems regarding the status of the service point/meter/item.
Supported Service Order Processes

Service Order Management supports the following service order processes as part of the base
package.
Enable Service
Enable Service is a request to start service for a particular service point. It is typically initiated
from a CIS application.
A "Start Service" field activity request from a CIS for a meter will result in the creation of an
"Enable Service" orchestration activity in Service Order Management. The "Enable Service"
orchestration activity will initiate field activities and smart meter commands necessary to change
the state of service at a service point to the enabled state and confirm an initial measurement
exists.

For example, a service order request is received to start service for a meter, the following field
activities smart meter commands may occur:
• If there is no meter at the service point and the service point is not connected as the source, a
field activity will be created to connect the service point to its source and install the meter.
• If a smart meter exists at the service point, but it is in a disconnected state, a smart meter
command will be sent to the appropriate head-end system to connect the meter.
• If there is a non-smart (manual) meter at the service point and it's on, a field activity will be
created to request the reading on / near the start date (assuming that the next scheduled
meter read date is not close to the start date).
Disable Service
Disable Service is a request to stop service for a particular service point. It is typically initiated
from a CIS application.
A "Stop Service" field activity request from a CIS for a meter will result in the creation of an
"Disable Service" orchestration activity in Service Order Management. The "Disable Service"
orchestration activity will initiate field activities and/or smart meter commands necessary to
change the state of service at a service point to the disabled state and confirm a final measurement
exists.
For example, a service order request is received to stop service for a meter, the following field
activities and smart meter commands may occur:
• If there is a non-smart (manual) meter at the service point and it's on, a field activity will be
created to turn off the meter
• If a smart meter exists at the service point and its state is connected/commissioned, a smart
meter command will be sent to the appropriate head-end system to perform a remote
disconnect of the meter
Cut for Non-Payment

Disconnect for non-payment is a type of field work that is most often initiated from a collections
process that has been created from within the Credit and Collections module within Oracle
Utilities Customer Care and Billing. A collections process is created when it has been determined
to be past due, and one of the methods for eliciting payment is to issue a disconnect.
A "Disconnect for Non-Payment" field activity request from Oracle Utilities Customer Care and
Billing will result in the creation of a "Cut Service for Non-Payment" orchestration activity in
Service Order Management. The "Cut Service for Non-Payment" orchestration activity will
initiate field activities and/or smart meter commands necessary to change the state of service at a
service point to the disabled state.
For a "Cut for Non-Payment" service order, the orchestrations steps will include determining if a
smart meter command can be executed or if a request to a mobile field work application (such as
Oracle Utilities Mobile Workforce Management) to dispatch a truck needs to be executed.
Another example might be to determine if a disconnect can be executed against a service point
given based on specific criteria of the service point. Such rules might include determining if there
is life support equipment at the premise, or if the service point can be disconnected at the current
time of year or business hours based on utility defined rules taking into account predominant
weather conditions (for instance, the utility cannot disconnect someone in the dead of winter of
the service point resides at a certain zip code that is affected by extreme cold weather).
Reconnect for Payment

Reconnect Service for Payment is a request to restart service for a particular service point after
customer has paid off their past due balance. It is typically initiated from the Credit and
Collection's Severance Process in a CIS application such as Oracle Utilities Customer Care and
Billing

A "Reconnect for Payment" field activity request from the CIS will result in the creation of a
"Reconnect Service for Payment" orchestrator activity in Service Order Management. The
"Reconnect for Payment" orchestration activity will initiate field activities and/or smart meter
commands necessary to change the state of service at a service point to the enabled state.
For example, if a service order request to reconnect service is received for a meter service, the
following field activities and smart meter commands may ensue:
• If there is a non-smart (manual) meter at the service point and it's turned off, a field activity
will be created to turn on the meter
• If a smart meter exists at the service point, but it is in a disconnected state, a smart meter
command will be sent to the appropriate head-end system to connect the meter
Meter Exchange
Meter Exchange service is basically an exchange of an old meter with a new meter. A meter
exchange request may be initiated as the result of a smart meter rollout, an individual customer's
smart meter opt-out, a meter no longer working correctly, a meter reaching the end of its expected
life, a customer with a manual meter enrolling in a program that requires a smart meter, or a need
to upgrade measurement capabilities etc.
Meter exchanges can be initiated from a variety of applications, including a CIS such as Oracle
Utilities Customer Care and Billing, Service Order Management (internally), and an asset
management system such as Oracle Utilities Operational Device Management. Meter exchange
requests can also be requested as pick-up orders from a field work application such as Oracle
Utilities Mobile Workforce Management.
Meter Exchanges involving smart meters will involve smart meter commands in addition to field
activities. A requesting system should be able to optionally provide some input as to the type of
meter needed, and depending upon the requesting system, this input could be specific (the type of
configuration) or general (smart or manual).
Back-to-Back
Back to Back service is basically service disablement and enablement in single step. The main
purpose of this service is to minimize the dispatching (and obviously cost) of field work to obtain
readings for both start and stop event for correct billing to the customer.
An example of a back-to-back scenario would involve an outgoing tenant calling their utility
company for a move-out and an incoming tenant calls for a move-in at the same premise. As long
as the gap period during which the premise is vacant is within the utility company's threshold, the
change would be considered as a back to back event. In this case, a single field task is dispatched to
take the meter reading used for this event and typically initiated from a CIS application.
A "Back to Back Service" field activity request from a CIS for a premise will result in the creation
of a "Back to Back Service" orchestration activity in Service Order Management. The "Back to
Back Service" orchestration activity will initiate field activities and smart meter commands
necessary to change the state of the service of both customers at a service point to the desired
state and confirm that the measurements exists for that period.
Canceling Service Order Requests

Cancel service is basically cancels any orchestration and/or specific activities that are in progress.
If the cancel is for orchestration activity then that orchestration activity along with corresponding
activities will be discarded where as if the cancel is initiated for a specific activity then only that
specific activity will be discarded.
Depending on the status of the specific activity, the "Cancel Orchestration" orchestration activity
will either discard the activity or an outbound communication will be sent to the field work system
to request a cancel of the specific activity. Once the cancel to the field work system is confirmed as
successful the "Cancel” will also cancel the parent orchestration activity and/or specific activities.

If the cancel is not successful then the “Cancel" orchestration activity will be discarded. When it is
discarded, it will send a response message to the requester indicating the cancel was unsuccessful.
If cancel service is for field work system then "Cancel" orchestration activity will be initiated and a
Cancel Command will be initiated in case of smart meter commands.
Cancellation of service can be initiated from a variety of applications, including a CIS such as
Oracle Utilities Customer Care and Billing, Service Order Management (internally), and an asset
management system such as Oracle Utilities Operational Device Management. Cancellation of
service can also be requested as pick-up orders from a field work application such as Oracle
Utilities Mobile Workforce Management.
Updating Service Order Requests

Update service is basically handles requests for updates to an existing enablement, disablement,
cut for nonpayment, and reconnect for payment orchestration activity and their related specific
field activities.
The types of data available for update include the following:
• Instructions
• Comments
• Start Date/Time
• Contact Name
• Main Phone.
Additionally, an update service request can check to see if appointment information is different
between the specific activity and the update orchestration activity.
Depending on the status of the specific activity both direct updates will be made to the activities
and communications within Service Order Management or an outbound communication will be
sent to the field work system to request an update of the specific activity fields that have been
changed.
Once that update to the field work system is confirmed as successful the "Update" orchestration
activity service will also update the "Enable Service" or "Disable Service" orchestration activities
as well. If the updates are not successful the "Update Service" orchestration activity will be
discarded. When it is discarded, it will send a response message to the requester indicating the
update was unsuccessful.
Update service requests can be initiated from a CIS such as Oracle Utilities Customer Care and
Billing or Service Order Management (internally).

Understanding Service Order Orchestration Activities

This section describes service order orchestration activities and how they manage the service
order process.
Understanding Service Order Processing

To understand how service order orchestration activities manage the service order process, it’s
important understand the lifecycle of orchestration activity business objects.
Service Order Orchestration Activity Lifecycle

All service order orchestration activity business objects share a common parent business object
that defines their lifecycles. This is the Service Point Activity Orchestration business object (D1-
SPActivityOrchestration). The table below outlines the lifecycle for this business object.
State Description
Pending The initial state for orchestration activities.
An Enter algorithm sends an acknowledgement to the

requesting system.
The activity is transitioned to the next state via a monitor

process.
Validate Enter algorithms perform the following:

• Validate Activity Type
• Validate Service Point
• Check for a non-final duplicate service order request
activity for the same service point.
Validation Error If the business object fails any of the validations in the
Pending state, it enters this state.
Activities in this state can be corrected and retried.
Discarded Activities discarded in other states enter this state.
Enter algorithms perform the following:

• Validate that non-final child activities can be discarded
without the need for a cancel activity
• Cancel non-final child activities
• Send a failure notification to the requesting system
Waiting for Effective Date If an orchestration activity has a future effective date, it
remains in this state until the effective date is reached.
A Monitor algorithm transitions the activity to the next state

when the activity's effective date time is reached (process date
time >= effective date time).

State Description
Are SP and Device Ready? Each type of orchestration activity business object has a
unique set of Enter algorithms that perform operations as
appropriate for the type of service order request.
See Are SP and Device Ready? - Algorithm Types on page

2-9 for more information about these algorithms.
Activity in Progress Orchestration activities remain in this state while their child
activities are processed.
A Monitor algorithm transitions the activity to the "Are the SP

and Device Ready?” state if there are no non-final child
activities related to the current activity.
A Monitor algorithm validates that the orchestration activity

has not been in its current state for too long, based on the
Expiration Days parameter on the orchestration activity’s type
and the Expiration Date/Time on the orchestration activity
An Exit algorithm resets the Expiration Date/Time on the

orchestration activity such that each time the activity exits this
state its Expiration Date/Time is updated.
Activity Error If one or more child activities enters an Error state, the
orchestration activity enters this state.
Retry When an orchestration activity is retried after correction of an

error condition, it enters this state.

• Check to determine if there are child field activities in
progress that have outbound communications awaiting a
response.
• Transition any non-final child activity to the "Reject" state
(the state defined as "Reject" on the child activity
business object lifecycle. This is most often the
"Discarded" state).
Completed Orchestration activities enter this state when all child activities
have successfully completed.
An Enter algorithm send a success notification to the

requesting system.
Use the Business Object and Algorithm portals to view additional details about this business
object and its lifecycle algorithms.
Cancel / Update Orchestration Lifecycle

The Cancel Orchestration (D1-CancelOrchestration) and Update Orchestration (D1-
UpdateOrchestration) business objects have a similar lifecycle, with the following exceptions:
• There is no "Waiting for Effective Date" state.

• In place of the "Are SP and Device Ready?” state, they have "Cancel Specific
Activity" / "Update Specific Activity" states. Enter algorithms on these states
attempt to cancel or update a specific child activity.
• In the place of "Activity In Progress" and "Activity Error" states, they have
"Communication in Progress" and "Communication in Error" states.
Use the Business Object and Algorithm portals to view additional details about this business
object and its lifecycle algorithms.
Are SP and Device Ready? - Algorithm Types

When an orchestration activity enters the "Are SP and Device Ready?" state, a set of Enter
algorithms are used to evaluate the state of the service point / meter / item to determine which
actions are required to complete the service request. These algorithms are based on the following
algorithm types.
Customer-Device Compatibility Check (D1-DVCOMCHK)

Algorithms of this type execute the "Customer-Device Compatibility Algorithm" defined on the
orchestration activity’s activity type. Algorithms of this type uses the following parameters:
• Activity BO To Create If Compatibility Detected: Specifies the activity business object to
instantiate if the algorithm detects an in compatibility between the customer/service point
and device.
Note: The base package does not include algorithm types for the "Activity Type - Customer
Device Compatibility" algorithm entity.
Connect Only If Previously Connected (D1-CONPRECON)

Algorithms of this type check if the "Connect New Device" flag has a value. If the flag is not
populated, the algorithm sets the value of the flag based on the connection status of the device
prior to the meter exchange (used only with Meter Exchange requests).
Create Meter Exchange Field Activity (D1-CREMTREXC)

Algorithms of this type create a field activity based on details provided in the algorithm’s
parameters. Algorithms of this type uses the following parameters:
• Activity and Specific Field Task to Create: Specifies the type of activity business object
and field task type to create for meter exchange field activities, as defined by the following
mnemonics:
Mnemonic Description
activityBOToCreate Specifies the activity business object to create.
specificFieldTask Specifies the Field Task Type when creating a field

activity. This value comes from the Field Task Type
extendable lookup.
For example, to create a field activity based on the D1-FieldActivity business object and the
Exchange Meter field task type, these mnemonics would be configured as follows:
activityBOToCreate=D1-FieldActivity specificFieldTask=D1-ExchangeMeter
Decommission Removed Meter (D1-DCRMMTR)

Algorithms of this type create a decommissioning command for a removed meter (used only with
Meter Exchange requests). Algorithms of this type uses the following parameters:

• Decommission Activity BO to be created: Specifies the type of activity business object to

create when decommissioning a meter. The specific activity is created, as defined by the
following mnemonics:
activityBOToCreate Specifies the activity business object to create.
For example, to create a smart meter command activity based on the D1-DeviceDecommission
business object, this parameter would be configured as follows:
activityBOToCreate=D1-DeviceDecommission
Create Specific Activity (D1-CRSPACT)

Algorithms of this type determine if a specific activity needs to be created based on the state of the
service point. Algorithms of this type use the following parameters to specify the conditions and
activity to be created:
• Field Activity BO: Specifies the field activity business object to instantiate if the algorithm
creates a field task type (see next parameter).
• SP State and Activity BO to Create: Specifies the type of activity business object to create
based on the state of the service point. This parameter can be repeated up to 20 times.
Instances of the parameter are evaluated one at a time and the first condition matching the
state of the service point is used. Parameters should be ordered from the most restrictive
condition to the least restrictive. This parameters uses the following mnemonics to indicate
the state (any combination of the following) of the service point:
servicePointConnected Specifies if the service point is currently connected
Valid values are “true" and "false".
disconnectLocation Specifies the “Disconnect Location” for the service

point.
Valid values are “D1SR" (source) and "D1DV" (device).
deviceInstalledAtSP Specifies if there is a device currently installed at the

service point.
installationEventStatusOverride Specifies the value of the "Installation Status" option type

of the Install Event's Status ("Pending", "Conn-
PreComm", "ManualOff", etc.)
Based on the unique combination of these mnemonics, a specific activity is created, as defined by
the following mnemonics:
activityBOToCreate Specifies the activity business object to create (used most

often to specify a command business object)

specificFieldTask Specifies the field task type when creating a field activity.
This value comes from the Field Task Type extendable
lookup.
Note: If this mnemonic is specified, the "Field Activity

BO" parameter should specify the field activity business
object to create.
spTypeCategory Specifies a service point type category. Valid values in

include "D1MT" (meter), "D1IT" (item), "D1MI" (multi-
item), from the SP_CATEGORY_FLG lookup.
Specifying this mnemonic indicates that a field activity

should be created only if the service point’s category
match the one specified by this mnemonic.
executeOverrideAlgorithm Specifies whether or not to execute the algorithm

specified for the Override Device/Task Algorithm on
the service order orchestration activity type.
This allows the activity business object to create to be

dynamically determined based on an algorithm instead of
the "activityBOToCreate" or "specificFieldTask"
mnemonics.
For example, the following parameter configuration would create a "Connect Service Point and
Install Meter" field activity given the following conditions:
• Service Point Connected: False
• Disconnect Location: Source
• Device Installed at Service Point: False
• Service Point Category: Meter
servicePointConnected=false disconnectLocation=D1SR
deviceInstalledAtSP=false specificFieldTask=D1-ConnSPAtSrceAndInstMtr
spTypeCategory=D1MT
Update Device (D1-UPDDVC)

Algorithms of this type determine if an activity needs to be created to update the device based on
the state of the service point and device installed at the service point. Algorithms of this type use
the following parameters to specify the conditions and activity to be created.
• Error if SP Not Connected or no Device Installed (Default is Yes): Indicates if the
algorithm should return an error if the service point is not connected or if a device is not
currently installed. Valid values are "Yes" and "Con" (continue)
• SP State and Activity BO to Create: Specifies the type of activity business object to create
based on the state of the service point. This parameter can be repeated up to 20 times.
Instances of the parameter are evaluated one at a time and the first condition matching the
state of the service point is used. Parameters should be ordered from the most restrictive

condition to the least restrictive. This parameters uses the following mnemonic to indicate the
state (any combination of the following) of the service point:
installationEventStatusOverride Specifies the value of the "Installation Status" option type

of the Install Event's Status ("Pending", "Conn-
PreComm", "ManualOff", etc.)
Based on the value of this mnemonic, a specific activity is created, as defined by the following
mnemonics:
activityBOToCreate Specifies the activity business object to create (used most

often to specify a command business object)
specificFieldTask Specifies the Field Task Type when creating a field

activity. This value comes from the Field Task Type
extendable lookup.

object to create.
spTypeCategory Specifies a service point type category. Valid values in

include "D1MT" (meter), "D1IT" (item), "D1MI" (multi-
item), from the SP_CATEGORY_FLG lookup.
Specifying this mnemonic indicates that a field activity

should be created only if the service point’s category
match the one specified by this mnemonic.
alternativeFieldTask Specifies an alternative Field Task Type to use when

creating a field activity in the event that the device does
not support the command indicated by the
"activityBOToCreate" mnemonic.

object to create.
A value of 'skip' will continue the evaluation of the

algorithm's next parameter
For example, the following parameter configuration would create a "Turn On Meter" field activity
given the following conditions:
• Installation Status: Manual Off
• Service Point Category: Meter
installEventStatusOverride=ManualOff specificFieldTask=D1-TurnOnMeter
spTypeCategory=D1MT
Other parameters used by algorithms of this type include:

• Field Activity BO: Specifies the field activity business object to instantiate if the algorithm
creates a field task type (see above parameter).

• XPath of Activity Element controlling Activity creation: Defines an element within the
activity business object schema that can be used to control whether or not this algorithm
should create an activity. For example, to specify that the value of the "Connect New Device"
flag be used to determine whether or not the algorithm should create an activity, this
parameter could be set to "connectNewDevice".
• Element value indication that Activity creation should not proceed: Specifies a value for
the element defined in the "XPath of Activity Element controlling Activity creation"
parameter that would indicate that the algorithm should not create an activity. Valid values are
based on the element defined for the "XPath of Activity Element controlling Activity
creation" parameter. For example, to specify that an activity should not be created if the
"Connect New Device" flag is set to "Do Not Connect / Turn On", this parameter should be
set to "D1NC" (from the D1_CONNECT_NEW_DEVICE_FLG lookup).
Remote Turn Off Turn On (D1-REMONOFF)

Algorithms of this type remotely turn a device off and on for a Back to Back service request.
Algorithms of this type use the following parameters:
• Device Incompatibility Detected Activity BO: Specifies the activity business object the
algorithm will look for. If the algorithm finds an activity of this business object, the algorithm
terminates.
• Remote Connect BO: Specifies the activity business object to instantiate when creating a
remote connect command.
• Remote Disconnect BO: Specifies the activity business object to instantiate when creating a
remote disconnect command.
• Installation Event Status Override for Connect: The override status to which the
Installation Event Status is set after performing a remote connect command.
• Installation Event Status Override for Disconnect: The override status to which the
Installation Event Status is set after performing a remote disconnect command.
Check for Measurement (D1-CHKMSMT)

Algorithms of this type determine if measurements exist on activity's service point as of the
service date/time. If no measurement is found, algorithms of this type create an activity to either
obtain or wait for a measurement. The specific type of activity is based on the type and
configuration of the device and service point. Algorithms of this type use the following
parameters:
• Activity BO To Wait For Measurement: Specifies the activity business object to instantiate
when the algorithm logic indicates it should wait for a measurement for the service point.
• Activity BO For Field Read: Specifies the field activity business object to instantiate when
the algorithm logic indicates it should request a meter reading from the field.
• Specific Field Task: Specifies the field task type when creating a field activity for a meter
reading from the field.
• Activity BO To Wait For Scheduled Read: Specifies the activity business object to
instantiate when the algorithm logic indicates it should wait for a scheduled read for the
service point.
• Activity BO For On Demand Read - Scalar: Specifies the activity business object to
instantiate when the algorithm logic indicates it should issue an on-demand read (scalar)
smart meter command.
• Start Range for Normal Measurement Condition: The start of the range of conditions
that indicate "normal" measurements when the algorithm is searching for measurements for
the service point.

• End Range for Normal Measurement Condition: The end of the range of conditions that
indicate "normal" measurements when the algorithm is searching for measurements for the
service point.
• Minimum Range for bottom Measurement condition: The minimum measurement
condition used when searching for measurements for the service point. Used only when no
measurements are found in the "normal" range defined by the "Start/End Range Normal
Measurement Condition” parameters.
The following parameters on the orchestration activity type are also used by algorithms of this
type when searching for measurements for the service point:
• Look for Measurement within the Day: Limits the search to the reference date (the service
date).
• Minimum and Maximum Offset Number of Days: Numbers of days added to /
subtracted from the reference date to expand the search period.
Algorithm Types and Orchestration Activity Business Objects

Each of the orchestration activity business objects uses a different set of these algorithm types.
The tables below lists which of these algorithm types are defined for each of the service order
orchestration activity business objects, and the specific algorithms used by each.
Cut for Reconnect

Enable Disable Meter Back-to-
Non- for
Service Service Exchange Back
Payment Payment
Customer-Device X X
Compatibility Check
Connect Only If X
Previously
Connected
Create Specific X
Activity
Create Meter X
Exchange Field
Activity
Update Device X X X X X X
Remote Turn Off X

Turn On
Decommission X
Removed Meter
Check For X X X X
Measurement:
Enable Service Algorithm Types and Algorithms
Algorithm Type Algorithm(s)
Customer-Device Compatibility Check Customer-Device Compatibility Check

(D1-DVCOMCHK) (D1-DVCOMCHK)
Create Specific Activity Connect SP and/or Install Device

(D1-CRSPACT) (D1-CNSPINSDV)

Update Device Connect Device

(D1-UPDDVC) (D1-CONNDVC)
Check for Measurement Check for Measurement

(D1-CHKMSMT) (D1-CHKMSMT)
Disable Service Algorithm Types and Algorithms
Update Device Disconnect Device

(D1-UPDDVC) (D1-DSCNDVC)

Cut for Non-Payment Algorithm Types and Algorithms
Update Device Disconnect Device for Non Payment

(D1-UPDDVC) (D1-DDVCFNPY)

Reconnect for Payment Algorithm Types and Algorithms
Update Device Reconnect Device for Non Payment

(D1-UPDDVC) (D1-RDPAY)
Meter Exchange Algorithm Types and Algorithms
Connect Only If Previously Connected Connect Only If Previously Connected

(D1-CONPRECON) (D1-CONPRECON)
Create Meter Exchange Field Activity Create Meter Exchange Field Activity
(D1-CREMTREXC) (D1-CREMTREXC)

Decommission Removed Meter Decommission Removed Meter

(D1-DCRMMTR) (D1-DCRMMTR)

Back-to-Back Algorithm Types and Algorithms
Customer-Device Compatibility Check Customer-Device Compatibility Check

(D1-DVCOMCHK) (D1-DVCOMCHK)

Remote Turn Off Turn On Remote Turn Off Turn On

(D1-REMONOFF) (D1-REMONOFF)

Use the Algorithm Type and Algorithm portals to view additional details about these algorithms.
Cancel / Update Orchestration - Algorithm Types

Enter algorithms on the "Cancel Specific Activity" and "Update Specific Activity" states attempt
to cancel or update a specific child activity. These algorithms are based on the following algorithm
types.
• Cancel Specific Activity: Algorithms of this type cancel the specific activity (either a field
activity or a smart meter command) that is associated to the Cancel or Update orchestration
activity, based on the current status of the specific activity.
• Update Specific Activity: Algorithms of this type update the specific activity (either a field
activity or a smart meter command) that is associated to the Cancel or Update orchestration
activity, based on the current status of the specific activity.
Cancel Specific Activity Cancel Specific Activity

(D1-CANSPACT) (D1-CANSPACT)
Update Specific Activity Update Specific Activity

(D1-UPDSPAC) (D1-UPDSPAC)
Use the Algorithm Type and Algorithm portals to view additional details about these algorithms.
Service Order Management Service Providers

The external systems used with Service Order Management must be defined as service providers
using the "External System" (D1-ExternalSystem) service provider business object. Examples of
external systems can include:
• A customer information system (such as Oracle Utilities Customer Care and Billing)
• A field work system (such as Oracle Utilities Mobile Workforce Management)
• An asset management system (such as Oracle Utilities Operational Device Management or
Oracle Utilities Work and Asset Management)
Information defined for external system service providers used by Service Order Management
include:
• Our Name/ID in Their System: This is the value that the field work system uses to identify
our system.

• Utility Device ID Type: This is the Device ID Type that will be used when communicating
with the external application and it will be the assumed Device ID Type for any device
identifiers sent from the external application.
• Utility Service Point ID Type: This is the Service Point ID Type that will be used when
communicating with the external application and it will be the assumed Service Point ID Type
for any service point identifiers sent from the external application.
Processing Roles
The service provider’s processing roles define how data relevant to the field work system is sent
and/or created.
Field work service providers can use the following processing roles:
• Activity Notification: Used to send notifications to subscribing and/or requesting systems
about the status of orchestration and/or field activities.
• Appointment Request: Used to send a request for an appointment to the field work system.
• Cancelation Activity: Used to send notifications to requesting systems when canceling
orchestration and/or field activities.
• Collection Details: Used to retrieve details about collections processing (used with "Cut
Service for Non-Payment" and "Restore Service for Payment" orchestration activities).
• Customer Contact: Used to send a contact to a customer regarding a service request
• Field Activity: Used to send a field activity to the field work system.
• Field Activity Completion: Used to send a notification regarding completion of a field
activity.
• Interim Status Update: Used to send updates regarding the status of orchestration and field
activities to requesting systems.
• Meter Exchange Mapping: Used to define how to define different types of meter
exchanges based specific roles and device configurations. This can provide context to field
crews to help ensure they install the correct type of device and device configuration when
exchanging a meter.
• Response - Appointment: Used to send a request for an appointment to the field work
system.
• Response - Fail: Used to send a response to an external system when Service Order
Management fails to respond.
• Response - Missed Appointment: Used to send a response to the field work system when
notification of a missed appointment is received.
• Response - Negative Acknowledgement: Used to send a negative acknowledgement
response to an external system in the event that a request is rejected.
• Response - Received: Used to send a response to an external system to acknowledge receipt
of a request.
• Response - Success: Used to send a response to an external system when Service Order
Management successfully processes a request.
• Send Field Activity Remark: Used to send a field activity remark to a subscribing system
• Update Activity: Used to send notifications to requesting systems when updating
orchestration and/or field activities.

Understanding Field Activities

This section describes field activities and how they communicate with field work management
systems such as Oracle Utilities Mobile Workforce Management.
What are Field Activities?

Field activities are activities that involve sending workers into the field to perform service. This
can include meter installation, meter replacement, and other activities.
Field activities send messages to a field work system, which in turn assigns them to crews to be
completed in the field. Service Order Management is integrated with Oracle Utilities Mobile
Workforce Management to support field activities, but can also integrate with other field work
systems if needed.
Field Activity Information

All field activities are based on the Field Activity (D1-FieldActivity) business object, and include
the following user-accessible information:
• 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. This defines the type of task and
other processing details regarding how Service Order Management processes the field
activity. See Field Task Types on page 2-19 for more details about field task types.
• Recipient: The field work system service provider to which the field activity is sent for
scheduling and assignment.
• Device ID: 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.
The field activity business object also contains other information that is populated by algorithms
and scripts as the field activity is processed by the system.
How Do Field Activities Work?

At a high level, field activities work as follows:
Create Field Activity

A service order orchestration activity creates a field activity based on the current state of the
service point/meter/item.
Retrieve Required Data

The field activity uses a set of pre-processing algorithms to derive and populate field activity data,
such as the device, service point, address, effective date, and others.
Request Appointment (Optional)

If the field activity task type specifies that field tasks of this type require an appointment, the field
activity checks for available appointment slots in the field work system and sends a notification to
the appointment handling system.

Create Outbound Communication

The field activity creates an outbound communication to send the field activity to the field work
system. The outbound communication gathers the information required by the field work system
before being sent. This information is retrieved by a set of processing scripts defined on the field
task type.
Receive Inbound Communication

When the field activity has been completed, the field work system sends an inbound
communication back to Service Order Management.
Inbound communications can contain Field Activity Remarks (entered by field resources when
they perform and complete their field work. If the Field Activity Remarks reference completion
events, they are executed.
The inbound communications create completion events as defined on the field task type. If the
field activity was successfully completed, it creates the "Completion Events When Successful"
completion events. If the field activity was canceled, it creates the "Completion Events When
Canceled" completion events.
Execute Completion Events

After receiving the inbound communication, a field activity algorithm transitions any active
completion events into their executed state.
Complete Processing
The field activity completes its processing by doing the following:
• Updating the parent orchestration activity
• Sending a success response to the requester
• Transitioning the parent orchestration activity to the next state in its lifecycle
• Sending a field activity completion outbound communication to subscribing systems.
Field Task Types

A field activity’s field task type defines details about the type of task to be performed and how the
system will process the activity.
Field Task Type Information

Field task types are values for the Field Task Type (D1-FieldTaskTypeLookup) extendable lookup.
Each field task type value includes the following information:
• Routing: Indicates if field tasks of this type can only be performed at a service point. Valid
values are "SP Required" and "Pass-Through".
• Appointment Option: Indicates if an appointment (via a mobile workforce application) is
required or applicable to field tasks of this type. Valid values are "Not Applicable",
"Optional", and "Required".
• Completion Events When Successful: One or more completion events that are executed
upon successful completion of field tasks of this type.
• Completion Events When Canceled: One or more completion events that are executed
upon cancellation of field tasks of this type.
• Duplicate Task Type Information: Defines processing rules for handling potential
duplicate field tasks, including:
• Allow Duplicates: Specifies whether or not duplicate field tasks are allowed

• Duplicate Threshold: A number of hours used to determine if a newly instantiated

field task type should be considered a duplicate.
• Field Task Types: A list of one or more field task types that are considered to be
duplicates of the field task type
• Conflict Task Type Information: Defines processing rules for handling potentially
conflicting field tasks, including:
• Allow Conflicts: Specifies whether or not conflicting field tasks are allowed
• Conflict Threshold: A number of hours used to determine if a newly instantiated field
task type should be considered a conflict.
• Field Task Types: A list of one or more field task types that are considered to conflict
with the field task type
• Processing Scripts: Defines one or more processing scripts to extract supplemental
information needed by the mobile workforce application to schedule field tasks of this
Field Activity Processing and Communication

This section outlines how field activities are processed, and how communication with field work
systems are performed.
Pre-Processing, Validation, and Post-Processing Algorithms

When field activities are first instantiated, a set of pre-processing algorithms populate and derive
information needed for the field activity, such as the activity type, service point, device, address,
effective date, and other information.
Validation algorithms validate this information when first retrieved and when updated.
When field activities are completed, a post-processing algorithm populates the field activity end
date/time:
Field Activity Lifecycle

As a field activity moves through its lifecycle, it triggers various business processes based on the
type of field activity. The table below outlines the lifecycle for the Field Activity (D1-FieldActivity)
business object.
State Description
Pending The initial state for field activities.
An Enter algorithm sends an acknowledgement to the

requesting system.

process.

State Description
Validate Enter algorithms perform the following:

• Validate Activity Type (and transition to error if invalid)
• Derive and validate field activity recipient
• Validate duplicate and conflict field activities
• Derive and validate field activity service point
• Derive and validate field activity device
• Validate address constituents
• Check for any existing cut service restrictions
process.
Validation Error If the business object fails any of the validations in the
Pending state, it enters this state.

• Create a To Do based on specified To Do Type and To
Do Role
• Set the "Allow Child to Transition Parent Activity" flag to
yes. This allows the field activity to transition the parent
orchestration activity if needed.
Waiting to Request If a field activity has a future effective date, it remains in this
state until the effective date is reached.
A Monitor algorithm transitions the activity to the next state

when the activity's effective date time is reached (process date
time >= effective date time).
An Enter algorithm sets the "Allow Child to Transition Parent

Activity Based On Effective Date" flag to yes. This allows the
field activity to transition the parent orchestration activity if
needed.

State Description
Waiting for Appointment If the field activity passes its validations and the effective date
has been reached, the activity enters this state.

• Evaluate if an appointment is required for field tasks of
this type. If not, the activity transitions to the
"Communication in Progress" state.
• Create a To Do if an appointment is necessary but the
system is not able to send an appointment request
• Send a notification to the appointment handling system
Monitor algorithms perform the following:
• Verify if an appointment has been supplied
• Send a notification to the appointment handling system
process.
See Waiting for Appointment on page 2-24 for more

information about this state.
Communication in Progress Field activities enter this state following the "Waiting for
Appointment" or "Retry" states.

• Create an outbound communication for the field activity
(see Communication in Progress on page 2-25 for
more information)

• Check for existing child communications
• Check that the activity hasn’t timed out
Discarded Activities discarded in other states enter this state.

• Cancel outstanding outbound communications
• Cancel outstanding completion events
• Populate the cancel reason
• Send a failure notification to the requesting system
• Transition the parent activity to the " Activity Error" state
(Service Order Orchestration Activity Lifecycle on
page 2-7 for more information)
• Check if a Cancel Orchestration activity is required

State Description
Communication Error If an outbound or inbound communication an Error state, the

field activity enters this state.

Do Role
Retry When an field activity is retried after correction of an error

condition, it enters this state.

• Check to determine if there are associated outbound
communications in progress.
• Cancel any outstanding outbound communications
Execute Completion Events After an inbound communication is received, it enters this

state.
• Executes completion events defined on the field task type
(these completion events were initially created by the
inbound communication).
• Evaluates the "Field Activity Completed" flag on the field
activity. If this is set to "No", the field activity is
transitioned to the "Canceled In Field" state.
process.
See Execute Completion Events on page 2-29 for more

information about this state.
Completion Event Error If an error occurs during completion event processing, the
field activity enters this state.

Do Role

State Description
Completed Field activities enter this state when all completion events
have successfully completed.

• Update the parent orchestration activity
• Send a success response to the requester
• Transition the parent orchestration activity to the next
state in its lifecycle
• Send a field activity completion outbound
communication to subscribing systems.
Canceled in Field If the "Field Activity Completed" flag on the field activity is
set to "No", the field activity enter this state.

• Send a failed response to the requester
• Transition the parent orchestration activity to the
"Activity Error" state.
• Create a To Do to notify users that the field activity has
been canceled.
Waiting for Appointment

When a field activity enters the "Wait for Appointment" state, it first determines if an appointment
is necessary for the field activity. If not, the activity moves on to the "Communication in Progress"
state (see below).
If an appointment request cannot be sent for some reason, the field activity creates a To Do item
to alert a user to attempt to manually request an appointment. Otherwise, the field activity sends
an outbound message to the field work system requesting an appointment. based on the
appropriate processing role defined on the."Send Notification to Appointment Handling System -
Enter" algorithm.
Processing Role Outbound Communication Business Object
Appointment Response Send Appointment Response Outbound Message

(default) (D1-SendApptRespOutboundMsg)
Used if:
• An appointment is required Note: An outbound message must be created based on
and needs to be scheduled this business object.
• Appointment has been set
The response from the field work system can be received by creating an Inbound Web Service that
references the "Book selected appointment to Field Activity" (D1-BookAppt) service script.
While in this state, monitor algorithms verify if an appointment has been supplied and send
notifications to the field work system.

Communication in Progress
Field Activity communications are records of messages sent between Service Order Management
and an external field work system, such as Oracle Utilities Mobile Workforce Management.
Communications can flow both outbound and inbound.
When a field activity enters the "Communication in Progress" state, it sends an outbound
communication to the field work system, and waits for an inbound communication response.
See Understanding the Field Activity Communication Process below for more information
about the role of communications in the field activity communication process.
Outbound Communications
Outbound Communications represent messages sent from Service Order Management to. an
external field work system Outbound communications use the following types of objects:
• Outbound Communication Business Objects
• Outbound Message Types
• External Systems
Outbound Communication Business Objects
An outbound communication business object exists for each type of message to be sent to an
external system. For field activities, the following base package outbound communication objects
can be used.
Type of Outbound
Outbound Communication Business Object
Communication
Initial field activity outbound Field Activity Outbound Communication

communication (D1-FieldActivityOBComm)
Modify outbound communication Field Activity Outbound Communication

Used to send an update to a field (D1-ActivityModifyOBComm)
activity previously sent to the field
work system.
Outbound Message Types

A outbound message type must also be created for each type of message to be sent to an external
system. Again, this is based on the types of messages the system is designed to accept. For field
activities, the following outbound message types are needed:
Type of Outbound
Outbound Message Type
Communication
Initial Field Activity Field Activity Outbound Message

Message
Modify Existing Field Modify Field Activity Outbound Message

Activity
Refer to the Oracle Utilities Application Framework documentation for more information about
outbound message types.
External Systems
You must also create an External System for each external system to which Service Order
Management will send messages. Each external system defines a set of outbound message types

that will be sent to that system. Each external system outbound message type also specifies the
following:
• The processing method used to send the message (Batch, XAI, or Real-time)
• XAI Sender (if Processing Method is set to Real-time or XAI)
• Batch Control (if Processing Method is set to Batch)
• Message XSL, W3C Schema, and Response XSL (as applicable)
To continue the example above, you might create the following external system:
External Application
Processing
Outbound Message Type Batch Control
Method
Field Activity Outbound Message Batch Sync Request Monitor

(F1-SYNRQ)
Modify Field Activity Outbound Message Batch Sync Request Monitor

(F1-SYNRQ)
external systems.
Inbound Communications
Inbound Communications represent messages sent from an external field work system such as
Oracle Utilities Mobile Workforce to Service Order Management. Inbound communications are
typically sent in response to a field activity. Inbound communications use the following types of
objects:
• Inbound Communication Business Objects
• XAI Inbound Service
• Field Activity Remarks
Inbound Communication Business Objects
An inbound communication business object must be created for each type of message to be
received from an external system. For field activities, the following base package inbound
communication object can be used.
Inbound Communication Business Object
Field Activity Inbound Communication

(D1-FieldActivityIBComm)
XAI Inbound Service

You must also create an XAI Inbound Service for each type of message to be received from an
external system. XAI inbound services define the details of how messages are received from an
external system, including the inbound communication business object (or business service or
service script) to be invoked when the response message is received. As in the case of inbound
communication business objects, the set of XAI inbound services you need to create is based on

the types of messages the system is designed to send. To continue the example above, you might
create the following XAI inbound services:
Schema
XAI Inbound Service
(Inbound Communication Business Object)
Field Activity Inbound Field Activity Inbound Communication

Communication D1-FieldActivityIBComm
XAI Inbound Services.
Field Activity Remarks
Inbound communications can contain activity remarks, which represent notes entered by the field
worker as they perform and complete their field work. These can be solely informational, or can
reference completion events via the "Remark Processing" section of the Field Activity Remark
Type extendable lookup. This allows information sent with the inbound communication to initiate
business processing if necessary.
Completion events specified on this extendable lookup are created by the inbound
communication, and then executed when the field activity enters the "Execute Completion
Events" state.
Understanding the Field Activity Communication Process

This section provides an overview of the communication process that takes place when a field
activity is initiated. For each step in the process, the table below provides a brief description of the
processing that takes place, and lists the specific base package objects used by Service Order
Management
Note that the process outlined below has been simplified for illustrative purposes, and does not
reference every step performed in this process.
Step Process Base Package Objects
1. An orchestration activity creates a field activity Field Activity Business Object: Field
as part of its processing. Activity (D1-FieldActivity)
A field activity business object is instantiated for

the command.
2. When the field activity enters the Outbound Communication Business

Communication in Progress tate, it creates an Object: Field Activity Outbound
outbound communication. Communication
(D1-FieldActivityOBComm)
3. A Enter algorithm on the "Awaiting Response" Enter Algorithm: Populate Send Detail for
state of the outbound communication retrieves Field Activity (D1-POPSNDDTL)
information needed by the outbound message
to be sent to the field work system based on
processing scripts specified on the field task
type.
4. A Enter algorithm on the "Awaiting Response" Enter Algorithm: Create Outbound

state of the outbound communication creates an Message (D1-COUTMSG)
outbound message.
Note: An outbound message type for this
message is not included in the base
package.

Step Process Base Package Objects
5. The outbound message is sent to middleware External System: MWM

components via an External System and Batch
Control. Batch Control: Sync Request Monitor
(F1-SYNRQ)
Middleware components utilize Business
Process Execution Language (BPEL).
6. The middleware converts the outbound message

from SOM format into the format used by the
field work system, and sends the message to the
field work system.
7. When the field work system sends a response, XAI Inbound Service: D1-
the middleware receives the response message FieldActivityIBComm (D134794183)
from the field work system, and converts it from
the format used by the field work system to
SOM format and invokes an XAI Inbound
Service.
8. The XAI Inbound Service picks up the message, XAI Inbound Service: D1-
and creates a corresponding inbound FieldActivityIBComm (D134794183)
communication.
Inbound Communication Business Object:
The specific type of inbound communication Field Activity Inbound Communication
business object created is determined by the (D1-FieldActivityIBComm)
XAI Inbound Service.
9. The inbound communication identifies the Outbound Communication Business

parent outbound communication. Object: Field Activity Outbound
Communication
10. The inbound communication creates the Inbound Communication Business Object:
completion events defined on the field activity Field Activity Inbound Communication
field task type (Successful or Canceled, as D1-FieldActivityIBComm
appropriate) in the "Pending" state.
If the inbound communication contains field

activity remarks, it also executes any field activity
remark completion events.
11. The inbound communication updates the Inbound Communication Business Object:
outbound communication. Field Activity Inbound Communication
D1-FieldActivityIBComm
This update is performed by an Enter algorithm
on the “Completed” Status of the inbound Outbound Communication Business
communication business object’s lifecycle. Object: Field Activity Outbound
Communication
12. The outbound communication updates the Outbound Communication BO: Initiate
“Completion Flag” and the original field activity Connect Disconnect (D3-
business object. InitiateConnectDisconnect)
This update is performed by an Enter algorithm Field Activity Business Object: Field
on the “Completed” Status of the outbound Activity (D1-FieldActivity)
communication business object’s lifecycle.

Execute Completion Events

After receiving the inbound communication, the field activity enters the "Execute Completion
Events” state.
The inbound communication will have previously created completion events for the field activity,
based on those defined on the field task type or those referenced by field activity remarks. These
creation events begin in the "Pending" state.
An Enter algorithm transitions completion events associated with the field activity into their
"Executed" state.
Unrelated Pickup Orders

When field work crews are out performing field work, it’s possible that they will encounter other
work unrelated to their current task that needs to be done. This type of work can be as simple as
trimming a tree whose branches are too close to power lines, or the replacement of a meter for a
different customer or service point. These types of task are referred to as "unrelated pickup
activities." Crews can either work the field activity or leave it to be assigned to another crew at a
later date.
When the crew creates an unrelated pickup activity in the field work system, it is sent to Service
Order Management, and a corresponding field activity is created in the system.
Unrelated pickup activities can be created via one of the following XAI Inbound Services:
• Field Activity Asynchronous Req Inbound (D1-FARequestAsynchronous)
• Field Activity Synchronous Req Inbound (D1-FARequestSynchronous)
Once created, the are processed like any other field activity. If the pickup activity was completed in
the field before being sent to Service Order Management, it will quickly move through its lifecycle
(as now further action is needed) until it reaches the "Completed" state.
Retrieving Service Point Information

If the unrelated pickup activity is customer-related it will require service point information to be
created. This information can be queried by the field work crew via the "Field Work Service Point
Query" (D1-FieldWorkSPQuery) XAI Inbound Service
This service uses set of service point criteria to allow the field crew to search for a service based
upon either service point or device information. The service returns a list of service points that is
configurable in length. If the number of results is larger than the configured maximum length the
service indicates that additional records exist and the crew can request another set of results
allowing them to identify the proper service point to associate to the activity.
There are times when an unrelated pick-up activity is identified but the field crew is out-of-
coverage (i.e. no network connection) and they will not be able to immediately verify service point
information. In this type of situation, the crew can input the service point criteria fields and create
the activity, which, when imported into Service Order Management, will attempt to identify the
service point based upon the information provided. If the service point can be uniquely identified
everything should operate as normal. If the service point cannot be uniquely identified then the
field activity is set to the error state.

Understanding Smart Meter Commands
Understanding Smart Meter Commands

Smart meter commands issued by service order orchestration are the same as smart meter
commands provided by the base Oracle Utilities Smart Grid Gateway functionality.
See Chapter 7: Device Communication and Device Events in the Oracle Utilities Smart Grid
Gateway Configuration Guide for more information about how smart meter commands are
processed.

Service Order Orchestration Activities In Detail

This section provides details concerning the service order orchestration activity objects supplied
as part of the base package. This information illustrates how the base package objects were
designed, and can serve as the basis for any custom service order orchestration activity objects you
create as part of your implementation. This section includes:
• Lists of the base package service order orchestration activity business objects
• A sample service order orchestration activity business object (D1-EnableService)
Smart Grid Gateway Base Package Service Order Orchestration Activity

Business Objects
The Oracle Utilities Smart Grid Gateway base package includes the following service order
orchestration activity business objects.
Business Object Name Description
D1-SPActivityOrchestration Service Point Activity Orchestration

(used as a parent business object for all
other service order orchestration activity
business objects)
D1-BackToBackService Back to Back Service

Instances of this business object represent
individual back-to-back service requests in
the system.
D1-CutServiceForNonPayment Cut Service for Non-Payment

individual cut service requests in the
system.
D1-DisableService Disable Service

individual disable service requests in the
system.
D1-EnableService Enable Service

individual enable service requests in the
system.
D1-ExchangeMeter Exchange Meter

individual exchange meter requests in the
system.
D1-ReconnectForPayment Reconnect Service for Payment

individual restore service requests in the
system.

D1-ResolutionMonitor Service Order Resolution Monitor

instances when another activity, such as an
orchestration activity, requires manual
intervention to proceed.
D1-CancelOrchestration Cancel Orchestration

individual cancel orchestration activities in
the system.
D1-UpdateOrchestration Update Orchestration

individual update orchestration activities in
the system.
Use the Business Object portal to view additional details concerning these business objects.
Example Service Order Orchestration Activity - D1-EnableService

The table below lists the details of the D1-EnableService service order orchestration activity
business object.
Option Description
Business Object D1-EnableService
Description Enable Service
Maintenance Object D1-ACTIVITY (Activity)
Parent Business Object D1-SPActivityOrchestration
Application Service D1-SPORCHACTBOAS (SP Activity Orchestration BO)
Instance Control Allow New Instances
Options • Related Administration BO: D1-EnableServiceType (Enable

Service Type)
Algorithms • Information: D1-SPACTINFO (SP Orchestration Activity

*Inherited from parent Information)*
business object
• Pre-Processing: D1-DETACTTYP (Determine Activity
Type)*
• Pre-Processing: D1-DRVSPEXID (Derive SP from External
SP ID)*
• Post-Processing: D1ENDDTTM (Populate End Date/
Time)*
• Pre-Processing: D1-DRVCNTID (Derive Contact Id from
Person Id in Activity)

Option Description
Lifecycle • Pending (Initial)

(Inherited from parent
• Validate (Interim, Transitory)
business object)
• Validation Error (Interim)
• Discarded (Final)
• Waiting for Effective Date (Interim)
• Are SP and Device Ready? (Interim, Transitory)
• Activity in Progress (Interim)
• Activity in Error (Interim)
• Retry (Interim, Transitory)
• Completed (Final)
Use the Business Object portal to view additional details concerning this business object.

Field Activities In Detail

This section provides details concerning the field activity objects supplied as part of the base
package. This information illustrates how the base package objects were designed, and can serve
as the basis for any custom field activity objects you create as part of your implementation. This
section includes:
• A list of the base package field activity business objects
• A sample field activity business object (D1-FieldActivity)
• A list of base package field task type
• A list of base package processing scripts used by Field Task Types
• A list of base package completion events used by Field Task Types
• A sample field task type (D1-ConnectSPAtMeter)
Service and Measurement Data Foundation Base Package Field Activity

Business Objects
The Service and Measurement Data Foundation base package includes the following “lite”
inbound communication business objects:
D1-FieldActivity Field Activity

individual field activities in the system.
Example Field Activity - D1-FieldActivity

The table below lists the details of the D1-FieldActivity field activity business object.
Option Description
Business Object D1-FieldActivity
Description Field Activity
Maintenance Object D1-ACTIVITY (Activity)
Application Service D1-FAOAS (Field Activity BO)
Instance Control Allow New Instances

Option Description
Options • Cancel Orchestration BO: D1-CancelOrchestration (Cancel

Orchestration)
• Final Status Required for Archive (Y/N): Y
• Summary Service Script: D1-FASUM
• Update Orchestration BO: D1-UpdateOrchestration (Update
Orchestration)
• Related Administration BO: D1-FieldActivityType (Field
Activity Type)
• Portal Navigation Option: d1-ActivityNavOpt (Activity
Navigation Option)
• Display Map Service Script: D1-CKFATYSOM (Check if
Field Activity Type exists in SOM Config)
Algorithms • Information: D1-FAINFO (Field Activity Information

• Post-Processing: D1-ENDDTTM (Populate End Date/Time)
• Pre-Processing: D1-DETACTTYP (Determine Activity Type)
• Pre-Processing: D1-DRVACTSP (Derive Field Activity
Service Point)
• Pre-Processing: D1-DSPDDC (Derive Field Activity Device)
• Pre-Processing: D1-DRVADRCNS (Derive Field Activity
Address Constituents)
• Pre-Processing: D1-INITEFDAT (Initialize Effective Date)
• Pre-Processing: D1-ACSDT (Adjust Cut Service Date Time)
• Pre-Processing: D1-DRVCNTID (Derive Contact Id from
Person Id in Activity)
• Validation: D1-VALFTDATE (Validate Field Activity
Expiration and Effective Dates)
• Validation: D1-VALFTTUPD (Validate Duplicate and
Conflicting Field Activities on Update)
• Validation: D1-VALADRCNS (Validate Field Activity Site
Address)
• Validation: D1-VALSPUPD (Validate Field Activity Service
Point on Update)
• Validation: D1-VALDVCUPD (Validate Field Activity Device
on Update)
• Validation: D1-VALCPRADR (Validate Field Activity
Address Constituents on Update)
• Validation: D1-CHKUPDORC (Check if Update
Orchestrator is Required)
• Validation: D1-VALRCPUPD (Validate Field Activity
Recipient on Update)
• Validation: D1-VCUTSR (Validate Cut Service Restrictions)

Option Description
Lifecycle • Pending (Initial)

(Inherited from parent
• Validate (Interim, Transitory)
business object)
• Validation Error (Interim)
• Waiting for Request (Interim)
• Waiting for Appointment (Interim)
• Communication in Progress (Interim)
• Discarded (Final)
• Communication Error (Interim)
• Retry (Interim, Transitory)
• Execute Completion Events (Interim)
• Completion Event Error (Interim)
• Completed (Final)
• Canceled in Field (Final)
Use the Business Object portal to view additional details concerning this business object.
Base Package Field Task Types

The table below lists the base package field task types.
Field Task Type Description
D1-ConnectSPAtDevice Item - Connect SP at Device
D1-ConnectSPAtDvcAndTurnOn Item - Connect SP at Device and Turn On
D1-ConnectSPAtMeter Connect SP at Meter
D1-ConnectSPAtMeterAndTurnOn Connect SP at Meter and Turn On
D1-ConnectSPAtSource Connect SP at Source
D1-ConnectSPAtSourceAndTurnOn Connect SP at Source and Turn On
D1-ConnSPAtDvcAndInstDvc Connect SP at Device and Install Device
D1-ConnSPAtMtrAndInstMtr Connect SP at Meter and Install Meter
D1-ConnSPAtSrceAndInstDvc Connect SP at Source and Install Device
D1-ConnSPAtSrceAndInstMtr Connect SP at Source and Install Meter
D1-ConnSPAtSrceAndTurnOnDvc Item - Connect SP at Source and Turn On
D1-CutForNonPayment Cut for Non Payment
D1-CutItemForNonPayment Item - Cut for Non Payment
D1-DisconnectItemSPAtSource Item - Disconnect SP at Source
D1-DisconnectSPAtDevice Disconnect SP at Device
D1-DisconnectSPAtMeter Disconnect SP at Meter

Field Task Type Description
D1-DisconnectSPAtSource Disconnect SP at Source
D1-DisconnectWarning Disconnect Warning
D1-DisConnSPAtDvcAndRmveDvc Disconnect SP at Device and Remove

Device
D1-DisConnSPAtMtrAndRmveMtr Disconnect SP at Meter and Remove Meter
D1-DisConnSPAtSrceAndRmveMtr Disconnect SP at Source and Remove

Meter
D1-ExchangeDevice Item - Exchange Device
D1-ExchangeMeter Exchange Meter
D1-InstallDevice Item - Install Device
D1-InstallMeter Install Meter
D1-ReadMeter Read Meter
D1-ReconnectForPayment Reconnect for Payment
D1-ReconnectItemforPayment Item - Reconnect for Payment
D1-RemoveDevice Item - Remove Device
D1-RemoveMeter Remove Meter
D1-ServiceInvestigation Service Investigation
D1-TrimTree Trim Tree
D1-TurnOffItem Turn Off Item
D1-TurnOffMeter Turn Off Meter
D1-TurnOnItem Turn On Item
D1-TurnOnMeter Turn On Meter
D1-TurnOnPilotLight Turn On Pilot Light
Use the Extendable Lookup portal to view additional details for these field task types.
Field Activity Task Types - Base Package Processing Scripts

The processing scripts defined on the field task type are invoked by the "Populate Send Detail for
Field Activity" (D1-POPSNDDTL) algorithm on the outbound communication sent by the field
activity. The table below lists the base package field task type processing scripts.
Processing Script Base Package Script Description
CIS Data Retriever Service Order - Retrieve CIS Data (D1-RetCisDat)
Asset System Data No base package script provided.

Retriever
Internal Data Retriever Service Order - Retrieve Internal Data (D1-RetIntDat)
Criteria Script Service Order - Retrieve Criteria Value (D1-RetCriVal)

Processing Script Base Package Script Description
External System Service Order - Populate External System and Identifiers (D1-
Identifier Retriever RetExtIdf)
MDM Data Retriever Service Order- Retrieve Meter Data Details (D1-RetMtrDtl)
Service Order - Retrieve Item Data Details (D1-RetItmDtl)
Field Activity Task Types - Base Package Field Activity Completion Events
The completion events defined on the field task type are created by the "Create Completion Event
for Field Activity" (D1-COMPEVSA) algorithm on the inbound communication sent by the field
work system. These completion events are then executed by the "Execute Completion Events"
(D1-EXCMPEVTS) algorithm on the field activity. The table below lists the base package field
task type completion events.
Completion Event Description
D1-ConnectItemFA Connect Item - Field Work Completion
D1-ConnectDeviceFA Connect Meter - Field Work Completion
D1-ConnectNewDeviceFA Connect New Meter-Field Work Completion
D1-ConnectSPCE Connect SP - Field Work Completion
D1-CreateFAIMD Create FA IMD Completion Event
D1-CustomerContact Notify Requester of Customer Contact
D1-DisconnectDeviceFA Disconnect Device - Field Work Completion
D1-DisconnectItemFA Disconnect Item - Field Work Completion
D1-InstallDevice Install Device - Field Work Completion
D1-InstallItem Install Item - Field Work Completion
D1-RemoveDevice Remove Device - Field Work Completion
D1-RemoveItem Remove Item - Field Work Completion
D1-RequestToDo Create To Do with Crew Message
D1-UpdateDevice Update Device - Field Work Completion
D1-UpdateItem Update Item - Field Work Completion
D1-UpdateSP Update SP - Field Work Completion

Example Field Task Type - D1-ConnectSPAtMeter

The table below lists the details of the D1-ConnectSPAtMeter field task type.
Option Description
Field Task Type D1-ConnectSPAtMeter
Status Active
Description Connect SP at Meter
Routing SP Required
Appointment Option Not Applicable
Duplicate Task Type Allow Duplicates: Yes

Information
Conflicting Task Type Allow Conflicts: Yes

Information
Processing Scripts • CIS Data Retriever: Service Order - Retrieve CIS Data
• Asset System Data Retriever
• Internal Data Retriever: Service Order - Retrieve Internal
Data
• Criteria Script: Service Order - Retrieve Criteria Value
• External System Identifier Retriever: Service Order - Populate
External System and Identifiers
• MDM Data Retriever: Service Order- Retrieve Meter Data
Details
Completion Events • 10 - Connect SP - Field Work Completion - Yes

When Successful
• 20 - Update SP - Field Work Completion - No
• 30 - Update Device - Field Work Completion - No
• 40 - Create To Do with Crew Message - No
• 50 - Notify Requester of Customer Contact - No
Completion Events N/A

When Canceled

Service Order Operational Dashboards

The Service Order Management dashboards are used to view the current status of service order
activities in the system. Refer to the Oracle Utilities Service and Measurement Data Foundation User’s
Guide for information about working with these dashboards.
This section outlines how the data presented on these dashboards is generated and updated.
Service Order Activity Aggregation

Aggregation processing is used to derive the service order activity data presented via the Service
Order Management dashboards. This section will focus only on how aggregation for activity
statistics are calculated for use in the dashboards. Refer to Chapter 13: Aggregations in the
Oracle Utilities Meter Data Management Configuration Guide for a description of the aggregation
process.
Accumulation-Based Aggregation
Some of the data accessed on the dashboards is aggregated using a traditional "accumulation"-
style aggregation of activity data. With accumulations, data is refreshed when changes occur, and
when a request to refresh the data is submitted (either via scheduled batch process or via the
Activity Statistics dashboard zone).
For example, assume that 400 activities were created on June 15, and 300 were "In Progress" as of
the last time the data was updated. Then on June 16 if an update was requested, while there would
still 400 activities that had been created on June 15, if at this time only 200 were "In Progress", the
data would be updated to reflect 200 "In Progress".
SnapShot Aggregation
Some data on the dashboards is generated using a "snapshot"-style aggregation of activity data.
Snapshots are typically used whenever there is a need to look at trends over time. For example, to
view trends of in-flight activities, the system can take periodic snapshots to hold capture data.
Note that snapshot data is preserved, but not updated. This means that snapshot data becomes
stale as soon as the snapshot is taken.
Aggregator Business Objects

The dashboard activity statistics aggregation process uses the following aggregator measuring
component business objects.
Aggregator Business Object Description
D1-ActivityProcsAggregator This aggregator retrieves all activities created during

Activity Processing Accumulation the aggregation horizon for the activity type, service
Aggregator type (via the service point to which the activity is
linked), and requesting system.
D1-ActivityProcSnapAggtor This aggregator takes a snapshot of activities based

Activity Processing Snapshot on its dimensional values, including the requesting
Aggregator system, activity type, and service type (as determined
via the service point linked to the activity).
The period of time over which it retrieves activities is

controlled via the "Number of Days to Consider for
Snapshot" parameter on the Service Order
Management master configuration.

Aggregator Business Object Description
D1-ActivityProcDerivedSnapAgg This aggregator takes a snapshot of another

Activity Processing Derived Snapshot aggregator's measurement data. It assumes that the
Aggregator current aggregator is configured as a related
measuring component on the appropriate
aggregator.
The aggregator used as the basis for calculation
should be the "Activity Processing Accumulation
Aggregator” (D1-ActivityProcsAggregator).
D1-ActivityAgingSnapAggtor This aggregator takes a snapshot of activity statistics

Activity Aging Snapshot Aggregator pertaining to aging for activities created over a
configurable period of time, based on the
aggregator's activity type, requesting system, and
service type (determined via the service point
associated with the activity). It considers activities
that have been completed within the snapshot period
(typically a day).
Aggregator Type Business Objects

The dashboard activity statistics aggregation process uses the following aggregator measuring
component type business objects.
Aggregator Type Business Object Description
D1-ActStatsSubAggregatorType This measuring component type defines sub-

Activity Statistics Sub-Aggregator Type aggregator types for activity statistics
calculation.
D1-ActStatsMasterAggType This measuring component type defines master

Activity Statistics Master Aggregator Type aggregation information for its measuring
component and its sub-aggregator measuring
components, and controls the aggregation
parameters, its sub-aggregator measuring
component types, and the valid measuring
component types to aggregate.
D1-ActStatsSubAggregatorType This measuring component type defines the

Activity Statistics Sub-Aggregator Type sub-aggregation information for its measuring
component, an controls the aggregation
parameters.
Use the Business Object portal to view additional details for these business objects.

Activity and Activity Type Business Objects

The dashboard activity statistics aggregation process uses the following activity and activity type
business objects.
D1-ActivityStatsAggtorCreator This activity business object creates aggregators

Activity Statistics Aggregator Creator for active activity types for orchestrators, field
activities, and smart meter commands.
To use the aggregator creator to facilitate
statistics calculations for all of the available
types, an activity should be created for each
combination of the master aggregator MC type
(processing statistics) and a service type.
For example:
• Aggregator Creator 1: Processing Statistics
Accumulation MC Type / Electric
• Aggregator Creator 2: Aging Statistics
Accumulation MC Type / Electric
D1-ActivityStatsAggtorCreatorType This activity type business object defines

Activity Statistics Aggregator Creator Type configuration options used by the activity
statistics aggregator creator.
Use the Business Object portal to view additional details for this business objects.
Batch Processing
The activity statistics processing uses the following batch controls.
D1-ACTAG This batch control initiates automatic/

Activity Statistics Aggregation Monitor scheduled transition for aggregator measuring
components and is used to update aggregated
statistics.
This batch control can be triggered from the

Activity Statistics dashboard zone, or can be
scheduled to run at regular intervals to update
activity processing statistics.
D1-ADS This batch control scans for new dimension

Aggregation Dimension Scanner Monitor combinations and creates new activity
aggregators as needed.

Service Order Management Master Configuration

The Service Order Management master configuration can be used to define how data is processed
and displayed on the Service Order Management dashboards. This section outlines these options.
Management Dashboard Configuration

The Management Dashboard Configuration options are used to define how dashboard statistics
are calculated.
Basic options include the following:
• Number of Days to Consider for Snapshot: The number of days to consider when creating
data snapshots.
• Weekends/Holidays Inclusion in Activity Duration: A flag that indicates if weekends and
holidays should be included when calculating activity durations. Valid options (defined by the
HOLIDAYS_INCL_FLG lookup) include
• Including in Activity Duration
• Exclude from Activity Duration
• Work Calendar: The work calendar used to determine weekdays, weekends, and holidays.
• Default Expected Activity Completion Time (Hours): The default number of hours in
which activities are expected to be completed.
Override Expected Completion Time Configuration

This section allows an implementation to override the default expected activity completion time
(see above) for specific types of activities and field task types. This is used for types of activities
that take longer (or shorter) than the default expected completion time. For example, if the default
completion time is set to 3 hours, but reading a meter takes only 1 hour, you might create an
override for the "Read Meter" field task type. Each override is defined by the following:
• Activity Type: The activity type to which the override applies.
• Task Type: The Field Task Type to which the override applies. Applicable only if the Activity
Type is a field activity type.
• Expected Completion Time (Hours): The number of hours in which activities of the
specified are expected to be completed.
Summary To Do Types
This section defines To Do Roles for Summary To Do entries. For each To Do Type specified, you
can specify a To Do Role.
Hours Beyond Expected Activity Completion Time

This section defines numbers of hours used to define thresholds for activity completion and
progress.
Completion tolerance options include the following:
• On Time Completion Tolerance: The number of hours in which an activity’s completion is
considered to be "on time".
• Late Completion Tolerance: The number of hours in which an activity’s completion is
considered to be "late".
• Very Late Completion Tolerance: The number of hours in which an activity’s completion is
considered to be "very late".
For example, if the "On Time Completion Tolerance" is 8, an activity that takes up to 8 hours to
complete is considered "on time". If the "Late Completion Tolerance" is 16, an activity that takes

between 8 and 16 hours to complete is considered "late”. If the "Very Late Completion Tolerance"
is 24, an activity that takes between 16 and 24 hours to complete is considered "very late”.
In progress time options include the following:
• Normal In Progress Time: The number of hours in which an activity’s progress is
considered to be "normal".
• Long In Progress Time: The number of hours in which an activity’s progress is considered
to be "long".
• Very Long In Progress Time: The number of hours in which an activity’s progress is
considered to be "very long".
For example, if the "Normal In Progress Time" is 8, an activity that takes up to 8 hours to
complete is considered "normal". If the "Long In Progress Time" is 16, an activity that takes
between 8 and 16 hours to complete is considered "long". If the "Very Long In Progress Time" is
24, an activity that takes between 16 and 24 hours to complete is considered "very long".
Update Statistics
This section specifies the batch control used to update statistics for the Service Order
Management dashboards.
The Service Order Management Master Configuration can be used to configure details concerning
how data is displayed on these dashboards.
Chart Options
The Chart Options section is used to define specifics for how data its displayed on the dashboard.
The Number of Historical Days to Include in Summary Charts options specifies the number
of days of historical data to display in summary charts.
Colors used in the dashboard charts are defined by values for the "Colors" (D1-COLOR)
characteristic type. Colors are defined by HTML color codes.
Processing Statistics
This section defines the color to use when displaying processing statistics on dashboard charts and
graphs.
Available processing statistic types are based on Value Identifiers defined on a measuring
component type that references the "Activity Process Accumulation Aggregator" (D1-
ActivityProcsAggregator) measuring component business object. The business object for this
measuring component type must be "Activity Statistic Master Aggregator Type".
Aging Statistics
This section defines the color to use when displaying aging statistics on dashboard charts and
graphs.
Available aging statistic types are based on Value Identifiers defined on a measuring component
type that references the "Activity Aging Snapshot Aggregator" (D1-ActivityAgingSnapAggtor)
measuring component business object. The business object for this measuring component type
must be "Activity Statistic Master Aggregator Type".
Activity Types
This section defines the color to use when displaying activity types on dashboard charts and
graphs.
Available activity types are based on values defined for the "External Activity Type Identifier"
(D1-ExternalActTypeIdentifier) extendable lookup.

Field Task Types

This section defines the color to use when displaying field task types on dashboard charts and
graphs.
Available field task types are based on values defined for the "Field Task Type" (D1-
FieldTaskTypeLookup) extendable lookup.

Service Order Management Integrations

This section provides a high-level overview of integrations used with Service Order Management.
These include:
• Oracle Utilities Customer Care and Billing to Service Order Management
• Service Order Management to Oracle Utilities Mobile Workforce Management
Oracle Utilities Customer Care and Billing to Service Order Management

This integration enables service request business processing between Oracle Utilities Customer
Care and Billing and Service Order Management, including the following:
Process Description
Field Activity Creation Field activities can be sent from Oracle Utilities
Customer Care and Billing to Service Order
Management.
Field Activity Completion For activities that are handled in Service Order
Management, Service Order Management sends a
success/failure response to Oracle Utilities Customer
Care and Billing.
Service Request Update / Field Customer contacts can be created as part of completion
Activity Customer Contact for activities handled in Service Order Management.
Oracle Utilities Service Order Management will send a
message to Oracle Utilities Customer Care and Billing to
create a customer contact.
Appointment Notifications Service Order Management can communicate to Oracle

Utilities Customer Care and Billing if an appointment was
booked.
Missed Appointment Service Order Management can communicate to Oracle

Utilities Customer Care and Billing if an appointment was
missed.
Collection Information Service Order Management requests collection

information from Oracle Utilities Customer Care and
Billing and passes it to Oracle Utilities Mobile Workforce
Management.
Cancel Field Activity Before attempting to cancel field activity in Oracle

Utilities Customer Care and Billing, a real time service call
to Service Order Management is made to determine if the
field activity is cancellable.
Refer to the Oracle Utilities Service Order Management Integration to Oracle Utilities Mobile Workforce
Management Implementation Guide for details about configuring this integration.

Service Order Management to Oracle Utilities Mobile Workforce Management

This integration enables service request business processing between Service Order Management
and Oracle Utilities Mobile Workforce Management, including the following:
Business Process Description
Process Field Activities Service Order Management sends the details of field
activities that need to be created/updated/cancelled to
Oracle Utilities Mobile Workforce Management.
Appointment Window Request Service Order Management requests Oracle Utilities

Mobile Workforce Management for available
appointment slots. Oracle Utilities Mobile Workforce
Management provides a list of available appointments.
Interim Activity Status Request Service Order Management requests interim activity
status from Oracle Utilities Mobile Workforce
Management. Oracle Utilities Mobile Workforce
Management provides the status of interim activities such
as work in progress or en route.
Device Verification Oracle Utilities Mobile Workforce Management requests

device verification from Service Order Management.
Create Pickup Order /Create Oracle Utilities Mobile Workforce Management requests
Activity Service Order Management to create unrelated pickup
orders.
Activity Completion / Oracle Utilities Mobile Workforce Management sends

Cancellation activity completion/cancellation information to Service
Order Management.
Query Service Point / Unrelated Oracle Utilities Mobile Workforce Management supplies
Pickup Order criteria to identify a service point in Service Order
Management when creating unrelated pickup activities.
Management Implementation Guide for details about configuring this integration.


Chapter 3
Service Order Management Process
Configuration
This chapter provides an overview of the data configuration required for each of the service order
processes supported by Service Order Management, including:
• Data Setup for All Processes
• Enable Service for Items
• Disable Service for Meters
• Disable Service for Items
• Cut Service for Non-Payment for Meters
• Cut Service for Non-Payment for Items
• Reconnect Service for Payment for Meters
• Reconnect Service for Payment for Items
• Meter Exchange
• Item Exchange
• Back-to-Back for Meters
• Cancel Orchestration for Meters
• Update Orchestration for Meters
To view additional details about the objects referenced in this guide, use the appropriate
application portal.
Service Order Management Process Configuration 3-1

Data Setup for All Processes

This section outlines the data setup required to support the all Service Order Management
processes.
Customer Care and Billing

This section describes the setup required in Oracle Utilities Customer Care and Billing to support
Service Order Management processes. Refer to the Oracle Utilities Customer Care and Billing
Administration Guide for more information about creating the following types of data.
Service Point Types (SP Type)

The "Fieldwork Orchestration" field on SP Type records is used to define how the field work is
managed for service points of this type. Valid values are defined in the EXT_SRV_REQ_FLG
lookup, and include:
• Customer Care and Billing indicates that Oracle Utilities Customer Care and Billing will be
used to orchestrate field work based on FA Type Profile, customer event and service point
condition.
• Service Order Management indicates that Oracle Utilities Customer Care and Billing will
create generic field activities that are routed to an external service request system.
Orchestration of the actual field work request is managed by the external system.
Set the "Fieldwork Orchestration" field to "Service Order Management" for each SP Type where
the field work request will be managed by Service Order Management.
Example: SP Type: E-RES
Main Tab:
• Service Type: Electric Service
• Description: Electric - Residential
• Sub Type: Meter
• Allow Service Rule: [enabled]
• Multiple Route Usage: Not Allowed
• Trend Class: Residential Customers
• Fieldwork Orchestration: Service Order Management
• Field Activity Type Profile: METERED (see below)
Note: The example above does not capture the complete list of fields and their corresponding
values.
Outbound Message Types and XAI Components

Management Implementation Guide for details regarding outbound message types and XAI Senders
used by Oracle Utilities Customer Care and Billing to communicate with Service Order
Management.


This section describes the setup required in Service Order Management to support Service Order
Management processes. Refer to the and Oracle Utilities Application Framework Administration Guide
and Oracle Utilities Service and Measurement Data User’s Guide for more information about creating the
following types of data.
External Systems
You must create External Systems for both Oracle Utilities Customer Care and Billing and Oracle
Utilities Mobile Workforce Management in order to Service Order Management to communicate
with them. The minimum information that must be defined for each of these external systems is
outlined below.
Oracle Utilities Customer Care and Billing:
• Description: Oracle Utilities Customer Care and Billing
• Our Name In Their System: SOM
Management Implementation Guide for details regarding outbound message and XAI Senders
associated with this external system.
Oracle Utilities Mobile Workforce Management.:
• Description: Oracle Utilities Mobile Workforce Management
• Our Name In Their System: SOM
Service Providers
You must create Service Providers for both Oracle Utilities Customer Care and Billing and Oracle
Utilities Mobile Workforce Management. The minimum information that must be defined for
each of these is outlined below.
Oracle Utilities Customer Care and Billing:
• Description: Oracle Utilities Customer Care and Billing
• External System: Oracle Utilities Customer Care and Billing
• Utility Device ID Type: Badge Number
• Utility Measuring Component ID Type: Channel ID
• Utility Service Point ID Type: External ID
• Processing Methods: Define the following processing methods for each of the service
providers defined in Service Order Management.
Processing Method (Role) Description
Response - Negative Acknowledgement SR - Response - Negative Acknowledgement
Response - Fail SOM - Response - Fail
Response - Received SOM - Response - Positive Acknowledgement
Response - Success SOM - Response - Success

Management Implementation Guide for details regarding outbound message types used by these
processing methods.
Oracle Utilities Mobile Workforce Management.:
• Description: Oracle Utilities Mobile Workforce Management
• External Reference ID: SOM
• External System: Oracle Utilities Mobile Workforce Management
• Utility Device ID Type: Badge Number
• Utility Measuring Component ID Type: External ID
• Utility Service Point ID Type: External ID
• Processing Methods: Define the following processing methods for each of the service
providers defined in Service Order Management.
Processing Method (Role) Description
Field Activity MWM Create Outbound Communication

Default Business Object: D1-FieldActivityOBComm
Master Configuration
Define the following options on the Service Order Management master configuration.
Master Configuration: Service Order Management Master Configuration
• Business Object: Service Order Management Master Configuration
• Field Work System: Oracle Utilities Mobile Workforce Management
• CIS External Requestor: Oracle Utilities Customer Care and Billing
values.
Mobile Workforce Management

This section describes the setup required in Oracle Utilities Mobile Workforce Management to
support Service Order Management processes.
Refer to the Oracle Utilities Mobile Workforce Management User’s Guide for more information about
creating the following types of data.
External System
You need to an create External System for Service Order Management in order for Oracle Utilities
Mobile Workforce Management to communicate with it. The minimum information that must be
defined for each of these external systems is outlined below.
Service Management.:
• Description: Oracle Utilities Service Order Management
• Our Name In Their System: MWM

Enable Service for Meters

This section outlines the data setup required to support the Enable Service process for meters. See
Data Setup for All Processes on page 3-2 for information about data setup used by all services.

the Enable Service process for meters.
Refer to the Oracle Utilities Customer Care and Billing Administration Guide for more information about
Field Activity Type

The "Fieldwork Orchestration" field on Field Activity Type records is used to define how the field
work is managed for field activities of this type. Valid values are defined in the
EXT_SRV_REQ_FLG lookup, and include:
condition.
Set the "Fieldwork Orchestration" field to "Service Order Management" for each Field Activity
Type where the field work request will be managed by Service Order Management.
Example: Activity Type: SOM-START
Main Tab:
• Description: SOM - Start Activity
• Field Activity Priority: Priority 50
• Field Service Class: Meter Shop
• Eligible for Dispatch:
• Appointment Booking: Not Applicable
• Display as Alert:
• Nbr Days Alert Active: 0
values.
Field Activity Type Profile

Field Activity Type Profiles should reference applicable Service Order Management-enabled Field
Activity Types (see above).
Example - Field Activity Type Profile: METERED
Main Tab:
• Description: Metered Service
• FA Profile Template: Start Service
Template Tab:

• Customer Event: Start Service

• SP Field Condition: External Fieldwork Orchestration
• Sequence: 10
• Not Activity:
• Disconnect Location:
• Activity Type: SOM-START
Type Tab:
• Field Activity Type: SOM-START
values.

This section describes the setup required in Service Order Management to support the Enable
Service process for meters.
Refer to the Oracle Utilities Service and Measurement Data User’s Guide for more information about
Field Task Type

The Enable Service process for meter uses the following Field Task Types (defined as values for
the D1-FieldTaskTypeLookup extendable lookup).
• Connect SP at Source: D1-ConnectSPAtSource
• Connect SP at Meter: D1-ConnectSPAtMeter
• Connect SP at Source and Turn On: D1-ConnectSPAtSourceAndTurnOn
• Connect SP at Meter and Turn On: D1-ConnectSPAtMeterAndTurnOn
• Connect SP at Source and Install Meter: D1-ConnSPAtSrceAndInstMtr
• Connect SP at Meter and Install Meter: D1-ConnSPAtMtrAndInstMtr
• Install Meter: D1-InstallMeter
• Turn On Meter: D1-TurnOnMeter
Example: Field Task Type: D1-ConnectSPAtSource
• Field Task Type: D1-ConnectSPAtSource
• Status: Active
• Description: Connect SP at Source
• Routing: SP Required
• Appointment Option: Not Applicable
• Duplicate Task Type Information:
• Allow Duplicates: Yes
• Conflicting Task Type Information:
• Allow Conflicts: Yes
• Processing Scripts:
• CIS Data Retriever: Service Order - Retrieve CIS Data

• Internal Retriever: Service Order - Retrieve Internal Data

• External System Identifier Retriever: Service Order - Populate External System and
Identifiers
• Completion Events When Successful:
Field Business Object Required
10 Connect SP - Field Work Completion Yes
20 Update SP - Field work Completion No
30 Update Device - Field Work Completion No
40 Create To Do with Crew Message No
50 Notify Requestor of Customer Contact No
• Completion Events When Canceled:

N/A
Activity Type
You must create an Activity Type for the Enable Service process.
Example: Activity Type: Enable Service
• Activity Type: ENABLESERVICE
• Description: Enable Service Activity Type
• Activity Type Status: Active
• Activity Expiration Days: 10
• Override Device/Task Algorithm:
• Customer Device Compatibility Algorithm:
• Exception Handling:
• To Do Type: Activity To Do Type
• To Do Role: System Default Role
• Retry Frequency: 00:10:00
• Maximum Retries: 2
• Discard Reason:
• Find Measurement Criteria:
• Field Read Option: Use on Service Date
• Prorate Fail Action: Use Field Read
• To Do Type:
• To Do Role:
• Search Within the Day: No
• Minimum Offset Days: 2
• Maximum Offset Days: 2


Task Type
You must create task types that correspond to the field task types defined in Service Order
Management.
For example, the "Turn On Meter" field task type in Service Order Management could be mapped
to an "Electric Turn On Meter" task type in Oracle Utilities Mobile Workforce Management.
Mappings between Service Order Management field task types and Oracle Utilities Mobile
Workforce Management task types are defined using the SOM_MWM_TaskType domain value
map (DVM). Refer to the Oracle Utilities Service Order Management Integration to Oracle Utilities Mobile
Workforce Management Implementation Guide for more information about this DVM.
Example: Task Type: E-ON
• Activity Type: E-ON
• Description: Electric Turn On Meter
• Status: Active
• Average Duration: 00:10:00
• Auto Dispatch: Yes
• Acknowledgement Required: No
• Work Calendar: Default
• Eligible for Contracting: No
• Eligible for Assist: No
• Allow Breaks: No
• Allow Crew Time: No
• Activity Business Object: Activity
• Priority:
• Queue: Normal
• Preferred Time Factor: 1
• Ignore Sequence Locking: No
• Priority Profile: High
• Scheduling Priority: 1.00
• Procedures:
• Procedure Clearance Required: Yes
• Procedure Type: Meter Work Procedure
• Activities Creation:
• Create by Crew: Allowed
• Activity Expiration:
• Auto Extension: No

• Auto Cancel: No
• Capabilities:
• Crew Size: 1
• Worker Capability: Electric Meter Reading, Usage: Required, Count: 1
• Equipment: Basic Service Tools, Usage: Required
• Valid Remark Types:
• Remark Type: Mark for Review, Sort Sequence: 1
values.

Enable Service for Items

This section outlines the data setup required to support the Enable Service process for items. See

the Enable Service process for items.
Field Activity Type

condition.
Example: Activity Type: SOM-STRIT
Main Tab:
• Description: SOM - Start Item Activity
values.

Example - Field Activity Type Profile: ITEM
Main Tab:
• Description: Badged Item Service
Template Tab:


• Sequence: 10
• Not Activity:
• Activity Type: SOM-STRIT
Type Tab:
• Field Activity Type: SOM-STRIT
values.

Service process. for items
Field Task Type

The Enable Service process for items uses the following Field Task Types (defined as values for
• Connect SP at Source: D1-ConnectSPAtSource
• Item - Connect SP at Device: D1-ConnectSPAtDevice
• Item - Connect SP at Source and Turn On: D1-ConnSPAtSrceAndTurnOnDvc
• Item - Connect SP at Device and Turn On: D1-ConnectSPAtDvcAndTurnOn
• Connect SP at Source and Install Device: D1-ConnSPAtSrceAndInstDvc
• Connect SP at Device and Install Device: D1-ConnSPAtDvcAndInstDvc
• Item - Install Device: D1-InstallDevice
• Turn On Item: D1-TurnOnItem
Example: Field Task Type: D1-ConnectSPAtDevice
• Field Task Type: D1-ConnectSPAtDevice
• Status: Active
• Description: Item - Connect SP at Device


Identifiers
• MDM Data Retriever: Service Order - Retrieve Meter Data Details
10 Connect SP - Field Work Completion Yes
30 Update Item - Field Work Completion No

N/A
Activity Type
Example: Activity Type: Enable Service
• Activity Type: ENABLESERVICE
• Description: Enable Service Activity Type
• Discard Reason:
• To Do Type:
• To Do Role:


Service process for items.
Task Type
Management.
For example, the "Turn On Item" field task type in Service Order Management could be mapped
to an "Electric Turn On Item" task type in Oracle Utilities Mobile Workforce Management.
Example: Task Type: E-ONITEM
• Activity Type: E-ONITEM
• Description: Electric Turn On Item
• Status: Active
• Priority:
• Queue: Normal
• Procedures:

• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.

Disable Service for Meters

This section outlines the data setup required to support the Disable Service process for meters.
See Data Setup for All Processes on page 3-2 for information about data setup used by all
services.

the Disable Service process for meters.
Field Activity Type

condition.
Example: Activity Type: SOM-STOP
Main Tab:
• Description: SOM - Stop Activity
values.

Main Tab:
• FA Profile Template: Stop Service
Template Tab:


• Sequence: 10
• Not Activity:
• Activity Type: SOM-STOP
Type Tab:
• Field Activity Type: SOM-STOP
values.

This section describes the setup required in Service Order Management to support the Disable
Service process.
Field Task Type

The Disable Service process for meter uses the following Field Task Types (defined as values for
• Turn Off Meter: D1-TurnOffMeter
Example: Field Task Type: D1-TurnOffMeter
• Field Task Type: D1-TurnOffMeter
• Status: Active
• Description: Turn Off Meter
10 Disconnect Device - Field Work Yes

Completion
20 Create Field Work IMD Completion Event Yes
30 Update SP - Field Work Completion No


N/A
Activity Type
You must create an Activity Type for the Disable Service process.
Example: Activity Type: Disable Service
• Activity Type: DISABLESERVICE
• Description: Disable Service Activity Type
• Discard Reason:
• To Do Type:
• To Do Role:


Task Type
Management.
For example, the "Turn Off Meter" field task type in Service Order Management could be mapped
to an "Electric Turn Off Meter" task type in Oracle Utilities Mobile Workforce Management.
Example: Task Type: E-OFF
• Activity Type: E-OFF
• Description: Electric Turn Off Meter
• Status: Active
• Priority:
• Queue: Normal
• Procedures:

• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.

Disable Service for Items

This section outlines the data setup required to support the Disable Service process for items. See

the Disable Service process for items.
Field Activity Type

condition.
Example: Activity Type: SOM-STPIT
Main Tab:
• Description: SOM - Stop Item Activity
values.

Main Tab:
• FA Profile Template: Stop Service
Template Tab:


• Sequence: 10
• Not Activity:
• Activity Type: SOM-STPIT
Type Tab:
• Field Activity Type: SOM-STPIT
values.

Field Task Type

The Disable Service process for items uses the following Field Task Types (defined as values for
• Turn Off Item: D1-TurnOffItem
Example: Field Task Type: D1-TurnOffItem
• Field Task Type: D1-TurnOffItem
• Status: Active
• Description: Turn Off Item
10 Disconnect Item - Field Work Completion Yes


N/A
Activity Type
You must create an Activity Type for the Disable Service process.
Example: Activity Type: Disable Service
• Activity Type: DISABLESERVICE
• Description: Disable Service Activity Type
• Discard Reason:
• To Do Type:
• To Do Role:

Task Type
Management.
For example, the "Turn Off Item" field task type in Service Order Management could be mapped
to an "Electric Turn Off Item" task type in Oracle Utilities Mobile Workforce Management.

Example: Task Type: E-OFFITEM

• Activity Type: E-OFFITEM
• Description: Electric Turn Off Item
• Status: Active
• Priority:
• Queue: Normal
• Procedures:
• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.

Cut Service for Non-Payment for Meters

This section outlines the data setup required to support the Cut Service for Non-Payment process
for meters. See Data Setup for All Processes on page 3-2 for information about data setup used
by all services.

the Cut Service for Non-Payment process for meters.
Field Activity Type

condition.
Example: Activity Type: SOM-CUT
Main Tab:
• Description: SOM - Cut for Non-Payment Activity
• Alert Information: Cut for non-payment within 10 days
values.

Main Tab:
• FA Profile Template: Cut for Non-Payment

Template Tab:
• Customer Event: Cut for Non-Payment
• Sequence: 10
• Not Activity:
• Activity Type: SOM-CUT
Type Tab:
• Field Activity Type: SOM-CUT
values.

This section describes the setup required in Service Order Management to support the Cut
Service for Non-Payment process for meters.
Field Task Type

The Cut Service for Non-Payment process for meter uses the following Field Task Types (defined
as values for the D1-FieldTaskTypeLookup extendable lookup).
• Cut for Non-Payment: D1-CutForNonPayment
Example: Field Task Type: D1-CutForNonPayment
• Field Task Type: D1-CutForNonPayment
• Status: Active
• Description: Cut for Non-Payment
Identifiers

10 Disconnect Device - Field Work Yes

Completion
20 Create FA IMD Completion Event Yes

N/A
Activity Type
You must create an Activity Type for the Cut Service for Non-Payment process.
Example: Activity Type: Cut Service for Non-Payment
• Activity Type: CUTNOPAY
• Description: Cut Service for Non-Payment
• Always Dispatch Field Activity: No
• Ensure Business Hours: Yes
• Work Calendar: US Work Calendar
• Start Hour: 10:00AM
• End Hour: 06:00PM
• Discard Reason:
• To Do Type:
• To Do Role:


Service for Non-Payment process for meters.
Task Type
Management.
For example, the "Cut Service for Non-Payment" field task type in Service Order Management
could be mapped to an "Meter for Non-Payment" task type in Oracle Utilities Mobile Workforce
Management.
Example: Task Type: SOM-CUTFORNOPAY
• Activity Type: SOM-CUTFORNONPAY
• Description: SOM Cut Meter for Non-Payment
• Status: Active
• Appointment Booking Group: Weekday All Day
• Activity Business Object: Cut For Non-Payment Meter Activity
• Host Reference: D1-CutForNonPayment
• Host System: Oracle Utilities Service Order Management
• Priority:
• Queue: Normal
• Priority Profile: Mandatory
• Procedures:
• Procedure Clearance Required: No

• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.

Cut Service for Non-Payment for Items

This section outlines the data setup required to support the Cut Service for Non-Payment process
for items. See Data Setup for All Processes on page 3-2 for information about data setup used
by all services.

the Cut Service for Non-Payment process for items.
Field Activity Type

condition.
Example: Activity Type: SOM-CUTIT
Main Tab:
• Description: SOM Item - Cut for Non-Payment Activity
values.

Main Tab:
• FA Profile Template: Cut for Non-Payment

Template Tab:
• Customer Event: Cut for Non-Payment
• Sequence: 10
• Not Activity:
• Activity Type: SOM-CUTIT
Type Tab:
• Field Activity Type: SOM-CUTIT
values.

Service for Non-Payment process for items.
Field Task Type

The Cut Service for Non-Payment process for meter uses the following Field Task Types (defined
as values for the D1-FieldTaskTypeLookup extendable lookup).
• Item - Cut for Non-Payment: D1-CutItemForNonPayment
Example: Field Task Type: D1-CutItemForNonPayment
• Field Task Type: D1-CutItemForNonPayment
• Status: Active
• Description: Item - Cut for Non-Payment
Identifiers

10 Disconnect Item - Field Work Completion Yes

N/A
Activity Type
You must create an Activity Type for the Cut Service for Non-Payment process.
Example: Activity Type: Cut Service for Non-Payment
• Activity Type: CUTNOPAY
• Description: Cut Service for Non-Payment
• Always Dispatch Field Activity: No
• Ensure Business Hours: Yes
• Start Hour: 10:00AM
• End Hour: 06:00PM
• Discard Reason:
• To Do Type:
• To Do Role:


Service for Non-Payment process for items.
Task Type
Management.
For example, the "Item - Cut for Non-Payment " field task type in Service Order Management
could be mapped to an "Cut Item for Non-Payment" task type in Oracle Utilities Mobile
Workforce Management.
Example: Task Type: SOM-CUTITEMNOPAY
• Activity Type: SOM-CUTITEMNOPAY
• Description: SOM Cut Item for Non-Payment
• Status: Active
• Activity Business Object: Cut For Non-Payment Item Activity
• Host Reference: D1-CutItemForNonPayment
• Priority:
• Queue: Normal
• Procedures:

• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.

Reconnect Service for Payment for Meters

This section outlines the data setup required to support the Reconnect Service for Payment
process for meters. See Data Setup for All Processes on page 3-2 for information about data
setup used by all services.

the Reconnect Service for Payment process for meters.
Field Activity Type

condition.
Example: Activity Type: SOM-RECON
Main Tab:
• Description: SOM - Reconnect for Payment Activity
values.

Main Tab:
• FA Profile Template: Reconnect for Payment

Template Tab:
• Customer Event: Reconnect for Payment
• Sequence: 10
• Not Activity:
• Activity Type: SOM-RECON
Type Tab:
• Field Activity Type: SOM-RECON
values.

This section describes the setup required in Service Order Management to support the Reconnect
Service for Payment process for meters.
Field Task Type

The Reconnect Service for Payment process for meter uses the following Field Task Types
(defined as values for the D1-FieldTaskTypeLookup extendable lookup).
• Reconnect for Payment: D1-ReconnectForPayment
Example: Field Task Type: D1-ReconnectForPayment
• Field Task Type: D1-ReconnectForPayment
• Status: Active
• Description: Reconnect for Payment
• Appointment Option:
Identifiers

10 Connect Meter - Field Work Completion Yes

N/A
Activity Type
You must create an Activity Type for the Reconnect Service for Payment process.
Example: Activity Type: Reconnect Service for Payment
• Activity Type: RECONNECTPAY
• Description: Reconnect Service for Payment
• Discard Reason:
• To Do Type:
• To Do Role:


Task Type
Management.
For example, the "Reconnect for Payment" field task type in Service Order Management could be
mapped to an "Reconnect for Payment" task type in Oracle Utilities Mobile Workforce
Management.
Example: Task Type: SOM-RECONPAY
• Activity Type: SOM-RECONPAY
• Description: SOM Reconnect for Payment
• Status: Active
• Activity Business Object: Reconnect For Payment Activity
• Host Reference: D1-ReonnectForPayment
• Priority:
• Queue: Normal
• Procedures:

• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.

Reconnect Service for Payment for Items

This section outlines the data setup required to support the Reconnect Service for Payment
process for items. See Data Setup for All Processes on page 3-2 for information about data
setup used by all services.

the Reconnect Service for Payment process for items.
Field Activity Type

condition.
Example: Activity Type: SOM-RECIT
Main Tab:
• Description: SOM - Reconnect Item for Payment Activity
values.

Main Tab:
• FA Profile Template: Reconnect for Payment
Template Tab:

• Customer Event: Reconnect for Payment

• Sequence: 10
• Not Activity:
• Activity Type: SOM-RECIT
Type Tab:
• Field Activity Type: SOM-RECIT
values.

Service for Payment process for items.
Field Task Type

The Reconnect Service for Payment process for items uses the following Field Task Types
(defined as values for the D1-FieldTaskTypeLookup extendable lookup).
• Item - Reconnect for Payment: D1-ReconnectItemForPayment
Example: Field Task Type: D1-ReconnectItemForPayment
• Field Task Type: D1-ReconnectItemForPayment
• Status: Active
• Description: Reconnect for Payment
• Appointment Option:
Identifiers
10 Connect Item - Field Work Completion Yes


N/A
Activity Type
You must create an Activity Type for the Reconnect Service for Payment process.
Example: Activity Type: Reconnect Service for Payment
• Activity Type: RECONNECTPAY
• Description: Reconnect Service for Payment
• Discard Reason:
• To Do Type:
• To Do Role:


Task Type
Management.
For example, the "Item - Reconnect for Payment" field task type in Service Order Management
could be mapped to an "Reconnect Item for Payment" task type in Oracle Utilities Mobile
Workforce Management.
Example: Task Type: SOM-RECITPAY
• Activity Type: SOM-RECITPAY
• Description: SOM Reconnect Item for Payment
• Status: Active
• Activity Business Object: Reconnect Item For Payment Activity
• Host Reference: D1-ReonnectItemForPayment
• Priority:
• Queue: Normal
• Procedures:

• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.

Meter Exchange
Meter Exchange
This section outlines the data setup required to support the Meter Exchange process. See Data
Setup for All Processes on page 3-2 for information about data setup used by all services.

the Meter Exchange process.
Field Activity Type

condition.
Type where the field work request will be managed by Service Order Management. Meter
exchange field activities can include the following:
• SOM - Meter Exchange Program from Manual to Manual (SOM-MXM2M)
• SOM - Meter Exchange Program from Manual to Smart (SOM-MXM2S)
• SOM - Meter Exchange Rollout from Manual to Smart Meter (SOM-MXRMS)
• SOM - Exchange for Faulty Device from Manual to Manual Meter (SOM-XFM2M)
• SOM - Exchange for Faulty Device from Smart to Smart Meter (SOM-XFS2S)
• SOM - Meter Exchange Program from Smart to Smart Meter (SOM-MXS2S)
Example: Activity Type: SOM-MXM2S
Main Tab:
• Description: SOM - Meter Exchange Program from Manual to Smart
values.

Meter Exchange

Main Tab:
• FA Profile Template: Meter Exchange
Template Tab:
• Customer Event: Meter Exchange
• Sequence: 10
• Not Activity:
• Activity Type: SOM-MXM2S
Type Tab:
• Field Activity Type: SOM-MXM2S
values.

This section describes the setup required in Service Order Management to support the Meter
Exchange process.
Field Task Type

The Meter Exchange process uses the following Field Task Types (defined as values for the D1-
FieldTaskTypeLookup extendable lookup).
• Exchange Meter: D1-ExchangeMeter
Example: Field Task Type: D1-ExchangeMeter
• Field Task Type: D1-ExchangeMeter
• Status: Active
• Description: Exchange Meter

Meter Exchange

10 Remove Device - Field Work Completion Yes
20 Install Device - Field work Completion Yes

N/A
You can also create additional business-role specific meter exchange field task types as needed.
Examples include the following:
• SOMFTT_Exchange For Program Change Manual To Manual Meter
(FTT_ExchangeProgChangeM2M)
• SOMFTT_Exchange For Program Change Manual To Smart Meter
(FTT_ExchangeProgChangeM2S)
• SOMFTT_Exchange For Program Change Smart To Smart Meter
(FTT_ExchangeProgChangeS2S)
• SOMFTT_Exchange For Roll Out Manual To Smart Meter (FTT_ExchangeRollOutM2S)
• SOMFTT_Exchange Faulty Device Smart To Smart Meter (FTT_ExchangeS2S)
• SOMFTT_Exchange for Opt Out Smart To Manual meter (FTT_OptoutExchangeS2M)
Device Install Business Roles

The Device Install Business Role extendable lookup (D1-DeviceInstallSpecialRoleLkp) is used to
define specific business roles associated with meter exchanges. These roles can indicate specific
reasons for a meter exchange. Examples of device install business roles include the following:
• DIBR-Exchange Program Change Manual To Manual
• DIBR-Exchange Program Change Manual To Smart
• DIBR-Exchange Roll Out Manual To Smart
• DIBR-Exchange Program Change Smart To Smart
• DIBR-Exchange Faulty Device Manual To Manual
• DIBR-Exchange Faulty Device Smart To Smart
Meter Exchange Mapping

The Meter Exchange Mapping extendable lookup (D1-CCBMeterExchangeMap) is used to define
mappings between meter exchange field activity types in Oracle Utilities Customer Care and
Billing and device install business roles. In addition, specific service point / device configuration
type pairings can be defined for each mapping. Example mappings include the following:
Meter Exchange Device Install

Description Usage Flag
Field Activity Type Business Role
SOM-MXM2M SOM-Exchange Active DIBR-Exchange

Program Change Program Change
Manual To Manual Manual To Manual

Meter Exchange

SOM-MXM2S SOM-Exchange Active DIBR-Exchange

Program Change Program Change
Manual To Smart Manual To Smart
SOM-MXRMS SOM-Exchange Roll Active DIBR-Exchange

Out Manual To Smart Roll Out Manual To
Smart
SOM-MXS2S SOM-Exchange Active DIBR-Exchange

Program Change Smart Program Change
To Smart Smart To Smart
SOM- XFM2M SOM-Exchange Faulty Active DIBR-Exchange

Device Manual To Faulty Device
Manual Manual To Manual
SOM- XFS2S SOM-Exchange Faulty Active DIBR-Exchange

Device Smart To Smart Faulty Device
Smart To Smart
Activity Type
You must create an Activity Type for the Meter Exchange process.
Example: Activity Type: Meter Exchange
• Activity Type: METER_EXCHANGE
• Description: Meter Exchange
• Decommission Removed Meter?: Decommission
• Discard Reason:
• To Do Type:
• To Do Role:
• Meter Exchange Role Configuration:

Meter Exchange
Device Install Business Override Device /Task

Field Task Type
Role Algorithm
DIBR - Exchange Item Item - Exchange Device
DIBR-Exchange Faulty SOMFTT_Exchange Faulty

Device Manual To Manual Device Manual To Manual
Meter

Device Smart To Smart Device Smart To Smart
Meter
DIBR-Exchange Opt Out SOMFTT_Exchange for Opt

for Smart To Manual Out Smart To Manual meter
DIBR-Exchange Program SOMFTT_Exchange For

Change Manual To Manual Program Change Manual To
Manual Meter

Change Manual To Smart Program Change Manual To
Smart Meter

Change Smart To Smart Program Change Smart To
Smart Meter
DIBR-Exchange Roll Out SOMFTT_Exchange For D2-EVSMOPDV

Manual To Smart Roll Out Manual To Smart
Meter

Exchange process.
Task Type
Management.
For example, the "Meter Exchange" field task type in Service Order Management could be
mapped to an "Exchange Meter" task type in Oracle Utilities Mobile Workforce Management.
Example: Task Type: SOM-FD EXCHANGE_MM
• Activity Type: SOM-FD EXCHANGE_MM
• Description: SOM-FD Exchange MM
• Status: Active

Meter Exchange

• Activity Business Object: Meter Exchange Activity
• Host Reference: FTT_ExchangeM2M
• Priority:
• Queue: Normal
• Procedures:
• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.
Other task types can be created for individual role-based meter exchange field task types.
Examples include:
Task / Activity Type Host System
SOM_FD EXCHANGE_SS FTT_ExchangeS2S
SOM_OPT OUT EXCHANGE_SM FTT_OptoutExchangeS2M

Meter Exchange
SOM_PC EXCHANGE_MM FTT_ExchangeProgChangeM2M
SOM_PC EXCHANGE_MS FTT_ExchangeProgChangeM2S
SOM_ROLL OUT EXCHANGE_MS FTT_ExchangeRollOutM2S

Item Exchange
Item Exchange
This section outlines the data setup required to support the Item Exchange process. See Data
Setup for All Processes on page 3-2 for information about data setup used by all services.

the Item Exchange process.
Field Activity Type

condition.
Type where the field work request will be managed by Service Order Management. Meter
exchange field activities can include the following:
Example: Activity Type: SOM-XITEM
Main Tab:
• Description: SOM - Item Exchange
values.

Main Tab:
• FA Profile Template: Item Exchange
Template Tab:

Item Exchange
• Customer Event: Item Exchange

• Sequence: 10
• Not Activity:
• Activity Type: SOM-XITEM
Type Tab:
• Field Activity Type: SOM-XITEM
values.

Exchange process.
Field Task Type

The Meter Exchange process uses the following Field Task Types (defined as values for the D1-
FieldTaskTypeLookup extendable lookup).
• Exchange Device: D1-ExchangeDevice
Example: Field Task Type: D1-ExchangeDevice
• Field Task Type: D1-ExchangeDevice
• Status: Active
• Description: Exchange Device
10 Remove Device - Field Work Completion Yes
20 Install Device - Field work Completion Yes

Item Exchange

N/A
Device Install Business Roles

The Device Install Business Role extendable lookup (D1-DeviceInstallSpecialRoleLkp) is used to
define specific business roles associated with meter exchanges. These roles can indicate specific
reasons for a meter exchange. Examples of device install business roles include the following:
• DIBR-Exchange Item
Meter Exchange Mapping

The Meter Exchange Mapping extendable lookup (D1-CCBMeterExchangeMap) is used to define
mappings between meter exchange field activity types in Oracle Utilities Customer Care and
Billing and device install business roles. In addition, specific service point / device configuration
type pairings can be defined for each mapping. Example mappings include the following:

SOM-XITEM Field Activity for Item Active DIBR-Exchange

Exchange Item
Activity Type
You must create an Activity Type for the Meter Exchange process.
Example: Activity Type: Meter Exchange
• Activity Type: METER_EXCHANGE
• Description: Meter Exchange
• Decommission Removed Meter?: Decommission
• Discard Reason:
• Meter Exchange Role Configuration:

Field Task Type
Role Algorithm
DIBR - Exchange Item Item - Exchange Device

Device Manual To Manual Device Manual To Manual
Meter

Device Smart To Smart Device Smart To Smart
Meter

Item Exchange

Field Task Type
Role Algorithm
DIBR-Exchange Opt Out SOMFTT_Exchange for Opt

for Smart To Manual Out Smart To Manual meter

Change Manual To Manual Program Change Manual To
Manual Meter

Change Manual To Smart Program Change Manual To
Smart Meter

Change Smart To Smart Program Change Smart To
Smart Meter
DIBR-Exchange Roll Out SOMFTT_Exchange For D2-EVSMOPDV

Manual To Smart Roll Out Manual To Smart
Meter

Exchange process.
Task Type
Management.
For example, the "Meter Exchange" field task type in Service Order Management could be
mapped to an "Exchange Meter" task type in Oracle Utilities Mobile Workforce Management.
Example: Task Type: SOM_EXCHANGE_ITEM
• Activity Type: SOM_EXCHANGE_ITEM
• Description: SOM-FD Exchange Item
• Status: Active

Item Exchange
• Activity Business Object: Exchange Item Activity
• Host Reference: D1-ExchangeDevice
• Priority:
• Queue: Normal
• Procedures:
• Auto Cancel: No
• Capabilities:
• Crew Size: 1
values.
Other task types can be created for individual role-based meter exchange field task types.
Examples include:
SOM_FD EXCHANGE_SS FTT_ExchangeS2S
SOM_OPT OUT EXCHANGE_SM FTT_OptoutExchangeS2M
SOM_PC EXCHANGE_MM FTT_ExchangeProgChangeM2M
SOM_PC EXCHANGE_MS FTT_ExchangeProgChangeM2S
SOM_ROLL OUT EXCHANGE_MS FTT_ExchangeRollOutM2S

Back-to-Back for Meters

This section outlines the data setup required to support the Back-to-Back process for meters. See

the Back-to-Back process for meters.
Field Activity Type

condition.
Example: Activity Type: SOM-BTOB
Main Tab:
• Description: SOM - Back to Back Activity
values.
The Back-to-Back process also uses the following field activity types:
• SOM - Stop Activity (SOM-STOP)
• SOM - Start Activity (SOM-START)

Main Tab:


Template Tab:
• Customer Event: Start/Stop
• Sequence: 10
• Not Activity:
• Activity Type: SOM-FTOB
Type Tab:
• Field Activity Type: SOM-FTOB
values.
Algorithm
The "SA/SP Field Work Creation" (SASP FW CRE) algorithm type can be used to define details
for how field activities are created for pending start and pending stop service agreements shortly
before the pending start / stop date if field activities do not already exist (i.e., if a CSR hasn't
already created the field activities).
Algorithms of this type can be defined for the "Start Stop Field Work" SA Type system event (on
the Algorithms tab of the SA Type portal). Parameters (and sample values) used by algorithms of
this type include the following:
• Number of Days Lead Time: 3
• Back-to-Back Threshold Days: 7
• Wait Time for Meter Read: 5
• Field Activity Type for Meter Read: M-MR CYC
• SP's desired state for Meter Read: 30
• Immediate Field Activity Creation: Y

This section describes the setup required in Service Order Management to support the Back-to-
Back process for meters.
Field Task Type

The Back-to-Back process for meter uses the following Field Task Types (defined as values for the
D1-FieldTaskTypeLookup extendable lookup).
• Read Meter: D1-ReadMeter
Example: Field Task Type: D1-ReadMeter
• Field Task Type: D1-ReadMeter
• Status: Active
• Description: Read Meter


N/A
Activity Type
Example: Activity Type: Back to Back
• Activity Type: BACKTOBACK
• Description: Back to Back Service
• Discard Reason:
• To Do Type:
• To Do Role:



This section describes the setup required in Service Order Management to support the Back-to-
Back process for meters.
Task Type
Management.
For example, the "Read Meter" field task type in Service Order Management could be mapped to
an "Electric Meter Read" task type in Oracle Utilities Mobile Workforce Management.
Example: Task Type: E-MREAD
• Activity Type: E-MREAD
• Description: Electric Meter Read
• Status: Active
• Complete Within Option: Days
• Complete Within Days: 2
• Activity Business Object: Meter Read Activity
• Priority:
• Queue: Normal


• Procedures:
• Auto Extension: By Days
• Extension Days: 5
• Extension Limits: 3
• Auto Cancel: No
• Capabilities:
• Crew Size: 1
• Remark Type: Mark for Review, Sort Sequence: 1; Seal Broken, Sort Sequence: 2;
Customer Inquiry, Sort Sequence: 3
values.

Cancel Orchestration for Meters
Cancel Orchestration for Meters

This section outlines the data setup required to support cancelation of orchestration activities. See

This section describes the setup required in Service Order Management to support the canceling
orchestration activities.
Activity Type
You must create an Activity Type for canceling orchestration activities.
Example: Activity Type: Cancel Orchestration
• Activity Type: CANCELORCHESTRATION
• Description: Cancel Orchestration
• Discard Reason:

Update Orchestration for Meters
Update Orchestration for Meters

This section outlines the data setup required to support updating of orchestration activities. See

This section describes the setup required in Service Order Management to support the updating
orchestration activities.
Activity Type
You must create an Activity Type for updating orchestration activities.
Example: Activity Type: Update Activity Orchestration
• Activity Type: UPDATEACTIVITY
• Description: Update Activity Orchestration
• Discard Reason:

SGG SOM Configuration Guide v2 1-0-3123

Uploaded by

Copyright:

Available Formats

SGG SOM Configuration Guide v2 1-0-3123

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SGG SOM Configuration Guide v2 1-0-3123

Uploaded by

Copyright:

Available Formats

Oracle Utilities Smart Grid Gateway

Service Order Management

What Is This Book?

• Oracle Utilities Smart Grid Gateway Batch Server Administration Guide

Oracle Utilities Application Framework Configuration Tools

Understanding Service Order Management 2-1

Service Order Management Overview

What is Service Order Management?

How Does Service Order Management Work?

Receive / Create Service Order Request

2-2 Smart Grid Gateway Configuration Guide

Create Service Order Activity

Evaluate Service Point and/or Meter

Create Activities as Needed / Appropriate

Update Requesting System

Send Notification to Subscribing Systems

Supported Service Order Processes

Understanding Service Order Management 2-3

Cut for Non-Payment

Reconnect for Payment

2-4 Smart Grid Gateway Configuration Guide

Canceling Service Order Requests

Understanding Service Order Management 2-5

Updating Service Order Requests

2-6 Smart Grid Gateway Configuration Guide

Understanding Service Order Orchestration Activities

Understanding Service Order Processing

Service Order Orchestration Activity Lifecycle

Pending The initial state for orchestration activities.

An Enter algorithm sends an acknowledgement to the

The activity is transitioned to the next state via a monitor

Validate Enter algorithms perform the following:

Activities in this state can be corrected and retried.

Discarded Activities discarded in other states enter this state.

Enter algorithms perform the following:

A Monitor algorithm transitions the activity to the next state

Understanding Service Order Management 2-7

See Are SP and Device Ready? - Algorithm Types on page

A Monitor algorithm transitions the activity to the "Are the SP

A Monitor algorithm validates that the orchestration activity

An Exit algorithm resets the Expiration Date/Time on the

Activities in this state can be corrected and retried.

Retry When an orchestration activity is retried after correction of an

Enter algorithms perform the following:

An Enter algorithm send a success notification to the

Cancel / Update Orchestration Lifecycle

2-8 Smart Grid Gateway Configuration Guide

Are SP and Device Ready? - Algorithm Types

Customer-Device Compatibility Check (D1-DVCOMCHK)

Connect Only If Previously Connected (D1-CONPRECON)

Create Meter Exchange Field Activity (D1-CREMTREXC)

activityBOToCreate Specifies the activity business object to create.

specificFieldTask Specifies the Field Task Type when creating a field

Decommission Removed Meter (D1-DCRMMTR)

Understanding Service Order Management 2-9

• Decommission Activity BO to be created: Specifies the type of activity business object to

activityBOToCreate Specifies the activity business object to create.

Create Specific Activity (D1-CRSPACT)

servicePointConnected Specifies if the service point is currently connected

Valid values are “true" and "false".