C2M CA Design Document v1.0

C2M Solution Design Document
for
Customer Assistance
V1.0
Solution Design Document
Version Control
Version Date of Change Change Description Owner
v0.01 25-May-2022 Initial Version Nitin Sharma
v0.02 1-June-2022 Changes incorporated as Nitin Sharma

suggested on meeting held on 27-
May.
v0.03 06-July-2022 Changes incorporated as Nitin Sharma

suggested on meeting held on 24-
June.
Submitting for review iteration 1
V0.04 21-July-2022 Changes incorporated as Nitin Sharma

suggested in review comment
tracker
V0.05 1-August-2022 Changes incorporated as Nitin Sharma

suggested in review comment
tracker
V0.06 13-September- Logic incorporated for MUB Nitin

2022 holding-un-holding process. Sharma/Shiva
Included additional fields to the

payload as discussed
Customer Assistance Design Document Page 2 of 109

Table of Contents
1. Overview ......................................................................................................................................... 5
2. Business Process ............................................................................................................................. 5
CA-1: Receipt and Classification of Customer Concern ...................................................................... 5
Inquiries .......................................................................................................................................... 5
Requests ......................................................................................................................................... 7
Complaints ...................................................................................................................................... 8
Action needs to perform in C2M ................................................................................................. 10
3. Acronyms ...................................................................................................................................... 12
4. Glossary ......................................................................................................................................... 13
5. To-Be solution ............................................................................................................................... 14
5.1. Receipt and Classification of Customer Concern .................................................................. 14
Business Requirement Mapping ................................................................................... 14
Functional Process Flow ................................................................................................ 15
Solution Description ...................................................................................................... 15
Design Components ...................................................................................................... 52
High-Level Test Acceptance Criteria ............................................................................. 76
6. Generic Configurations ................................................................................................................. 77
6.1. Case Type .............................................................................................................................. 77
6.2. Characteristic Type................................................................................................................ 78
6.3. IWS Configuration ................................................................................................................. 80
6.4. Data Area .............................................................................................................................. 81
6.5. Custom Fields ........................................................................................................................ 82
6.6. Service Task Type .................................................................................................................. 82
6.7. Business Objects ................................................................................................................... 83
6.8. Service Scripts ....................................................................................................................... 85
6.9. Algorithm Types .................................................................................................................... 87
6.10. Algorithms ......................................................................................................................... 89
6.11. Plug-in scripts .................................................................................................................... 90
6.12. Feature Configurations ..................................................................................................... 91
6.13. Extendable Lookups .......................................................................................................... 91
6.14. External System................................................................................................................. 92
7. Integration Flow ............................................................................................................................ 95
8. Gap Analysis .................................................................................................................................. 97

9. Cross Reference Business Documents .......................................................................................... 98

10. Open/Closed Points ................................................................................................................ 107
11. Reporting Consideration ......................................................................................................... 107
12. Data Migration Consideration ................................................................................................ 107
13. Audit Consideration ................................................................................................................ 107
14. Review Comments .................................................................................................................. 108
15. Sign Off .................................................................................................................................... 108

1. Overview
This document aims to describe the specific functionalities and information about the Customer
Assistance process. This design is based on the respective business processes and requirements that
have been discussed in the Requirements Analysis workshops.
As a part of the Customer Assistance Process, the Management of Customer Concern is defined to
efficiently address customer concerns regarding the different customer process-related services. To
provide timely and accurate responses to customer queries, the process is drafted to ensure the
correctness of the information that shall be given to the customer.
2. Business Process
This section explains the design specifications for various business processes related to Customer
Assistance module.Each of the requirements will be given an identifier so that it can be tracked
during the design and testing phases. The business process for each of the requirements will be
captured end-to-end, which will be explained in detail below.
CA-1: Receipt and Classification of Customer Concern

Customer Assistance is the process of handling customer concerns received by the company. A
customer concern may be classified into inquiry, request, and complaint and feedback. The
Customer Assistance process starts when a customer contacts the company to raise a concern via
phone call, SMS, social media, email, and other contact channels.
Classification of Customer Concern

Inquiries
As a part of the Customer Assistance Process, the Management of Customer Inquiries is defined to
efficiently address customer inquiries on the different customer process-related services. To provide
a timely and accurate response to customer queries, the process is drafted to ensure the correctness
of the information that shall be given to the customer.
The types of inquiries that will be handled by the Company are any of the following:
CASE
RECORD CONCERN TYPE CONCERN SUB-TYPE
TYPE
Inquiry Billing & Payments Inquiry on a Service’s Reading Date
Inquiry Billing & Payments Inquiry on Bill / DN Delivery
Inquiry Billing & Payments Inquiry on Bill Amount and Bill Details
Inquiry Billing & Payments Inquiry on Bill Computation
Inquiry Billing & Payments Inquiry on Consumption
Inquiry Billing & Payments Delinquency Management Status
Inquiry Billing & Payments Bill Presentment Process
Inquiry Billing & Payments Inquiry on Delinquency Management Process
Inquiry Billing & Payments Inquiry on Payment
Inquiry Billing & Payments Payment Process
Inquiry Billing & Payments Payment Status
Inquiry Billing & Payments Schedule / Status of Bill / DN Delivery
Inquiry Billing & Payments Paperless Billing Subscription (and Cancellation)
Inquiry Billing & Payments Cash Advance Refund Inquiry
Inquiry Billing & Payments Inquiry on Payment Channel

Inquiry Billing & Payments Customer-Initiated Meter Reading
Inquiry Application for Electric Documentary Requirements Inquiry
Service
Inquiry Application for Electric Estimated Deposit Amount Inquiry
Service
Inquiry Application for Electric Inquiry on Application of New Service
Service
Inquiry Application for Electric Meter Deposit Refund Related
Service
Inquiry Application for Electric Service Application Status Inquiry
Service
Inquiry Prepaid Electricity Service Balance Inquiry
Inquiry Service Interruption Outage-Related Queries
Inquiry Service Interruption Schedule of Pre-Arranged interruption
Inquiry Products, Programs, and Net Metering
Service Offerings
Inquiry Products, Programs and Peak, Off-Peak
Service Offerings
Inquiry Products, Programs and Prepaid Service (PRES)
Service Offerings
Inquiry Products, Programs and Meralco Online + App
Service Offerings
Inquiry General Inquiry Energy Conservation Tips
Inquiry General Inquiry Inquiry on Concern Status
Inquiry General Inquiry Location / Contact Information of Service Offices
Inquiry General Inquiry Report a Bug
Inquiry General Inquiry General Concern
Table 1: Concern Type -Inquiries
All inquiries will be settled on the same day. The receiving personnel shall strive to provide the
information being requested by the customer. If the information is not readily available, the
receiving personnel shall be responsible for determining how the query can best be answered, by
company policies and procedures, and provide this information to the customer within the same
day.
For Service Irregularity (SI) cases, inquiries on the responsible service office or contact person will be
handled by the receiving office. However, if the concern on the SI case already pertains to details of
the case or bill, the customer shall be advised to contact the responsible office directly.

Requests
As a part of the Customer Assistance Process, the Management of Customer Requests is defined to
efficiently address customer requests related to customer service processes. To satisfy the needs of
the customers, the process is drafted to ensure timely and quality provision of the requested service
of the customer.
The types of requests that will be handled by the Company are any of the following:
CASE RECORD CONCERN TYPE CONCERN SUB-TYPE

TYPE
Request Payment Enrollment & Update Request for Billing Adjustment (BA) Discount
Request Payment Enrollment & Update Request for Service Irregularity (SI) Discount
Request Payment Enrollment & Update Request for Official Receipt
Request Payment Enrollment & Update Request for IPA
Request Payment Enrollment & Update Request for Inclusion of IPA to APA
Request Payment Enrollment & Update Update on Account Details
Request Payment Enrollment & Update Payment Extension
Request Payment Enrollment & Update IPA Extension
Request Billing Enrollment & Update Bill Duplicate Request
Request Billing Enrollment & Update Request for Billing History
Request Meter Concerns Request for Meter Reading Schedule
Request Meter Concerns Request for Meter Replacement
Request Meter Concerns Request for Meter Test
Request Meter Concerns Request for Special Meter Reading
Request Meter Concerns Request to Witness Meter Reading
Request Meter Concerns RCOA - Special Meter Reading
Request Refunds Bill Deposit Refund (Contract Terminated)
Request Refunds Bill Deposit Refund (Good Credit Standing)
Request Refunds Refund of Credit (Account)
Request Refunds Refund of Meter Deposit
Request Service Maintenance Request for Assistance in Maintenance of
Customer Facilities
Request Service Maintenance Request for Copy of Power Interruption
History
Request Service Maintenance Request for Exemption from Power
Interruption
Request Service Maintenance Request for Postponement of Power
Interruption
Request Service Maintenance Line Conductor Cover Installation
Request Service Maintenance Line Conductor Cover Removal
Request Service Maintenance Request for Temporary Power Interruption
Request Service Maintenance Testing
Request Service Maintenance Miscellaneous
Request Service Maintenance RCOA – Desist from Disconnection
Request Service Maintenance RCOA – Disconnection
Request Service Maintenance RCOA – Reconnection
Request Service Maintenance Enrollment to ILP & Update
Request Prepaid Electricity Service Update on Account Details
Request Prepaid Electricity Service Request for Prepaid Loading History

Request Other Support Services Others (Service Application) – Request for

Equipment Rental
Request Other Support Services Others (Service Application) – Request for
Mechanical / Chemical Testing
Request Other Support Services Request for Escort Services
Request Other Support Services Request for Cleaning of Transformer Vault
Request Other Support Services Request for Certificate of Bill Deposit
Request Other Support Services Request for Copy of Documents
Request Other Support Services Request for Copy of Load Profile
Request Other Support Services RCOA – Request for Duplicate Copy of COC
Request Other Support Services Request for POP Simulation Comparison
Request Other Support Services Meralco Online + App (Modification)
Request Other Support Services Request for Power Quality
Request Blacklisting Lifting of Check Blacklist
Request Blacklisting Lifting of APA Blacklist
Request Payment Enrollment & Update MUB Suspension
Request Payment Enrollment & Update Payment Reallocation
Request Payment Enrollment & Update Credit Transfer
Request Payment Enrollment & Update Credit Allocation
Request Service Maintenance Tree-Trimming
Request Other Support Services Certification of Unpaid Bills
Table 2: Concern Type-Request
The receiving office shall be responsible for creating record for these requests. The processing of
requests for Line Conductor Cover Installation, Line Conductor Cover Removal, Escort Services,
Temporary Power Interruption, etc. will be the responsibility of the Corporate Business Group, Home
and Micro Business Group and BIZ Partners Group.
Complaints
As a part of the Customer Assistance Process, the Management of Customer Complaints is defined to
efficiently address customer Complaints related to customer service processes. To satisfy the needs
of the customers, the process is drafted to ensure timely and quality provision of the requested
service of the customer.
The types of complaints that will be handled by the Company are any of the following:
CASE RECORD
CONCERN TYPE CONCERN SUB-TYPE
TYPE
COMPLAINT Billing & Payments High Billing
COMPLAINT Billing & Payments Low Billing
COMPLAINT Billing & Payments Undelivered Bill
COMPLAINT Billing & Payments Vacant with Consumption
COMPLAINT Billing & Payments Disconnected with Consumption
COMPLAINT Billing & Payments Flat Streetlight High Billing
COMPLAINT Billing & Payments Erroneous BA Bill
COMPLAINT Billing & Payments Erroneous Payment Posting
COMPLAINT Billing & Payments Erroneous AWA Tagging
COMPLAINT Billing & Payments Unposted Payment
COMPLAINT Meter Concerns Blurred Meter Glass
COMPLAINT Meter Concerns Broken Meter Glass Cover
COMPLAINT Meter Concerns Broken / Missing Terminal Seal

COMPLAINT Meter Concerns Burnt Meter
COMPLAINT Meter Concerns Deformed / Detached Parts Inside Meter
COMPLAINT Meter Concerns Dial Pointers Out of Alignment
COMPLAINT Meter Concerns Fast / Slow Meter
COMPLAINT Meter Concerns Interchanged Meter
COMPLAINT Meter Concerns Meter Running Even w/o Load
COMPLAINT Meter Concerns Meter with Dirt Inside
COMPLAINT Meter Concerns Meter with No Display
COMPLAINT Meter Concerns Stolen Meter
COMPLAINT Meter Concerns Stopped Meter
COMPLAINT Application for Electric Service
Erroneous Contract Data
COMPLAINT Service Irregularity Denial of Violation
COMPLAINT Service Irregularity Erroneous SI Bill
COMPLAINT Service Irregularity Kuryente Watch Report
COMPLAINT Billing & Payments Erroneous APA Enrolment
COMPLAINT Billing & Payments Erroneous APA Cancellation
COMPLAINT Billing & Payments Electronic Bill Availability
COMPLAINT Billing & Payments Bill & Pay Notifications
COMPLAINT Prepaid Electricity Service Clawback & Rates
COMPLAINT Prepaid Electricity Service Erroneous Deduction of Load
COMPLAINT Prepaid Electricity Service No Notification Received for Top-Up
COMPLAINT Prepaid Electricity Service No Power with Load
COMPLAINT Prepaid Electricity Service Unable to Top-up
COMPLAINT Incident Report Accident to Public
COMPLAINT Incident Report Administrative Case (Meralco Employee /
Contractual Employee Related) - separate
COMPLAINT Incident Report Confinement (Off-Duty)
COMPLAINT Incident Report Confinement (On-Duty)
COMPLAINT Incident Report Damage to Company Property
COMPLAINT Incident Report Damage to Private Property
COMPLAINT Incident Report Damage to Public Property
COMPLAINT Incident Report Electrically Shocked
COMPLAINT Incident Report Electrocution
COMPLAINT Incident Report Employee Accident
COMPLAINT Incident Report Pilferage (Energy)
COMPLAINT Incident Report Pilferage (Property)
COMPLAINT Incident Report Vehicular Accident
COMPLAINT Customer Service Feedback Customer Service Feedback
COMPLAINT Products, Programs and Service AMC - Availment of Services
Offerings
COMPLAINT Products, Programs and Service Bayad Center - Availment of Services
Offerings
COMPLAINT Products, Programs and Service MIESCOR - Availment of Services
Offerings
COMPLAINT Products, Programs and Service MSERV - Availment of Services
Offerings
COMPLAINT Products, Programs and Service Non-AMC - Availment of Services
Offerings
COMPLAINT Products, Programs and Service RADIUS - Availment of Services

Offerings
COMPLAINT Products, Programs and Service Republic Surety - Availment of Services
Offerings
COMPLAINT Products, Programs and Service SPECTRUM - Availment of Services
Offerings
COMPLAINT Products, Programs and Service Meralco Online + App
Offerings
COMPLAINT Other Support Services Interruptible Load Program (ILP)
COMPLAINT Other Support Services Not Satisfied with Energy Walkthrough Audit
COMPLAINT Other Support Services Not Satisfied with Power Quality Walkthrough
Audit
COMPLAINT Other Support Services RCOA – Meter Data Provision
COMPLAINT Other Support Services Violation of DPA
Table 3: Concern Type-Complaint
• As much as possible, all customer complaints should be made in writing except when the
complaint is regarding power interruption or operating trouble related.
• A written protest letter shall be requested from the customers making a complaint.
• The letter shall include the details on the exact nature of the complaint, any justification or proof
that will support the customer’s claim, the desired action of the customer to resolve the
complaint, customer identity and location and contact information for customer feedback.
However, if the customer does not wish to write the letter, the complaint shall still be received
and recorded.
• The receiving personnel shall check with the customer the accuracy of the complaint that was
taken.
• The receiving personnel shall ensure that customer complaints are referred to the appropriate
responsible office for handling.
• Complaints on Power Outages and other Distribution Facility related troubles shall be handled by
Customer Care Group, HMB, BIZ, and CBG.
Action needs to perform in C2M

• Front-end process to be handled in the Salesforce CXE. The solution should be able to receive
the triggers sent by the Salesforce CXE to initiate the actions needed to be done in the CIS such
as generation of field order, creation of billing adjustment record, rebill/cancellation of a bill,
etc. The solution should also be able to send updates to the Salesforce CXE for purposes of
informing the customer of the status of his concern. Additionally, the solution should be able to
capture the multiple entities that will be associated with a certain case record (i.e., services, bills,
payments, etc.).
• Below is the list of the interfaces that will trigger handling in C2M:

Table 4: Interface List
• All concern types as well as the actions for each are listed in the attached concern inventory file
below.
CIS_CA_DesignMatr
ix.xlsx
• All action/transaction (e.g. billing adjustment, discount application, etc.) updates and resolution
details will be sent to CXE by C2M.
Provision of Feedback to Customer Regarding Customer Concerns
• Feedback shall be provided on all customer-initiated customer service-related concerns.

• Feedback shall be provided by the office responsible for the management of the concern.
• Feedback shall be addressed to the person who filed the concern.
• Feedback shall be reviewed by the responsible Team Leader to ensure completeness and
accuracy of the information to be relayed to the customer.
• The associated Concern Record shall only be considered closed upon provision of final feedback
to the customer and update of feedback receipt details.
Note: Feedback letter generated in CXE for the customer.
Complaints
• As much as possible, the customers shall be updated on the actions being done to resolve
their complaints.
• Feedback to the customer shall be given within fifteen (15 days) from receipt of the
complaint through a letter (Feedback Letter or FL).
• If the resolution of the complaint will take more than fifteen (15) days, an initial feedback
letter shall be provided to the customer.
• Once the concern is resolved, Meralco will provide the final feedback letter to the customer.
• The recipient and receipt date and time of the feedback letter shall be recorded.
• The Concern Record shall be considered closed when no further communication is received
from the customer within fifteen (15) days from receipt of the final feedback letter.
• Receiving a copy of the feedback letter shall be filed for records purposes.
Requests
• The requesting customer shall be informed of the status and details of the request in writing
within five (5) working days from receipt of the request.
Close Concern Record
Generally, a Concern Record shall be considered closed upon provision of final feedback to the
customer and recording of the feedback receipt details. As for complaints, a customer shall be
given fifteen (15) days starting from receipt of the final feedback to raise his issues about the
matter. In case no feedback was received from the customer within that period then the
Concern Record shall already be considered closed. Additionally, if the concern is resolved in
CXE, an interface with C2M should take place to lift the suspension of Management of Unpaid
Bills (MUB).
C2M must observe permanent deletion of personal data collected and processed for the
management of customer inquiries, requests, and complaints, especially when the concern
record is already closed. Per the DPA of 2012, personal data must be permanently deleted once
the purpose for collecting/processing such has already been fulfilled.
3. Acronyms
Acronym Description
C2M Customer to Meter
CA Customer Assistance
CXE Customer Experience Engine

EAM Enterprise Asset Management

Acronym Description
FO Field Order
IVR Interactive Voice Response
IWS Inbound Web Service
MDM Meter Data Management
MUB Management of Unpaid Bill
OTC One Time Charges
RFO Reconnection Field Order

R&C Rating and Charging
SA Service Agreement
SI Service Irregularity
STMS Stop Theft Monitoring System

Table 5: Acronyms
4. Glossary
SNO Feature Name Description
1 Bill cycle Billing interval of an account
2 Bill Segment Account Services Segments on a Bill
Customer class in C2M is used for the classification of the

3 Billing Class
customer
A lifecycle-based component in C2M. It is used for

4 Business Object
development purposes.
5 Case Life cycle process in C2M
A configurable component, used in C2M to configure a

6 Extendable Lookup
key and its dependent values.
A new row/value configured under the lookup

7 Feature Type
EXT_SYS_TYP_FLG will be known as a Feature Type
In C2M terminology it is the medium by which

8 Interface
communication is done with an external system
Inbound web services are the configurable component in

9 IWS C2M. This is a component which provides placeholder to
configure component which has business logic to be
executed with an XML wrapper over it. XML wrapper will

SNO Feature Name Description
be exposed to the external system for Integration

purpose.
Lookup is a configurable component in C2M which is used

10 Lookup
to configure A key and its related values.
Option Types are the Allowable Types of the values, these

11 Option Type Types are used to configure different values matching
with a Feature Type in Feature Configuration.
The interfaces for which the target system is C2M are

Inbound and Outbound termed as Inbound Interfaces
12
Interfaces whereas the interfaces for which the source system is
C2M are termed as Outbound Interfaces
A configurable component, which is known as Case Type

13 Life-cycle process in C2M. Using this component, a set of processes can be
designed to handle a requirement
Table 6:Glossary
5. To-Be solution
This section explains the intended solution and the specifications for various process components in
respective C2M functionality. Process components for each business process will be detailed end to
end. The scope of each business process and related components in each of the business flows will
be explained in detail.
5.1. Receipt and Classification of Customer Concern

Business Requirement Mapping
Requirement Id Business Requirement Description
CA-1 Receipt and Classification of Customer Concern.
Table 7:Business Requirement Mapping

Functional Process Flow
Figure 1: Functional Process Flow
Solution Description
Design Overview
• Customer Assistance process as described in the Flow diagram starts with accepting and lodging
the consumer concerns
• A consumer concern can be related to any of the services it is using like Billing, Payments,
Metering, etc.
• CXE System handles the entire lifecycle of the consumer concern request processing.
• For every user concern request, CXE System will create a Concern Record in its system.
• CXE System will then gather relevant information for the concern.
• For Inquiries, there shall be no need for interface between CXE and C2M. But there are other
concerns for which CXE system will have to communicate with C2M system. Such concerns are
Complaints or Requests.
• For the communication purpose with C2M system, Interfaces are proposed.
• Interfaces are the medium for the communication in between C2M system and any external
system.
• Classification of customer concerns and Interfaces is available in the Business Process section.
• CXE will use the CXE Case Number (CaseNumber) of its system as the Primary Key to
Communicate with C2M. The CXE Case Number shall be stored together with the Life Cycle
record or transaction that will be created after the interface.
• The same Key will be used by C2M System to send the updates on concern back to the CXE
System.

• The following sections will cover up the proposed solution to handle the C2M dependent action
items for the different Concern Types.
• There will be a facility to manually create a Service Task or CA record.
• Users will be allowed to bypass or skip some events or processes in the child activity as needed.
• The outline of the solution design for the communication process in between CXE and C2M
System primarily involves following processes:
➢ Classification and Designing the Interfaces.

➢ Processing the Interfaces.
➢ Update external System on the status of the Life-cycle process initiated in C2M.
➢ Data Management Mechanism.
Classification and Designing the Interfaces.
• Interfaces are the main design components; it has a business logic to process and an XML
wrapper over it.
• XML wrapper contains Data Fields. Data Fields are the main place holder in the interface for the
incoming and outgoing data
• Data Fields are designed as per the requirement.
• Data Fields can be put in Input/Output groups to separate the fields.
• Set of Data Fields is known as Payloads/Schema of the interface.
• Interfaces will be exposed to the External System by a Service URL. Payload information will be
kept in a file and will be shared to the External System. This document will be the part of
Integration documents for different services.
• The following diagram is the sample payload and common field related information for interface
between CXE and C2M. Common field will be used by both system for syncing the data.
Figure 2: Payload Information between CXE and C2M

• Based on the requirement and scope, the interfaces can be divided into 2 major categories
Inbound and Outbound.
• For any communication where the Target system is C2M it will be the handled by an Inbound
Interfaces. Whereas for Outbound Interface C2M system will work as Source System.
• Communication of C2M with the External System is ruled by another layer which is known as the
middle/Integration Layer.
• Following diagram explains the role of different layers and the Interface hierarchy:
Figure 3:Interface Hierarchy
5.1.1.2.1. External Systems

• Every System other then C2M will be treated as an External System.
• For Example, CTI, CXE, Rating and Charging.
5.1.1.2.2. Middle Layer

• Both Inbound/Outbound interfaces are channeled by a middle layer.
• It routes the data between the C2M system and External System.
• The integration layer accepts the request payloads and designs them in a dedicated system
acceptable format. The same action is required while getting the response.
5.1.1.2.3. CIS System

• It is the Parent System which holds all Admin data and Transactional Data related to different
modules like Billing, Payments, SI, MUB/C&C, SA, Metering.
• For Example: C2M
Processing Interfaces in C2M
• As explained, interfaces are the main component used for communication with C2M.

• Handling of the concerns in C2M further requires processes, sub-process, and the action items to
be triggered.
• An Inbound Interface to the C2M further triggers the action items in C2M system. This will be
fully an automated activity.
• The action items can belong to the different module like Billing, Payments, Metering, Field
Orders, MUB (Credit & Collection) etc.
• A detailed explanation of the action items/process is available in the module specific SDD.
• Details of the concerns processes is available in the following file. This file also has the detail of
the processes involved for handling of the concerns in C2M.
CIS_CA_DesignMatr
ix.xlsx
• As it is clear from the file, the handling of the concerns in C2M will be driven by the processes.
• In this document, handling of the concerns will be explained processes wise rather concern wise
as concerns may have common set of the processes.
• Now based on the handling of the concerns in C2M, concerns can be categorized primarily in
following two types:
1. Handling through Life-Cycle Process Initiation – For some consumer concerns handling is
required a lifecycle process initiation in C2M. Process Initiation will be automated. Handling
of the process will be done within the lifecycle process.
2. Handling through Transaction in C2M – This category will cover up the consumer concerns
for which initiation of a transaction in C2M system is required. For example, FO initiation,
Device Event Initiation, Account data updating, Person mobile number updating etc. Here
also Initiation of the transaction in C2M will be automated.
Following is the list of some common Processes/Sub-Processes which are involved directly or
internally in the handling of the concerns, In the following sections these are explained in detail.

Figure 4:List of Common Process/Sub-process
5.1.1.3.1. Handling through Life-Cycle Process Initiation

In this section the processes which are involved in handling of the concerns through life-cycle
process is listed and explained.
5.1.1.3.1.1 Billing Adjustment

❖ Several Billing and Metering concerns require a lifecycle process to be initiated in C2M to
handle the requirement.
❖ Billing Adjustment process will be the part of the lifecycle process for such scenarios.
❖ Detail of the life cycle process which includes creation of adjustments, Holding/un-Holding
MUB, and initiation and execution of EAM and non-EAM FO is explained in flow diagram.
❖ Billing Adjustment process related details is captured in the Billing module SDD. Details of
the SDD section is given in the concerns table below.
❖ The actual Billing Adjustment transaction will be initiated within the concern Lifecycle in
C2M.
❖ Once the Lifecycle for the concern process in C2M is completed, an Outbound interface shall
be initiated to inform CXE of the closing of the transaction in C2M.
❖ Details required to process the Billing Adjustment record and proceed with the Billing
Adjustment transaction will be inputted in C2M.
❖ For billing and meter reading complaints, the user can bypass steps or activities in the
lifecycle as needed. For example, the user may not need to perform a billing adjustment for
a concern type lifecycle.

Figure 5: Life Cycle process Flow Diagram for handling Billing Concerns

Figure 6: Life Cycle process Flow Diagram for handling Metering Concerns
Following Concerns has this process involved in handling of the concern:
SNo Concern Sub Reference Document C2M Proposed Input Fields

Type
1 High Billing Billing Module SDD, Billing
Adjustment, Section: 5.7.8.1
2 Low Billing Billing Module SDD, Billing
Adjustment, Section: 5.7.8.1
3 Disconnected Billing Module SDD, Billing
with Adjustment, Section: 5.7.8.1
Consumption
4 Vacant with Billing Module SDD, Billing
Consumption Adjustment, Section: 5.7.8.1
5 Erroneous BA Billing Module SDD, Billing
Bill Adjustment, Section: 5.7.8.1
6 Flat Streetlight Billing Module SDD, Billing
High Billing Adjustment, Section: 5.7.8.1
7 Blurred Billing Module SDD, Billing
Meter Glass Adjustment, Section: 5.7.8.1
8 Broken Billing Module SDD, Billing <caseNumber></caseNumber> // Legacy System Field-

Meter Glass Adjustment, Section: 5.7.8.1 mandatory
<RequestSource></RequestSource> // Legacy System Field-
Cover
mandatory
9 Broken / Billing Module SDD, Billing <ConcernType></concernType> // Legacy System Field-
Missing Adjustment, Section: 5.7.8.1 mandatory
Terminal Seal <ConcernSubtype></concernSubtype> // Legacy System Field-
10 Burnt Meter Billing Module SDD, Billing mandatory
Adjustment, Section: 5.7.8.1 <ConcernDescription></ConcernDescription> // Legacy System
Field-mandatory
11 Deformed / Billing Module SDD, Billing <MobNo></MobNo> // Legacy System Field-optional
Detached Adjustment, Section: 5.7.8.1 <Email></Email> // Legacy System Field-optional
Parts Inside <CANNO></CANNO> // Legacy System Field-mandatory
Meter <caseOwner></caseOwner> Legacy System Field-mandatory
12 Dial Pointers Billing Module SDD, Billing <responsibleOffice><responsibleOffice>// Legacy System Field-
mandatory
Out of Adjustment, Section: 5.7.8.1
<payorLegacyAccountNumber></payorLegacyAccountNumber>
Alignment Legacy System Field-mandatory
13 Fast / Slow Billing Module SDD, Billing <SIN></SIN> // Legacy System Field-optional
Meter Adjustment, Section: 5.7.8.1 <BILL_ID></BILL_ID> // C2M Field- mandatory for Billing
14 Interchanged Billing Module SDD, Billing Concern
Meter Adjustment, Section: 5.7.8.1 <RefundMode></ RefundMode> // C2M Field-
optional/Manually Entered Field
15 Meter Billing Module SDD, Billing <amountToAllocate><amountToAllocate>//C2M Field-
Running Even Adjustment, Section: 5.7.8.1 optional/Manually Entered Field
w/o Load <targetAccount></targetAccount>// C2M Field-
16 Meter with Billing Module SDD, Billing optional/Manually Entered Field
Dirt Inside Adjustment, Section: 5.7.8.1 <PAY_EVENT_ID></PAY_EVENT_ID>// C2M Field-
17 Meter with Billing Module SDD, Billing
<reasonForTransfer></reasonForTransfer> C2M Field-
No Display Adjustment, Section: 5.7.8.1 optional/Manually Entered Field
18 Stopped Billing Module SDD, Billing <dataToUpdate><dataToUpdate>// C2M Field-
Meter Adjustment, Section: 5.7.8.1 optional/Manually Entered Field
<daystoExtend></daystoExtend>// C2M Field-
<erroneousSIBill></erroneousSIBill> // C2M Field-
<noOfInstallment></noOfInstallment> // C2M Field-
<installmentAmount></installmentAmount> // C2M Field-
Table 8: Concerns List: Handling involves Billing Adjustment process
5.1.1.3.1.2 On-holding of MUB/removal of on-holding of MUB

❖ While handling certain concerns till the time the concern is closed, holding or suspension of
the delinquency process is required.
❖ Triggering of Holding/un-Holding of MUB process can be triggered within the lifecycle
process of other concern or it can be directly triggered directly through Inbound Interfaces
for handling certain concern. More details are listed in the following table.
❖ Triggering of Holding/un-Holding of MUB process will be an automated activity, in both
scenarios as if it is initiated within the lifecycle, it will be the part of the business process and
will be handled by the algorithms plugged-in to the lifecycle process statuses. In the second
scenario, if the request is coming directly from the CXE, then there will be a dedicated

lifecycle process to handle the process. Initiation of this dedicated lifecycle process will be
automatically triggered by the Inbound interface request.
❖ The moment concerns will get closed, the removal of suspension of the delinquency process
is required.
❖ This activity plays a very important role in handling of many concerns.
❖ A detailed explanation of this process is given in the module-MUB SDD and in CA SDD.
❖ Check the following details of the concerns for which this process is used directly/internally.
SNo Concern Sub Reference MUB On- C2M Proposed Input Fields
Type Document holding
/removal
of on-
holding
process
initiation
1 High Billing CA Module SDD, Triggered
On-holding of in another
MUB/removal of Lifecycle
on-holding of process
MUB: Solution
Description,
Section: 5.1.3.6.3.
2 Low Billing CA Module SDD, Triggered
MUB: Solution
Description,
Section: 5.1.3.6.3.
3 Disconnected CA Module SDD, Triggered
with On-holding of in another
Consumption MUB/removal of Lifecycle
MUB: Solution
Description,
Section: 5.1.3.6.3.
4 Vacant with CA Module SDD, Triggered
Consumption On-holding of in another
MUB: Solution
Description,
Section: 5.1.3.6.3.
5 Undelivered CA Module SDD, Triggered
Bill On-holding of in another
MUB: Solution
Description,
Section: 5.1.3.6.3.
6 Flat CA Module SDD, Triggered
Streetlight On-holding of in another
High Billing MUB/removal of Lifecycle
MUB: Solution
Description,
Section: 5.1.3.6.3.
7 Erroneous BA CA Module SDD, Triggered <caseNumber></caseNumber> // Legacy System Field-

Bill On-holding of in another mandatory
MUB/removal of Lifecycle <RequestSource></RequestSource> // Legacy System Field-
on-holding of process mandatory
MUB: Solution <ConcernType></concernType> // Legacy System Field-
Description, mandatory
Section: 5.1.3.6.3. <ConcernSubtype></concernSubtype> // Legacy System Field-
8 Erroneous CA Module SDD, Triggered mandatory
Payment On-holding of in another
<ConcernDescription></ConcernDescription> // Legacy System
Posting MUB/removal of Lifecycle
Field-mandatory
MUB: Solution <MobNo></MobNo> // Legacy System Field-optional
Description, <Email></Email> // Legacy System Field-optional
Section: 5.1.3.6.3. <CANNO></CANNO> // Legacy System Field-mandatory
9 Unposted CA Module SDD, Triggered <caseOwner></caseOwner> Legacy System Field-mandatory
Payment On-holding of in another <responsibleOffice><responsibleOffice>// Legacy System Field-
MUB/removal of Lifecycle mandatory
on-holding of process <payorLegacyAccountNumber></payorLegacyAccountNumber>
MUB: Solution Legacy System Field-mandatory
Description, <SIN></SIN> // Legacy System Field-optional
Section: 5.1.3.6.3. <BILL_ID></BILL_ID> // C2M Field- mandatory for Billing
10 Denial of CA Module SDD, Triggered Concern
Violation On-holding of in another <RefundMode></ RefundMode> // C2M Field-
MUB/removal of Lifecycle optional/Manually Entered Field
on-holding of process <amountToAllocate><amountToAllocate>//C2M Field-
MUB: Solution optional/Manually Entered Field
Description, <targetAccount></targetAccount>// C2M Field-
Section: 5.1.3.6.3.
11 Erroneous SI CA Module SDD, Triggered
<PAY_EVENT_ID></PAY_EVENT_ID>// C2M Field-
Bill On-holding of in another
MUB/removal of Lifecycle optional/Manually Entered Field
on-holding of process <reasonForTransfer></reasonForTransfer> C2M Field-
MUB: Solution optional/Manually Entered Field
Description, <dataToUpdate><dataToUpdate>// C2M Field-
Section: 5.1.3.6.3. optional/Manually Entered Field
12 Request for CA Module SDD, Triggered <daystoExtend></daystoExtend>// C2M Field-
Billing On-holding of in another optional/Manually Entered Field
Adjustment MUB/removal of Lifecycle <erroneousSIBill></erroneousSIBill> // C2M Field-
(BA) Discount on-holding of process optional/Manually Entered Field
MUB: Solution <noOfInstallment></noOfInstallment> // C2M Field-
Description, optional/Manually Entered Field
Section: 5.1.3.6.3. <installmentAmount></installmentAmount> // C2M Field-
13 Request for CA Module SDD, Triggered optional/Manually Entered Field
Service On-holding of in another
Irregularity MUB/removal of Lifecycle
(SI) Discount on-holding of process
MUB: Solution
Description,
Section: 5.1.3.6.3.
14 Request for CA Module SDD, Triggered
IPA On-holding of in another
MUB: Solution
Description,
Section: 5.1.3.6.3.
15 Payment CA Module SDD, Triggered
Extension in another

On-holding of Lifecycle
MUB/removal of process
on-holding of
MUB: Solution
Description,
Section: 5.1.3.6.3.
16 IPA Extension CA Module SDD, Triggered
MUB: Solution
Description,
Section: 5.1.3.6.3.
17 RCOA – CA Module SDD, Triggered
Desist from On-holding of in another
Disconnection MUB/removal of Lifecycle
MUB: Solution
Description,
Section: 5.1.3.6.3.
18 MUB CA Module SDD, Triggered
Suspension On-holding of Via CXE
MUB/removal of
on-holding of
MUB: Solution
Description,
Section: 5.1.3.6.3.
19 Payment CA Module SDD, Triggered
Reallocation On-holding of in another
MUB: Solution
Description,
Section: 5.1.3.6.3.
20 Credit CA Module SDD, Triggered
Transfer On-holding of in another
MUB: Solution
Description,
Section: 5.1.3.6.3.
21 Credit CA Module SDD, Triggered
Allocation On-holding of in another
MUB: Solution
Description,
Section: 5.1.3.6.3.
Table 9: Concerns List: Handling involves On-holding of MUB/removal of on-holding of MUB process

5.1.1.3.1.3 MUB Generic

❖ This process is responsible for handling the concerns related to MUB (Credit & Collection).
❖ For some concerns holding of the disconnection process is required, and for some concerns
relevant FO Initiation process is required
❖ A step-by step explanation of the lifecycle process which involves this process is mentioned
in the file (CIS_CA_DesignMatrix), which is attached in this document.
❖ The following concerns are related to this process.

Type
1 RCOA – DesistMUB Module SDD, Section: <caseNumber></caseNumber> // Legacy System Field-
from 5.18 Suspension of mandatory
DisconnectionDisconnection Field Order <RequestSource></RequestSource> // Legacy System Field-
mandatory
2 RCOA –MUB Module SDD, Section:
<ConcernType></concernType> // Legacy System Field-
Disconnection5.12 Customer Request for
mandatory
Disconnection <ConcernSubtype></concernSubtype> // Legacy System Field-
3 RCOA – MUB Module SDD, Section: mandatory
Reconnection 5.2 Severance Process <ConcernDescription></ConcernDescription> // Legacy System
Field-mandatory
<MobNo></MobNo> // Legacy System Field-optional
<Email></Email> // Legacy System Field-optional
<CANNO></CANNO> // Legacy System Field-mandatory
<caseOwner></caseOwner> Legacy System Field-mandatory
<responsibleOffice><responsibleOffice>// Legacy System Field-
mandatory
Legacy System Field-mandatory
<SIN></SIN> // Legacy System Field-optional
<BILL_ID></BILL_ID> // C2M Field- mandatory for Billing
Concern
<RefundMode></ RefundMode> // C2M Field-
<amountToAllocate><amountToAllocate>//C2M Field-
<targetAccount></targetAccount>// C2M Field-
<dataToUpdate><dataToUpdate>// C2M Field-
Table 10: Concerns List: Handling involves MUB Related process

5.1.1.3.1.4 Meter Test Fees

❖ To handle the concern for a Meter Test, a life cycle process is required.
❖ This lifecycle process involves generation of the FO and the fees to test a meter if applicable.
❖ An OTC to be created in the system for the Meter Test Fee. Amount of the OTC can be either
fixed or it can be taken in the request input field.
❖ OTCs are dependent on the requirement, hence it will be either fixed or can be taken as
input depending on the requirement.
❖ Details of the process of Meter Test Fees can be checked in the Billing SDD.
❖ Upon creation of interface in Life Cycle in C2M, a Meter Test field shall be available for input
of Meter Test fee amount in C2M. The value is user inputted and the creation of this OTC is
dependent on the amount identified by the user.


Type
1 Request for Billing Module SDD, Section: <caseNumber></caseNumber> // Legacy System Field-
Meter Test 5.7.7 Non-Commodity Billing mandatory
<RequestSource></RequestSource> // Legacy System Field-
mandatory
mandatory
<ConcernSubtype></concernSubtype> // Legacy System Field-
mandatory
Field-mandatory
mandatory
Concern
<meterTestFees></meterTestFees> // C2M Field-
Table 11: Concerns List: Handling involves Meter Test Fee related process
5.1.1.3.1.10 Payment Cancellation/Reallocation

❖ To handle certain concern while in the lifecycle process initiation or handling of the Payment
Cancellation/Reallocation process is required.

❖ Detail of the process of Payment Cancellation/Reallocation can be checked in the Payments

SDD.
❖ The details required to proceed with the payment reallocation concern shall be inputted in
C2M lifecycle.

Type
1 Payment Payments Module SDD, <caseNumber></caseNumber> // Legacy System Field-
Reallocation Section: 5.24. Payment mandatory
Cancellation Workflow, <RequestSource></RequestSource> // Legacy System Field-
Section: 5.25. Payment mandatory
Transfer Workflow
mandatory
mandatory
Field-mandatory
mandatory
Concern
Table 17: Concerns List: Handling involves Payment Cancellation/Reallocation Related process

5.1.1.3.1.11 Handling of SI Complaints/Update of SI Record, Update of SI Bill

❖ To handle certain concern while in the lifecycle process initiation or handling of the Handling
of SI Complaints/Update of SI Record, Update of SI Bill process is required.
❖ Detail of the process of Handling of SI Complaints/Update of SI Record, Update of SI Bill can
be checked in the SI Module SDD.

Type
1 Denial of SI Module SDD, Section: <caseNumber></caseNumber> // Legacy System Field-mandatory
Violation 5.13. Solution <RequestSource></RequestSource> // Legacy System Field-
Description mandatory
<ConcernType></concernType> // Legacy System Field-mandatory
2 Erroneous SI SI Module SDD, Section:
Bill 5.13. Solution Description
mandatory
3 Request for MUB Module SDD, <ConcernDescription></ConcernDescription> // Legacy System
IPA Section: 5.6. IPA Field-mandatory
(INSTALLMENT PAYMENT <MobNo></MobNo> // Legacy System Field-optional
AGREEMENT) <Email></Email> // Legacy System Field-optional
4 Request for SI Module SDD, Section: <CANNO></CANNO> // Legacy System Field-mandatory
Service 5.1.3. Solution <caseOwner></caseOwner> Legacy System Field-mandatory
Irregularity Description <responsibleOffice><responsibleOffice>// Legacy System Field-
(SI) Discount mandatory
<BILL_ID></BILL_ID> // C2M Field- mandatory for Billing Concern
<RefundMode></ RefundMode> // C2M Field- optional/Manually
Entered Field
<targetAccount></targetAccount>// C2M Field- optional/Manually
Entered Field
<PAY_EVENT_ID></PAY_EVENT_ID>// C2M Field- optional/Manually
Entered Field
<dataToUpdate><dataToUpdate>// C2M Field- optional/Manually
Entered Field
<daystoExtend></daystoExtend>// C2M Field- optional/Manually
Entered Field
<erroneousSIBill></erroneousSIBill> // C2M Field- mandatory for:
Erroneous SI Bill/Manually Entered Field
Table 18: Concerns List: Handling involves SI Complaint Related process

5.1.1.3.1.12 Discount
❖ To handle certain concern while in the lifecycle process initiation or handling of the Discount
process is required.
❖ Detail of the process of Discount can be checked in the Billing and SI Module SDD.
❖ Details required to proceed with the creation of the discount shall be inputted in C2M.

Type
1 Request for SI Module SDD, Section: <caseNumber></caseNumber> // Legacy System Field-mandatory
Service 5.1.3. Solution <RequestSource></RequestSource> // Legacy System Field-
Irregularity Description mandatory
(SI) Discount <ConcernType></concernType> // Legacy System Field-mandatory
2 Request for Billing Module SDD,
mandatory
Billing Section: 5.7.8 Billing <ConcernDescription></ConcernDescription> // Legacy System
Adjustment Adjustment Field-mandatory
(BA) <MobNo></MobNo> // Legacy System Field-optional
Discount <Email></Email> // Legacy System Field-optional
mandatory
Entered Field
Entered Field
Entered Field
Entered Field
Table 19: Concerns List: Handling involves Discount Related process

5.1.1.3.1.13 Updating of Bill Due Date

❖ To handle certain concern while in the lifecycle process initiation or handling of the Updating
of Bill Due Date process is required.
❖ Detail of the process of Updating of Bill Due Date, can be checked in the MUB Module SDD.

Type
1 Payment MUB Module SDD, <caseNumber></caseNumber> // Legacy System Field-mandatory
Extension Section: 5.11. Payment <RequestSource></RequestSource> // Legacy System Field-
Due Date Extension mandatory
<ConcernType></concernType> // Legacy System Field-mandatory
mandatory
Field-mandatory
mandatory
Entered Field
Entered Field
Entered Field
<daystoExtend></daystoExtend>// C2M Field- mandatory for:
Payment Extension/Manually Entered Field
Table 20: Concerns List: Handling involves Bill Due Date Related process

5.1.1.3.1.14 CA Related Field Orders

❖ To handle certain concern while in the lifecycle process initiation or handling of the Field
Orders process is required.
❖ Field orders can either be triggered either via directly from CXE or within another C2M
Lifecycle process.
o Concern types that will trigger FO via CXE interface and creation of a CA record
(service task / parent activity). This is for those concern types where only one C2M
action and FO is required to be handled in C2M.
▪ Concern Record Type: Complaint & Feedback; Concern Type: Application for
Electric Service (Inspect Existing Lot/Service FO)
▪ Concern Record Type: Requests; Concern Type: Meter Concerns
• Concern Subtype: Request for Special Meter Reading
• Concern Subtype: RCOA – Special Meter Reading
• Concern Subtype: RCOA – Disconnection
• Concern Subtype: RCOA – Reconnection
o Concern types that will trigger FO within C2M Lifecycle with more than one FO type
or other transactions. This is for these concerns
▪ Concern Record Type: Complaint & Feedback; Concern Type: Billing &
Payments
▪ Concern Record Type: Complaint & Feedback; Concern Type: Meter
Concerns
▪ Concern Record Type: Complaint & Feedback; Concern Type: Service
Irregularity
▪ Concern Record Type: Requests; Concern Type: Meter Concerns
• Concern Subtype: Request for Meter Replacement
• Concern Subtype: Request for Meter Test
❖ Based on the available FO types in the CIS CA Design Matrix, the user can select the FO
which needs to be processed in the concern lifecycle (the child activity).
❖ The user shall be required to input the FO type and subtype and other FO details that needs
to be provided, depending on the type of FOs that can be generated for that concern type.
Only the FO type required for the C2M concern Lifecycle is available for selection.
❖ C2M should not allow the closure of the CA Record if there is any pending FO activity.
❖ Detail of the process of Field Orders, can be checked in the FO Module SDD.
SNo Concern Sub Reference C2M Proposed Input Fields

Type Document
1 High Billing Service Order
Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
2 Low Billing Service Order
Management
Module SDD,
Section: 5.1. Field

Order Generation & <caseNumber></caseNumber> // Legacy System Field-mandatory

Initiation <RequestSource></RequestSource> // Legacy System Field-mandatory
3 Vacant with Service Order <ConcernType></concernType> // Legacy System Field-mandatory
Consumption Management
mandatory
Module SDD,
<ConcernDescription></ConcernDescription> // Legacy System Field-
Section: 5.1. Field mandatory
Order Generation & <MobNo></MobNo> // Legacy System Field-optional
Initiation <Email></Email> // Legacy System Field-optional
4 Disconnected Service Order <CANNO></CANNO> // Legacy System Field-mandatory
with Management <caseOwner></caseOwner> Legacy System Field-mandatory
Consumption Module SDD, <responsibleOffice><responsibleOffice>// Legacy System Field-
Section: 5.1. Field mandatory
Order Generation & <payorLegacyAccountNumber></payorLegacyAccountNumber> Legacy
System Field-mandatory
Initiation
5 Flat Service Order <BILL_ID></BILL_ID> // C2M Field- mandatory for Billing Concern
Streetlight Management <RefundMode></ RefundMode> // C2M Field- optional/Manually
High Billing Module SDD, Entered Field
Section: 5.1. Field <amountToAllocate><amountToAllocate>//C2M Field-
Order Generation & optional/Manually Entered Field
Initiation <targetAccount></targetAccount>// C2M Field- optional/Manually
6 Blurred Meter Service Order Entered Field
Glass Management <PAY_EVENT_ID></PAY_EVENT_ID>// C2M Field- optional/Manually
Entered Field
Module SDD,
Section: 5.1. Field
Order Generation & <dataToUpdate><dataToUpdate>// C2M Field- optional/Manually
Initiation Entered Field
7 Broken Meter Service Order <daystoExtend></daystoExtend>// C2M Field- optional/Manually
Glass Cover Management Entered Field
Module SDD, <erroneousSIBill></erroneousSIBill> // C2M Field- optional/Manually
Section: 5.1. Field Entered Field
Order Generation & <noOfInstallment></noOfInstallment> // C2M Field- optional/Manually
Initiation Entered Field
8 Broken / Service Order
Missing Management
Terminal Seal Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
9 Burnt Meter Service Order
Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
10 Deformed / Service Order
Detached Management
Parts Inside Module SDD,
Meter Section: 5.1. Field
Order Generation &
Initiation
11 Dial Pointers Service Order

Out of Management
Alignment Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
12 Fast / Slow Service Order
Meter Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
13 Interchanged Service Order
Meter Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
14 Meter Service Order
Running Even Management
w/o Load Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
15 Meter with Service Order
Dirt Inside Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
16 Meter with Service Order
No Display Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
17 Stolen Meter Service Order
Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
18 Stopped Service Order
Meter Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
19 Erroneous Service Order
Contract Data Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
20 Denial of Service Order
Violation Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
21 Request for Service Order
Meter Management
Replacement Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
Meter Test Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
Special Meter Management
Reading Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
24 RCOA - Service Order
Special Meter Management
Reading Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
25 RCOA – Service Order
Disconnection Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
26 RCOA – Service Order
Reconnection Management
Module SDD,
Section: 5.1. Field
Order Generation &
Initiation
Table 21: Concerns List: Handling involves FO Related process

5.1.1.3.1.15 Meter Replacement

❖ To handle certain concern while in the lifecycle process initiation or handling of the Meter
Replacement process is required.
❖ Detail of the process of Meter Replacement, can be checked in the Metering Module SDD.
❖ Following concerns are related to this process.
❖ A step-by step explanation of the lifecycle process which involves this process is
mentioned in the file (CIS_CA_DesignMatrix), which is attached in this document.

Type
1 Request for Metering Module <caseNumber></caseNumber> // Legacy System Field-mandatory
Meter SDD, Section: 5.1.1. <RequestSource></RequestSource> // Legacy System Field-mandatory
Replacement Meter, Metering <ConcernType></concernType> // Legacy System Field-mandatory
Point, Consumption <ConcernSubtype></concernSubtype> // Legacy System Field-
mandatory
types and Meter
Replacement mandatory
mandatory
<payorLegacyAccountNumber></payorLegacyAccountNumber> Legacy
Entered Field
Entered Field
Entered Field
Entered Field
Entered Field
<erroneousSIBill></erroneousSIBill> // C2M Field- optional/Manually
Entered Field
<noOfInstallment></noOfInstallment> // C2M Field- optional/Manually
Entered Field
Table 22: Concerns List: Handling involves Meter Replacement Related process

5.1.1.3.2. Handling through Transaction in C2M

In this section processes are listed and explained which involves in the handling of the concern, for
which an initiation of a transaction in C2M is required.
5.1.1.3.2.1 IPA
This process is required to initiate/create the IPA (INSTALLMENT PAYMENT AGREEMENT) process in
C2M. Detail explanation of the process is documented in the MUB SDD. Related concerns are listed
below.
File: CIS_CA_DesignMatrix which is attached in this document can be referred to check the steps
designed for handling of such concerns.

Type
1 Request for MUB(Credit &
IPA Collection) Module
SDD, Section: 5.6. IPA
(INSTALLMENT
PAYMENT
AGREEMENT)

2 IPA Extension MUB(Credit & <caseNumber></caseNumber> // Legacy System Field-mandatory

Collection) Module <RequestSource></RequestSource> // Legacy System Field-mandatory
SDD, Section: 5.6. IPA <ConcernType></concernType> // Legacy System Field-mandatory
(INSTALLMENT <ConcernSubtype></concernSubtype> // Legacy System Field-
mandatory
PAYMENT
AGREEMENT) mandatory
mandatory
Entered Field
Entered Field
Entered Field
Entered Field
Entered Field
Entered Field
<noOfInstallment></noOfInstallment> // C2M Field- Mandatory for:
Request for IPA /Manually Entered Field
<installmentAmount></installmentAmount> // C2M Field- Mandatory
for: Request for IPA / Manually Entered Field
Table 23: Concerns List: Handling involves IPA Related process
5.1.1.3.2.2 Update on Account Details

• This process is required to initiate/create the Update on Account Details process in C2M.
Detailed explanation of the process is documented in the SA Module SDD. Related concerns
are listed below.
• A Lifecycle record will be created once the Update on Account Details transaction is
initiated. The initiation of this Lifecycle record is based on the following concern type:
o Concern Type: Payment Enrollment &Update
o Concern Subtype: Update on Account Details
• The following information transactions shall be done in the Lifecycle record that will be
created in C2M
o Identificaton of Account fields that will be updated
o Updating of Account Fields
• The name of person who updated the records and date of records that were updated will be
recorded in the lifecycle.
SNo Concern Reference Document C2M Proposed Input Fields

Sub Type
1 Update on SA Module SDD, Section <caseNumber></caseNumber> // Legacy System Field-mandatory
Account 6.1.3.1.1, Section 8 <RequestSource></RequestSource> // Legacy System Field-
Details Integration mandatory
Flow,ServiceDetailsUpdates <ConcernType></concernType> // Legacy System Field-mandatory
mandatory
Field-mandatory
mandatory
Entered Field
Entered Field
Entered Field
Entered Field
Table 24: Concerns List: Handling involves Account update Related process

5.1.1.3.2.3 Update on Contract Data

❖ This process is required to initiate/create the Update on Contract Data process in C2M.
❖ There should be a facility to update the records in C2M for those requests which do not have
Service Application case records specific for the requests and Service Agreement records
available in the system.
❖ A CA record will be created once the Update on Contract Data transaction is initiated based
on the following concern type:
o Concern type: Application for Electric Service
o Concern Subtype: Erroneous Contract Data
❖ There will be a mandatory field/characteristic in C2M for the assignment of office.
❖ User will be redirected via hyperlink from the CA record to the Service Application page for
the updates.
❖ User will update the contract data fields of the Service Application record in the page. The
data fields that will be updated are based on the verification and validation done by the
user.
o Service Application record will be updated. There will be audit trail available in the
Service Application record. This can be checked in the SA Module SDD.
o CA record will be updated on the change.
o There will be a sync update from C2M to CXE via payload.


Sub Type
1 Erroneous CA Module SDD, SA <caseNumber></caseNumber> // Legacy System Field-mandatory
Contract module SDD, Section <RequestSource></RequestSource> // Legacy System Field-mandatory
Data 6.1.3.1.3 <ConcernType></concernType> // Legacy System Field-mandatory
mandatory
mandatory
mandatory
Entered Field
Entered Field
Entered Field
<dataToUpdate><dataToUpdate>// C2M Field- mandatory for:
Erroneous Contract Data/Manually Entered Field
Entered Field
Entered Field
<noOfInstallment></noOfInstallment> // C2M Field- optional/Manually
Entered Field
Table 25: Concerns List: Handling involves Miscellaneous process

5.1.1.3.2.7 OR/AR Printing

❖ To handle certain concerns where the printing of OR/AR is required.
❖ Detail of the process of Generation and Printing of OR/AR can be checked in the Payments
SDD.
❖ The expectation is that the OR/AR is already automatically generated for all payments
received and is already generated. For requests for OR/AR, the printing of the OR/AR shall
be initiated.


Type
1 Request Payments Module SDD, Section: <caseNumber></caseNumber> // Legacy System Field-
for 5.11. OR/AR Number Generation, mandatory
Official 5.37 Payment receipt request <RequestSource></RequestSource> // Legacy System Field-
Receipt workflow mandatory
mandatory
<ConcernSubtype></concernSubtype> // Legacy System
Field-mandatory
<ConcernDescription></ConcernDescription> // Legacy
<responsibleOffice><responsibleOffice>// Legacy System
Field-mandatory
<payorLegacyAccountNumber></payorLegacyAccountNumb
er> Legacy System Field-mandatory
Concern
Table 26: Concerns List: Handling involves OR/AR Related process
12

Update external System on the status of the Life-cycle process initiated

in C2M
An Outbound Interface service is required to achieve this functionality.
5.1.1.4.1. Outbound Interface Details

✓ Outbound Interface services are primarily used for data sync purposes.
✓ To access Outbound Service certain configurations are required such as External System,
Message Sender, Outbound Message Type and OutMessage BO in C2M System.
✓ In the case of Outbound Services, C2M will send the request to External System (CXE System).
✓ This request can be sent in Real-time/Through Batch Process.
✓ External Systems for example CXE can be configured in C2M as an entity.
✓ The External System provides the placeholder to configure different outbound services under
Message Sender. It also provides placeholder to configure the URL and the credentials for the
Services.
✓ Input/output Payloads can be configured in Outbound Message Type.
5.1.1.4.2. Service Details: UpdateCase

✓ This Service will be used to send the update on the status of the concern to the CXE System via
MW.
✓ It will be triggered within the lifecycle process initiated in C2M.
✓ Triggering event will be change in status of the lifecycle process.
✓ Payload related information will be covered up with Integration document of the SA Module.
Data Management Mechanism

✓ For the reporting purpose, for all incoming/outgoing request a management of data is required
in C2M.
✓ To achieve this functionality a Service Task Type Entity can be utilized technically.
✓ By using this approach all incoming data will be stored into the system using Service Task Type
Entity tables.
✓ Another way to achieve data management is by storing incoming CANNO, SINNO, CXE Case No
on the case characteristics.
✓ This will help to map the C2M concern ID with CXE system Case No.
On-holding of MUB and Removal of On-holding of MUB
5.1.1.6.1. MUB Process
• The Collection Process (aka MUB in Meralco) is triggered for all accounts automatically by
the Account Debt Monitoring (ADM) batch.
• In the Collection Class Control, the collection conditions are defined.
o The conditions are defined using Collection Condition Priority and Condition
Algorithm
o Based on the screen, Condition Algorithm are validations that will happen to the
Collection Process for the defined Collection Class Control (e.g., Check if severance
process exists for SA in debt class, check if account is on budget, always return true)
while Collection Condition Priority defines the level of priority the validation
algorithm will happen.
o In the Debt Criteria, the MUB process steps are defined for each Condition
Algorithm.
▪ Arrears Priority – priority of the execution of the Collection Process
Template based on minimum Arrears Amount
▪ Collection Process Template – MUB step
▪ Arrears Amount
▪ Days – number of days before MUB process is triggered
• One Debt Class may be defined for each collection process scenario (the example used is
that a collection handling is defined for all Standard Utility Debt Class, but a different
Collection Class Control can be defined for other Debt Classes such as Charity, OTC, Deposit,
Non-bill Budget, etc.). In the example of Standard Utility Debt Class, all Standard Utility Debt
Classes have the same collection rules.
o Under an Account, there may be multiple SA types associated to the Debt Class.
▪ For each SA under the Debt Class, the SA Info, Premise, Total Current
Balance, and breakdown of SA Arrears by days old and amount (the example
SAs provided are gas residential, electric residential and water residential)
o For each Account record, different Debt Classes may be defined.
o Each Debt Class for the Account has Current Balance and Payoff Balance details.
▪ Current Balance – Amount the company is charging the customer
▪ Payoff Balance – Amount required for payment to not initiate collection
process
o Only the delinquent amounts are considered for the collection process
o In the scenario for 1CAN: Many SINs scenario, the different SAs under the Debt Class
may be the different Electric Service Agreements.
o Delinquent amount refers to the amount that fulfills the criteria for Collection/MUB
process in the Collection Class Control and Debt Criteria
o Payments to be made to the account will be distributed based on the priorities
defined for each Debt Class and SA.
o The example Debt Classes for an Account can be as following:
▪ Charitable Contribution – different SA type where payoff balance is zero
because customer is not required to pay
▪ Payment Arrangement – different SA type
▪ Standard Utility Debt – different debt class with multiple SAs
▪ Write-off – handled of balances that the company cannot recover anymore
Customization for Service-Level MUB
• The customization will be if Meralco were to pursue a service-level MUB. Which will be as
follows:
SA Type Details and Payment Priority + Delinquent Pay Priority. To illustrate solution to a SA,
SA has a Payment Priority and Delinquent Pay Priority. These priorities must be defined per
SA and based on those; the payment will be distributed. Delinquent Pay Priority serves as a
sub priority level in case two SAs have the same Payment Priority. If Meralco will go with the
service-level MUB, the priority for each service should be defined.
Collection Process for Bills with Balances Tagged under a Concern Record

• For the scenario when an amount is tagged with concern when MUB is active for an
account.
• MUB Handling for OOTB Solution. For the OOTB solution, the moment MUB is triggered, all
balances of delinquent SAs under the account will be added to represent the Collection
Amount.
o The Collection Amount which is the overall balance the customer needs to pay while
the Amount Still Owing is the amount that should be paid for the Account to come
out of the collection/MUB process.
o Currently, the OOTB does not support SA Level MUB.
• System Configuration to Support SA Level MUB. To support Meralco’s requirement of
suspending MUB for a certain SA when the balance is tagged under a concern, the system
will be designed so that the balance in Amount Still Owing will automatically be transferred
to a Dispute Service Agreement with a different Dispute Debt Class with altered trigger dates
for collection process events.
• Proposed solution is to shift the trigger date for each Collection Event under the Collection
Process to 100 years ahead so they will not be triggered in the near future. This amount
should stay in that particular SA and Debt Class until the concern is resolved or cancelled.
o These actions will be part of the the life cycle in C2M triggered by a concern type.
o To identify the specific amount which must be pushed to a dispute SA, for each
concern, the particular SA ID for which the dispute must be raised so that the
balance may be pushed from the initial SA to the dispute SA. They confirmed that a
specific Bill ID/Bill Segment amount can be identified because every Bill Segment ID
is linked to a SA ID.
o There should be only one Bill Segment ID per case, and this case will have one
process. This is connected to the request to have only one Bill Segment ID per
payload.
o To revert the trigger dates to resume the MUB process. As per proposed solution
there will be a monitor algorithm in the case life cycle in the CA module will keep
watch on the status until it is resolved. Once resolved, the monitor algorithm will
change the trigger date back to the current date. Succeeding events will also be
reverted, following the parameters set for the period between events. If a specific
MUB event period has already started before the concern was raised, once the
concern is resolved, it will consider the buffer/remaining days for the event and
resume from there again.
MUB Handling for Unpaid Balances Tagged for Rebilling/Billing Adjustment
• A different handling will be needed wherein the amount will be manually identified from the
SA and placed in a Dispute SA. In the case of rebilling, if a certain amount will now be
collectible and part of the MUB process again, the balance will have to be manually moved
from the Dispute SA to another SA.
5.1.1.6.2. Flow Diagram for the solution of On-holding of MUB/removal

of on-holding of MUB

Figure 7: Flow Diagram: On-holding/Removal of On-holding of MUB Process
5.1.1.6.3. Solution Description-On-holding/Removal of On-holding of

MUB Process
❖ End user lodge concern to CXE System it re-direct the request to C2M through an
Inbound Webservice.
❖ In C2M Webservice will create a Service Task, initially it will be in Pending status for
customer request for MUB Hold process.
❖ Now there can be 2 scenarios when the process of Holding of MUB and removal of
holding of MUB will gets executed.
1. First Scenario will be when there will be a dedicated request coming for On-
holding of MUB/removal of on-holding of MUB. This will be considered as
request coming directly from CXE. For example, check the concern: MUB
Suspension.
2. Second Scenario will be when On-holding of MUB/removal of on-holding of MUB
a part of lifecycle process of handling other concerns. This will be considered as
request triggered in another Lifecycle process. for example, check the concern:
High Billing, Low Billing, Request for IPA.
❖ If the request is meeting Scenario:1 C2M System checks for Active MUB.
o If Active MUB exists change collection trigger dates to 100+Years - MUB Process.

o If it does not exists create collection process and change Collection trigger dates
to 100 +Years - MUB Process.
❖ If request is meeting Scenario:2 create concern sub type case.
o Process initiated to create concern sub type case.
o If the case lifecycle has steps/status for Hold MUB, then C2M System checks for
Active MUB.
▪ If Active MUB exists change collection trigger dates to 100+Years
- MUB Process.
▪ If it does not exists create collection process and change
Collection trigger dates to 100 +Years - MUB Process.
o Related concern sub type process continued.
o To execute Release of holding of MUB:
▪ Identify customer eligible buffer time from collection process
template and add buffer time to current date and change
collection trigger dates – MUB Process.
❖ Service task will keep waiting for concern closure.
❖ Service task will have a Monitor process configured; it will work as follows:
o If case is not completed-> Waiting for concern closure-> Monitors in
Progress Case-> Related concern sub type process continues.
❖ Once the Case gets completed.
❖ Monitor logic will complete Service Task.
❖ The End.

Flow diagram: Management of Complaints
Receipt and Classification of

Customer Concern
Analyze the complaints and

determine plan of action to handle
the complaint
Investigate the cause of complaint

using available office data
For field investigation Perform field investigation
Office data sufficient
Determine if for correction
Not for correction
For correction
Perform corrections
Resolve complaint
Provision of Feedback to
Customer
Figure 8: Flow diagram: Management of Complaints

Flow diagram: Management of Request

Receipt and Classification of
Customer Concern
Inform the customer on the

requirements of the request
Receive and check the

completeness of the submitted
requirements
Requirements
submitted
Incomplete requirements
Advise the customer to submit all
necessary requirements
Evaluate the validity of the

request & feasibility of executing
the same
Not approved
Approved
Finalize arrangements and settle

charges
Execute the request
Resolve request
Provision of Feedback to
Customer
Figure 9: Flow Diagram: Management of Request

Create Concern in C2M Flow-diagram:
Figure 10: Create Concern in C2M Flow Diagram
Design Components
Configurations and development of the following components are required:
1. Algorithms
2. Algorithm Types
3. Business Objects
4. Case Types
5. Characteristic Type
6. Custom Fields
7. Data Area
8. External System
9. IWS Configuration
10. Lookups
11. Message Sender
12. Outbound message Type
13. Plug-in scripts
14. Service Scripts
15. Service Task Type

Flow Diagram representing Usage of the Design components
Figure 11:Technical Components Usage
In the following section components, which are required to meetup the design of the solution is
explained. Section Component Type has a brief introduction about the component whereas in the
sub-section an example of that type of component is specified.

Component Type (Service Task Type)

Service Task Type is a technical component used for development. This component provides the
placeholder to configure the Service Task BO which is responsible to store all incoming request
related data into the table and to design a lifecycle process for the Handling of the concern. This is
known as transactional BO
Service task types define properties common to specific types of service tasks. Service task types
represent different types of tasks that can be performed by:
5.1.1.11.1. Service Task Type: CA-BILLING

Following is a Service Task Type for reference.
Field Name Value

Description Billing Related Concern Type
BUSINESS OBJECT Testing-Concern Task Type
SERVICE TASK TYPE Active

STATUS
RELATED Cm-CAConcernTaskTypeTransBO
TRANSACTION BO
SERVICE TASK CLASS Customer Assistant Concerns
DETAILED
DESCRIPTION
Configuration Mapping
CONCERN SUB-TYPE CUSTOMER CONTACT CLASS CUSTOMER CONTACT TYPE
GBILL BILL
HBILL BILL HIGHBILL

Table 27: Service Task Type Details

Figure 12: Service Task Type Image

Component Type (Business Object)

Business Object is a technical component used for development. It has a set of tables to interact, an
XML based Schema that work as wrapper in case this component will be used for integration
purpose. It also provided the option to put up a lifecycle process over it. The lifecycle process will be
driven on the set of data which is stored/belong the set of tables on which BO is constructed.
Following are some examples of the Business Objects:
5.1.1.12.1. Business Object: Cm-CAConcernTaskType

Cm-CAConcernTaskType is a Business Object. It is used or the development purpose. Main purpose
of this component is to store all incoming request related data into the table and to design a lifecycle
process for the Handling of the concern.
Field Name Value
Description Testing-Concern Task Type
Long
Description
MAINTENANC F1-STASKTYPE
E OBJECT
APPLICATION F1-STASKTYPE
SERVICE
INSTANCE Allow New Instances

CONTROL
BO Option
Option Type SEQUENC OPTION VALUE DETAILED DESCRIPTION OWNER

E
Portal 10 c1sitaskTabMenu Defines the navigation Customer

Navigation option of the business Modificatio
Option object's portal. n
Related 10 Cm- Defines the business Customer

Transaction CACreateConcernServiceTa object of the related Modificatio
BO sk transaction. This option n
is typically used on a
"type" business object.
Service Task 10 CMCA Defines the service task Customer

Class Modificatio
class of the BO. Valid
n
values are defined on
lookup
F1_SVC_TASK_CL_FLG.
For example, self-
service task type BOs

are assigned class
WXSS. Note that if
instances of this BO are
maintained on the
standard service task
type portal, then the
class is also defined on
lookup
C1_SVC_TASK_CL_UI_F
LG which controls the
values included in the
BO dropdown when
adding a new service
task type on the
standard portal.
Table28: Service Task Type Business Object
5.1.1.12.2. Business Object: Cm-CACreateConcernServiceTask

It is also a Business Object. Different instances of this component belong to its Cm-
CAConcernTaskType Object. It is a technical component used for development purpose.
Field Name Value
Description CA Create Concern service task
Long Description Main Business Object for CA Create Concern service task
MAINTENANCE F1-SVCTASK
OBJECT
APPLICATION CM-CACONCERNTASKBOA
SERVICE
INSTANCE Allow New Instances

CONTROL
BO Option
Option Type SEQUENCE OPTION VALUE DETAILED OWNER

DESCRIPTION
Portal 10 c1sitaskTabMenu Defines the navigation Customer

Navigation option of the business Modification
Option object's portal.

Table 13:Service Task Business Object
Figure 13: Business Object Main Page Image
5.1.1.12.3. Business Object Lifecycle: Cm-CACreateConcernServiceTask

Life Cycle structure of the Business Object, this is the process by which we can control any action
taken at the C2M side for the user concern.
Every Business Object has the placeholder to design a Lifecycle over it. The Lifecycle can be designed
to meetup the Business requirement. To achieve this different lifecycle status has to be designed
and configured into the system over a Business Object.
In the status placeholders are available to plugin Algorithms (technical component used to execute
business logic). Triggering point of these algorithms are event driven. For example, entering into an
status, or exiting a status can be the example of such events. At these events the custom algorithms
will be hit and get executed.
Switching from a status to another status can be handled in both ways I.e.by User or through
System. In create concern scenario it will be handled through System only.
BO: Cm-CACreateConcernServiceTask has a Lifecycle process which is for overall handling of the
concern. In the following section different status are explained in detail.

Figure 14: Business Object Lifecycle
Status Name (PENDING)

This will be the initial status of every Service Task which will be created using this BO, whenever a
request for concern handling will come to the C2M system a service task with the pending status will
be created.
Pending
Status PENDING
Description Pending
Script
Access Mode Pending
Status Condition Initial
Transitory State No
Alert No
Display Sequence 10
Batch Control
Comment
Algorithms
System Event Sequence Algorithm Existing/new
Monitor 10 F1-TRN-DF-NS Existing
Next Statuses
Status Action Label Seq Use as Transition Condition Transition Role
Default
1 Validate 10 Yes OK System
Required Characteristics
Description Required
Table 29: Business Object Status 1 Details

Figure 15: Business Object Lifecycle Status Image
Status Name (VALIDATION)

In this status following validations on the input data will be performed:
a) Check on the mandatory input data
b) Check the authenticity of the input data
c) Check for MUB hold/un-hold request
Apart validations a to-do will be initialized at this status for the responsible office to input the
optional data required for the concern.
A Monitor algorithm will be plugged-in to this status which will keep on checking whether the
optional data which is required for the concern is provided or not.
Validate
Status VALIDATE
Description Validation
Script
Access Mode In-Progress
Status Condition Interim
Transitory State Yes
Alert No
Display Sequence 20
Batch Control
Comment
Algorithms
Enter 10 CM_CAREQVALD New

Next Statuses
Default
1 Process Customer 10 Yes OK System
Contact and Case
2 Error 20 No Exception System
3 HOLD MUB 30 No Approved System & User
Figure 17: Business Object Lifecycle Image
Status Name (HOLD MUB)

When all the validations get passed and all the mandatory input data received Service status will be
transitioned to the HOLD MUB status IF, the Concern coming from CXE is dedicatedly for this
purpose (holding/un-holding the MUB).
An Algorithm is required at this status. This algorithm will perform the following logic:
a) This Algorithm component will check Active C&C(MUB) process is present or not.
b) If present change its Collection Event Trigger Dates to +100 Years.
c) If not present create Collection Process and changes its collection Event Trigger Dates to
+100 years.

Process Customer Contact and Case
Status HOLD MUB

Description HOLD MUB
Script
Alert No
Display Sequence 30
Batch Control
Comment
Next Statuses
Default
1 RELEASEMUB 10 Yes OK System & User
Status Name (PROCESS)

For handling concerns other than holding/un-holding the MUB. Validate status will move to the Next
Status, which is PROCESS. In this status a lifecycle process which is designed and configured in the
system to handle the specific concern will be initialized.

A monitor algorithm will be plugged-in to this status, which will keep on monitoring the closure of
the lifecycle process(case). The moment case gets closed Service Task will be completed and the
same will be informed to the CXE system.
Status PROCESS
Description Create Concern Sub Type Case
Script
Alert No
Display Sequence 40
Batch Control
Comment
Algorithms
Enter 10 CM_SVCSUCESS New
Next Statuses
Default
1 Complete 10 Yes OK System

Status Name (RELEASE MUB)

Service task will be landed in this status, when the time for holding an MUB process gets completed.
In this status plugged in algorithm will perform the following logic:
Identify Customer Eligible Buffer Time from Collection (MUB) Process Template and ADD buffer time
to current date and change Collection trigger dates.
Status RELEASEMUB
Description RELEASE MUB
Script
Alert No
Display Sequence 50
Batch Control
Comment
Next Statuses
Default
1 Complete 10 Yes OK System & User
2 Error 20 No Error System

Status Name (DISCARD)

In this Service task will be landed if any validations failed. Then the request will be
discarded/Rejected.
Complete
Status DISCARD
Description Discarded
Script
Access Mode Complete
Status Condition Final
Transitory State No
Alert No
Display Sequence 80
Batch Control
Comment
Algorithms
Next Statuses
Default
Status Name (COMPLETE)

This is the final status for the case closure.
Complete
Status COMPLETE
Description Complete
Script
Access Mode Complete
Transitory State No
Alert No
Display Sequence 100
Batch Control
Comment
Algorithms
Next Statuses
Default
Status Name (ERROR)

System transitions the lifecycle to this state whenever the processing of the other lifecycle
status goes into error. An example of this update to this is if there will be an error on the
MUB holding. If this happens, a To Do will be created.
Complete
Status ERROR

Description Error
Script
Access Mode Error-CCB
Transitory State No
Alert No
Display Sequence 90
Batch Control
Comment
Algorithms
Next Statuses
Default
Component Type (Service Script)

5.1.1.13.1. Service Script: CM_CACONCERN
Script CM_CACONCERN
Description To receive the IWS for CA Concern
DETAILED
DESCRIPTION
Script Type Service Script
APPLICATION SERVICE F1-DFLTS
Table 37: Service Script Details

Figure 28: Service Script Image
The Step section has the logic to handle the Concern, This section covers the initial scanning of the
input data and deciding the action itmes for the concern.
Figure 29: Service Script Steps Image
Following Schema will be exposed to the CXE system, by putting a wrapper on it, This wrapper will
be called IWS Service, Detailed information of this component can be checked in the following
process where the navigation option is captured to create an IWS Service.

Figure 30: Service Script Schema

IWS Service
Figure 31: IWS Service Configuration Navigation in C2M
Figure 32: IWS Configuration
Following is the Navigation path for the Deployment of the Service, this step will be executed just
after the Add IWS service process is completed.

Figure 33: IWS Deployment Navigation in C2M
Once the deployment is done IWS Service page will look as follows, a LINK for the WSDL of the
service will appear on the page. WSDL will provide the interface to access the Business Process
behind the IWS Service.
Figure 34: IWS Service with WSDL Link

Component Type (External System)

External System is a technical component, primarily used for the configuration of any System
information, to which the C2M System wants to communicate. Check the following flow to
understand the role of this component
Invoke OutMessageType BO -> It will find the External System and the Message Sender->Message
Sender->hit the Outbound Service
5.1.1.15.1. External System: CM-EAM
Figure 35: External System
Outbound Message Type
Figure 36: Outbound Message Type
5.1.1.16.1. Outbound Message Business Object

Outbound Message BO is a technical component, primarily used for Outbound Interfaces. Check the
following flow to understand the role of this component
Figure 37: Outbound Message Business Object
5.1.1.16.2. BO Schema
Figure 38: Outbound Message Business Object Schema
Message Sender
Message Sender is a technical component used for the configuration of the Outbound Service-
related information.
This includes many parameters like the URL of the outbound service, credentials to access the
service, timeout parameters etc.
Check the following flow to understand the functionality of the component:
Figure 39: Message Sender for External System

5.1.1.17.1. Message Sender Configuration
Figure 40: Message Sender configuration for External System

High-Level Test Acceptance Criteria

Note: The table below only outlines the high-level list of test scenarios. Detailed test cases
should be written based on these scenarios and this must not limit the developer in exhausting
all possible test combinations to completely unit test this gap.
Business Scenario Expected Results
Scenario1: Setting the value of the input field which

Received Output payload populated with
exists in the system and then hitting the Outbound
the expected data
Service
Scenario2: Setting the value of the input field which Only the Status and Description fields are
does not exist in the system and then hitting the populated with data. Description field has
Outbound Service the detail of the failed scenario.
Scenario3: Getting the value of the input field with a Output data can be varied/exist/not exist
different date range if the startDate and endDate based on the date range.
fields exist in the payload via incoming Inbound
Service Request.
Scenario4: Different sets of Concern Type and Sub – Output payload fields can be varied based
Type for the Create Concern Interface on the inputs.
Scenario5: Getting a request for Bill related Concerns The bill-related process triggered,
updated data will send back in the same
session or later by another interface.
Scenario6: Mandatory fields missing in the payload Description message for the missing field
in the payload.
Scenario7: Getting the input fields in different sets Input fields can refer to entities in
different states hence output payloads
may have different combinations.
Scenario8: Case Status progression After case initiation case lifecycle process
will progress to next expected status, and
the status information will be synced with
CXE System.
Scenario9: Business Object Status progression Using Business Object lifecycle handling
of the concern will be processed. After
initiation of the BO lifecycle, it is
expected that lifecycle will progress to
next expected status. Switch to next
status depends on the algorithm logic
plugged-in to the status.
Scenario10: Case Resolved/Cancelled Status update UpdateCaseStatus interface must send
with CXE the update for case close or cancelled to
CXE System.
Table 38: High Level test Scenario

6. Generic Configurations
Following are the various configuration we must keep in C2M to run the CA Business Process.
The information below will only contain the C2M Master Data Configuration for the business process
covered in this document. Complete C2M Master Data Configuration, including Organization
Elements and Master Data Structures, will be documented in the C2M Configuration Workbook.
6.1. Case Type

Relationship Type Description
Case Types Life Cycle process in C2M. This process can be configured as an entity and
lifecycle processes can be designed on it.
Table 39: Case Type details
Figure 41: Case Type Configuration
Figure 42: Case Type Lifecycle

Figure 43: Case Type Lifecycle step details1
Figure 44: Case Type Lifecycle step details2
6.2. Characteristic Type

Characteristic Type Characteristic type entities are used to capture additional information for
an entity.
Every entity has a separate tab to configure the characteristic Types.
Following are the screenshots of some characteristics configured on Case

Type.
Table 40: Characteristic Type

Figure 45: Characteristic Type Configuration

6.3. IWS Configuration

IWS Configuration Inbound Web Services are configured in the system over Schema-based
components like Service Scripts, Business Services, and Business Objects.
IWS is configured to provide the wrapper over these components for
integration purposes. This Configuration provides a WSDL to share with an
external system.

6.4. Data Area

Data Area This component is used to configure the standard set of fields to be induced
in the Schema based component to configure their schema.
Table 41: Data Area Details
Figure 46: Data Area Configuration
Figure 47: Data Area Schema Configuration

6.5. Custom Fields

Custom Fields While designing the schema of a component if the field level information is
not available in the system then new fields have to be configured in the
C2M system. These fields are known as custom fields. Field name initials will
be CM. This makes the identification of such fields easy.
Table 42: Custom fields Details
Figure 48: Custom field Configuration
6.6. Service Task Type

Service Task Type This Configuration is required to design a lifecycle process on a set of data.
This data usually comes from external systems.
Table 43: Service task Type Details
Figure 49: Service Task Type

Figure 50: Service Task Type Configuration
6.7. Business Objects

Business Object This component is schema-based. It provides the lifecycle process on a set
of data. This data belongs to the set of predefined tables. A set of
predefined tables can be configured under the Maintenance Object entity
configuration.
Table 44: Business Object
Figure 51: Business Object Configuration

Figure 52: Business Object Schema Configuration
Figure 53: Business Object Lifecycle Steps Configuration
Figure 54: Business Object Lifecycle step details1

Figure 55: Business Object Lifecycle step details2
6.8. Service Scripts

Service Scripts This component is schema-based. Using this component we can write the
Business Process Logic.
Table 45: Service Script
Figure 56: Service Script Configuration
Figure 57: Service Script Steps Configuration

Figure 58: Script Steps Details
Figure 59: Service Script Data Area Configuration

Figure 60: Service Script Schema Configuration
6.9. Algorithm Types

Algorithm Type Algorithm types and algorithms are the components that are used to
execute a custom logic at predefined process spots in C2M. Like Case Type
Enter Processing/Validations/Exit Processing or Customer Class pre
Billing/post Billing/Payment Freeze Spots. A Custom logic first has to be
developed and then it will be plugged into the spot for which it is
developed.
While the configuration of the Algorithm Type we can define parameters.

These parameters will work as an input just generalize the plugged-in
developed logic.
Table 46: Algorithm Type

Figure 61: Algorithm Type Configuration

6.10. Algorithms
Algorithm Type Algorithms are the objects created for Algorithm Type. By Using Algorithm
Type we define a structure by selecting a spot and plug-in the developed
logic.
Using Algorithms we create the instance of an Algorithm Type and attach it

to the real-time process.
Table 47: Algorithm
Figure 62: Algorithm Configuration
Figure 63: Algorithm Configuration in Case Type Lifecycle

6.11. Plug-in scripts

Plug-in Script This component is used to write the business logic. This component is part
of the development process. The entire process can be coded in the step
section.
There are certain parameters available to move in move-out-the-spot-

related data. These parameters are known as Hard parameters. These are
limited and we cannot add more to them.
Table 48: Plug-in Scripts:
Figure 64: Plug-in Script Configuration
Figure 65: Plug-in Script Steps Configuration

6.12. Feature Configurations

Feature This component is used to configure multiple related values for a Key. This
Configuration key will be termed as Feature Name and using this we can get all these
values.
Table 49: Feature Configuration
Figure 66: Feature Configuration
6.13. Extendable Lookups

Extendable Lookup This component is used to configure multiple related values for an entity.
Just like feature configuration, there will be a key to which a set of values
are configured
Table 50: Extendable Lookup

Figure 67: Extendable Lookup Configuration
6.14. External System

External System This component is used to configure any external system as an entity in
C2M. This component provides the placeholder to configure the URL to
access the External system as well as the credentials and other settings
options available. Login password will be aligned with MERALCO’s password
standard.
This component is used for Outbound Interfaces.

Table 51: External System
Figure 68: External System Configuration

Figure 69: Outbound Message Type Configuration
Figure 70: Message Sender

Figure 71: Message Sender Configuration

7. Integration Flow
This section has the details of the Integration processes involved in entire Customer Assistance
process.
Type Source Target

(Real- system System
Process Name Sub-Process Description Frequency
Time/File
Based)
GetServiceStatusAndRfo Check SIN status The service Real- CTI C2M

interface will
and Check Time
check if the SIN
Reconnection FO provided by CTI
through the
"Outages and
Incidents >
Disconnected
Service" option is
connected to a
Disconnected
service in
CMSv10. This
service will also
check for active
Reconnection FO
ValidateSIN Check SIN This service Real- CTI C2M

interface will
existence in the Time
validate the SIN
system provided either
through
"Outages and
Payments" or
"Billing and
Payments"
options from the
CTI call flow. The
expected result
will depend on
what option the
user came from
to validate the
SIN provided
CreateConcern Create concern A RESTFUL Real- CXE C2M

request coming
lifecycle Process Time
from CXE to C2M
via MW.
This service will

CIS_CA_DesignMatr
be used by CXE
ix.xlsx
System to trigger
the C2M
dependent
actions/processes

Type Source Target

Time/File
Based)
for handling the
concern.
Receipt of Remaining This service will Inbound service Real- R&C C2M
to create
Balance of Deactivated sync up the Time
negative/positive
Prepaid Services, remaining adjustment at
Interface Name: balance in C2M Side.
receiveRamainingBalance between R&C
This will be a sync
and C2M system up request.
for pre-paid
Triggering of the
Services service will be
done by R&C
system.
Based on the
amount it will be
decided whether
the amount to be
released to the
customer or will
it be demanded
from the
customer.
If the amount will

be positive, it will
treat as refund of
that much of
amount to be
made to the
customer and if
the amount value
is negative then it
will be taken as
the demand to
be made to the
customer.
ValidateCAN To validate CAN This service will Real- CTI C2M

check CAN exist
in the System Time
in the System, If it
exist then this
service will return
the following
values:
SIN, Service Start

Date, Description,
Return Code,
isPres, isValidSIN,

Type Source Target

Time/File
Based)
SegmentCode,
SegmentName
UpdateCaseStatus concern status Outbound service Real- C2M CXE

for the status
update Time
update to CXE
System
Table 52: Integration Flow
8. Gap Analysis
This section explains the details of the gaps (customizations required in the C2M) identified
to implement the business requirements which are not part of the out of box C2M
functionality to the module detailed in this document.
Sno. BRID GAP ID Requirement Description GAP Solution
1 CA-1 CA-GAP-1 Receipt and Classification In C2M No such Handling of this

of Customer Concern module/process available requirement will be
to handle Receipt and completely
Classification of Customer customized hence
Concern designing of a custom
process is required.
Design Components
can be checked in the
Section: 5.1.4
Table 53: Gap Analysis

9. Cross Reference Business Documents

SL Business Requirement
Cross Business Process Document (SDD Name)
No# Descriptions
1 High Billing Billing Module SDD, Billing Adjustment, Section: 5.7.8.1
CA Module SDD,
On-holding of MUB/removal of on-holding of MUB:
Solution Description, Section: 5.1.3.6.3.
Service Order Management Module SDD, Section: 5.1. Field

Order Generation & Initiation
Integration Document:
OUC2M_Integration_Specification_DCA_CreateConcern-
v0.03
2 Low Billing Billing Module SDD, Billing Adjustment, Section: 5.7.8.1
CA Module SDD,

v0.03
3 Disconnected with Billing Module SDD, Billing Adjustment, Section: 5.7.8.1
Consumption
CA Module SDD,

v0.03
4 Vacant with Consumption Billing Module SDD, Billing Adjustment, Section: 5.7.8.1
CA Module SDD,


v0.03
5 Erroneous BA Bill Billing Module SDD, Billing Adjustment, Section: 5.7.8.1
CA Module SDD,
v0.03
6 Flat Streetlight High Billing Billing Module SDD, Billing Adjustment, Section: 5.7.8.1
CA Module SDD,

v0.03
7 Blurred Meter Glass Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
8 Broken Meter Glass Cover Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
9 Broken / Missing Terminal Seal Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
10 Burnt Meter Billing Module SDD, Billing Adjustment, Section: 5.7.8.1


v0.03
11 Deformed / Detached Parts Billing Module SDD, Billing Adjustment, Section: 5.7.8.1
Inside Meter
v0.03
12 Dial Pointers Out of Alignment Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
13 Fast / Slow Meter Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
14 Interchanged Meter Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
15 Meter Running Even w/o Load Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
16 Meter with Dirt Inside Billing Module SDD, Billing Adjustment, Section: 5.7.8.1


v0.03
17 Meter with No Display Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
18 Stopped Meter Billing Module SDD, Billing Adjustment, Section: 5.7.8.1

v0.03
19 Undelivered Bill CA Module SDD,
Billing Module SDD, Section: 5.7.5. Bill Printing
v0.03
20 Erroneous Payment Posting CA Module SDD,
Payments Module SDD: Section: 5.24. Payment Cancellation

Workflow, Section: 5.25. Payment Transfer Workflow
v0.03
21 Unposted Payment CA Module SDD,
Payments Module SDD: Section: 5.25. Payment Transfer

Workflow
v0.03
22 Denial of Violation CA Module SDD,
SI Module SDD, Section: 5.13. Solution Description

v0.03
23 Erroneous SI Bill CA Module SDD,
v0.03
24 Request for Billing Adjustment CA Module SDD,
(BA) Discount On-holding of MUB/removal of on-holding of MUB:
Billing Module SDD, Section: 5.7.8 Billing Adjustment
v0.03
25 Request for Service Irregularity CA Module SDD,
(SI) Discount On-holding of MUB/removal of on-holding of MUB:
v0.03
26 Request for IPA CA Module SDD,
MUB(Credit & Collection) Module SDD, Section: 5.6. IPA

(INSTALLMENT PAYMENT AGREEMENT)
v0.03
27 Payment Extension CA Module SDD,
MUB Module SDD, Section: 5.11. Payment Due Date

Extension
v0.03
28 IPA Extension CA Module SDD,
MUB(Credit & Collection) Module SDD, Section: 5.6. IPA

(INSTALLMENT PAYMENT AGREEMENT)
v0.03
29 MUB Suspension CA Module SDD,
v0.03
30 Payment Reallocation CA Module SDD,
Payments Module SDD, Section: 5.24. Payment Cancellation

Workflow, Section: 5.25. Payment Transfer Workflow
v0.03
31 Credit Transfer CA Module SDD,
Payments Module SDD, Section: 5.16. Credit Transfer

Workflow
v0.03
32 Credit Allocation CA Module SDD,

Payments Module SDD: Section: 5.16. Credit Transfer

Workflow
v0.03
33 RCOA – Desist from MUB Module SDD, Section: 5.18 Suspension of
Disconnection Disconnection Field Order

CA Module SDD,
v0.03
34 RCOA – Disconnection MUB Module SDD, Section: 5.12 Customer Request for
Disconnection

35 RCOA – Reconnection MUB Module SDD, Section: 5.2 Severance Process

36 Request for Meter Test Billing Module SDD, Section: 5.7.7 Non-Commodity Billing

v0.03
37 Request for Assistance in Billing Module SDD, Section: 5.7.7 Non-Commodity Billing
Maintenance of Customer
Facilities Integration Document:
v0.03
38 Testing Billing Module SDD, Section: 5.7.7 Non-Commodity Billing
v0.03
39 Miscellaneous Billing Module SDD, Section: 5.7.7 Non-Commodity Billing
v0.03

40 Others (Service Application) – Billing Module SDD, Section: 5.7.7 Non-Commodity Billing
Request for Equipment Rental
v0.03
41 Others (Service Application) – Billing Module SDD, Section: 5.7.7 Non-Commodity Billing
Request for Mechanical /
Chemical Testing Integration Document:
v0.03
42 Request for Escort Services Billing Module SDD, Section: 5.7.7 Non-Commodity Billing
v0.03
43 Request for Cleaning of Billing Module SDD, Section: 5.7.7 Non-Commodity Billing
Transformer Vault
v0.03
44 Stolen Meter Billing Module SDD, Section: 5.7.7 Non-Commodity Billing
v0.03
45 Request for Official Receipt Payments Module SDD, Section: 5.11. OR/AR Number
Generation, 5.37 Payment receipt request workflow
v0.03
46 Bill Deposit Refund (Contract Payments Module SDD,
Terminated) Section: 5.13. Cash Refund,
Section: 5.14. Check Refund,
Section: 5.15. Refund Through Fund Transfer, Section: 5.20.
Early Refund of Bill Deposit
v0.03
47 Bill Deposit Refund (Good Payments Module SDD,
Credit Standing) Section: 5.13. Cash Refund,
v0.03
48 Refund of Credit (Account) Payments Module SDD,
Section: 5.13. Cash Refund,

v0.03
49 Refund of Meter Deposit Payments Module SDD,
Section: 5.13. Cash Refund,
v0.03
50 Lifting of Check Blacklist Payments Module SDD, Section: 5.21. Check Blacklist
Removal Workflow
v0.03
51 Lifting of APA Blacklist Payments Module SDD, Section: 5.10. APA Blacklist
Removal Workflow
v0.03
52 Erroneous Contract Data CA Module SDD
SA module SDD, Section 6.1.3.1.3

v0.03
53 Request for Meter Service Order Management Module SDD, Section: 5.1. Field
Replacement Order Generation & Initiation
Metering Module SDD, Section: 5.1.1. Meter, Metering

Point, Consumption types and Meter Replacement
v0.03
54 Request for Special Meter Service Order Management Module SDD, Section: 5.1. Field
Reading Order Generation & Initiation

v0.03
55 Update on Account Details SA Module SDD, Section 6.1.3.1.1, Section 8 Integration
Flow,ServiceDetailsUpdates
v0.03
56 Bill Duplicate Request Billing Module SDD, Section: 5.7.5. Bill Printing
v0.03
57 Erroneous AWA Tagging Payment Module SDD, Section: 5.30. AWA Tagging
v0.03
58 RCOA - Special Meter Reading Service Order Management Module SDD, Section: 5.1. Field
v0.03
Table 54: Cross Reference Business Documents
Note: In addition to the above table, all security and other technical requirements are to be referred to the CIS Scope of Work
(SOW)'s technical key specification requirements.
10. Open/Closed Points
Status
BR ID Description Pending With Comments
(Open/Closed)
Table 14: Open/Closed Points
11. Reporting Consideration

All the required reports corresponding to the CA module will be handled in the ORD reports design
document.
12. Data Migration Consideration

The data migration of the Customer Assistance related transaction data will be covered in the
migration architecture document. Please note that C2M will not have Completed, Pending,
Cancelled and In-Process CA transactions migrated in from the legacy system.
13. Audit Consideration

NA

14. Review Comments

MERALCO Status (Open/Closed) Action/Changes
BR ID Description TechM Response
Comments
Table 55: Review Comments
15. Sign Off
TECH MAHINDRA
S.No Person Name Designation Department Signature Date
1 Sandeep Singh C2M Solution CDU Oracle 07-Oct-2022

Architect
MERALCO
Technology
Customer Services
1 Nathaniel I. Que TechLead Oct 07, 2022
Platforms
Josemarie Anthony Customer

2 TechLead Oct 07, 2022
C. Cinco Touchpoint Solutions
Lorence M. Del Integrations

3 Solutions Engineering Oct 7, 2022
Rosario SPOC
Louie Angelo M. CyberSecurity Infrastructure &

4
Jalandoni SPOC Application Security Oct. 10, 2022
Cherry Josephine N. Meralco Customer Services

5
Manansala Platforms Platforms Oct. 7, 2022
Technology
6 Julie K. Garcia IT Platforms Delivery
Lead Oct 10,2022
Business Process & Requirements
Roxanne Angelica Business Analyst

7 Process & Standards Oct 11, 2022
Marie R. Acevedo Lead

Maria Cathlyn Process Excellence

8 Module PM
Challie G. Lansang Assurance Oct 11, 2022
Justine Anthony R. Workstream Co-

9 Process & Standards 10/11/2022
Abila Lead
Ruth Irina C.
10 Workstream PM Process & Standards
Francisco Oct. 11, 2022
Workstream
11 Cheryl M. Barretto Process & Standards
Lead Oct 12, 2022
Project Management
Nico Seassar C. CRS Project

12 Project Manager
Hernandez Management Oct 12, 2022
Customer Process
Mary Lourdes
13 Project Sponsor and Revenue Oct. 12, 2022
Margaret Y. Ramos
Assurance
Table 56: Sign Off
Tech Mahindra Limited: Manila Electric Company (Meralco):

Signature: Signature:
Name*: NIMISH HARSHADRAI GANDHI Name*: Nico Seassar C. Hernandez
Title: Project Manager / C2M Overall Lead Title: CIS Overall Project Manager
Date: 07-Oct-2022 Date: 10/12/2022
By executing this, Nimish Harshadrai Gandhi the signatory, Nico Seassar C. Hernandez the signatory,
By executing this, _____________________
warrants that the signatory is duly authorized to execute this warrants that the signatory is duly authorized to execute this
(state the complete document name & version) on behalf of (state the complete document name & version) on behalf of
TechM. Meralco.

C2M CA Design Document v1.0

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

C2M CA Design Document v1.0

Uploaded by

Copyright:

Available Formats

C2M Solution Design Document

Version Date of Change Change Description Owner

v0.01 25-May-2022 Initial Version Nitin Sharma

v0.02 1-June-2022 Changes incorporated as Nitin Sharma

v0.03 06-July-2022 Changes incorporated as Nitin Sharma

Submitting for review iteration 1

V0.04 21-July-2022 Changes incorporated as Nitin Sharma

Submitting for review iteration 2

V0.05 1-August-2022 Changes incorporated as Nitin Sharma

Submitting for review iteration 3

V0.06 13-September- Logic incorporated for MUB Nitin

Included additional fields to the

Submitting for review iteration 4

Customer Assistance Design Document Page 2 of 109

Customer Assistance Design Document Page 3 of 109

9. Cross Reference Business Documents .......................................................................................... 98

Customer Assistance Design Document Page 4 of 109

CA-1: Receipt and Classification of Customer Concern

Classification of Customer Concern

Inquiry Billing & Payments Inquiry on Payment Channel

Customer Assistance Design Document Page 6 of 109

CASE RECORD CONCERN TYPE CONCERN SUB-TYPE

Customer Assistance Design Document Page 7 of 109

Request Other Support Services Others (Service Application) – Request for

COMPLAINT Meter Concerns Broken / Missing Terminal Seal

COMPLAINT Products, Programs and Service RADIUS - Availment of Services

Action needs to perform in C2M

Customer Assistance Design Document Page 10 of 109

Table 4: Interface List

Provision of Feedback to Customer Regarding Customer Concerns

• Feedback shall be provided on all customer-initiated customer service-related concerns.

Note: Feedback letter generated in CXE for the customer.

Close Concern Record

C2M Customer to Meter

CXE Customer Experience Engine

Customer Assistance Design Document Page 12 of 109

IWS Inbound Web Service

MDM Meter Data Management

MUB Management of Unpaid Bill

OTC One Time Charges

RFO Reconnection Field Order

STMS Stop Theft Monitoring System

1 Bill cycle Billing interval of an account

2 Bill Segment Account Services Segments on a Bill

Customer class in C2M is used for the classification of the

A lifecycle-based component in C2M. It is used for

5 Case Life cycle process in C2M

A configurable component, used in C2M to configure a

A new row/value configured under the lookup

In C2M terminology it is the medium by which

Inbound web services are the configurable component in

Customer Assistance Design Document Page 13 of 109

SNO Feature Name Description

be exposed to the external system for Integration

Lookup is a configurable component in C2M which is used

Option Types are the Allowable Types of the values, these

The interfaces for which the target system is C2M are

A configurable component, which is known as Case Type

5.1. Receipt and Classification of Customer Concern

CA-1 Receipt and Classification of Customer Concern.

Table 7:Business Requirement Mapping

Customer Assistance Design Document Page 14 of 109

Functional Process Flow

Figure 1: Functional Process Flow