Events
Overview
From the Events tab, a user can access the following functions:
Events Overview
Contextual Search and Filtering
Events Details
Events Overview
Upon load, the events tab contains a table of active exceptions, warnings and informational notifications. The table gives an overview of information about the event including the creation date, event type, event code, etc.
From this view a user can choose to view details on a specific event, or can choose to navigate to the root Contract ID to view more information about the account associated to the event. Depending on your permissions, a user can also assign and resolve issues from this view.
First, select the event you want to change using the check mark
Second, from the action menu, choose one of the following options
Mark resolved
Change status
Assign events
To Mark resolved, select a resolution type from the dropdown, add an optional comment, and apply
To Change status, select either created or pending from the dropdown, and apply
To Assign event, select the user email you’d like to assign the event to from the dropdown and apply
Additionally, a user can select multiple events, and use the “mass updates” option to assign, resolve and reject multiple events at once. In the mass updates pop-up, there is filtering available to select which event codes, categories or statuses should be impacted at once.
The last options from actions menu allow a user to select and download events, which will download the rows selected to a csv for further analysis / reporting. There’s also the option to add a new event if there’s a manual intervention or work that should be tracked along with the exceptions, warnings, etc.
Contextual Search and Filtering
The search bar allows a user to filter on specific event types. After selecting the search bar, a user will see a list of items to choose from in the drop down menu (like prebilling exception) to filter down the list of events. The user can also filter events by date.
Events Details
Choosing the option to view details on a specific event will take a user to the events detail page. This page provides detailed information about the event that can be used to quickly review and resolve the issue. There are two tables on the events page, one give a breakdown of all details about the particular bill or account that created the event (like their contract ID, meter ID, bill start & end date, etc). The other table gives all information about the exception, warning or informational notification (like event ID, category, level, status and message).
There are other tabs on the events details page which enables a user to do the following:
Resolve: allows a user to select a handler to either modify attributes or customer data to resolve the issue and allow the account to bill, or resolve, reject or cancel / rebill the exception. For more information on handlers, please see the section below.
Event Log: a record of changes made to that event, including which user made specific actions. acts as an audit log of all activity related to an exception.
Related Events: if there are multiple events associated with a single account or bill, the related events tab will link those other events so that a user can work through them sequentially to clean up the account
Comments: gives a user the ability to leave an informational note on the event as they’re working through resolution
Event Handlers
Event Handler is the feature that allows the user to “handle” an Event (Exception/Warning) and resolve it based on the designed handler. There could be generic or specific handlers to resolve certain Event Types. All Event Handlers by nature should assist the user in fixing and resolving any Exceptions and/or Warnings.
The following handlers can be applied to resolve a billing exception:
Mark an event as resolved without using a handler
Modify/Add an attribute (Attribute Handler)
Modify/Add customer data (Customer Data Handler)
Modify the usage of account (Usage Handler)
Trigger internal Cancel/Rebill (Cancel/Rebill Handler)
Mark a bill request as Rejected (Reject Request Handler)
Resolve events generated by the Invoice Report (Invoice Response Handler)
After the event handler has been applied, the status of the event will change to “resolved”. And the account will be queued to bill during the next batch.
Attribute Modifier Handler
The Attribute Modifer Handler will allow the user to update or modify any attribute defined as a part of the implementation between GridX and client. Modifying an attribute changes the record (temporarly) in the GridX database to quickly unblock issues that cause billing to fail. However the utility customer systems are the true source of record, and the value must also be changed in those source systems in the long term, because GridX relies on a data sync from the utility systems for billing.
Any changes applied to the customer data using the Customer Data Handler will reflect in the customer table. A deactivate button will be provided in this handler to deactivate a selected customer.
Exceptions
An event with level exception and status “created” can be managed by “Modify Attribute” handler. Upon applying the handler (either edit existing attribute(s) or add new attribute(s)), the status of the event will change to “resolved” and the request will be picked up by the next scheduled billing run and reprocessed
If reprocessing succeeds, the bill will be generated and invoiced to the client in the Bill Response File, no Manual status update will be required. If reprocessing fails and the same exception code is generated, a new event is generated with the “created” status. This would NOT result in duplicate events since the original exception is already in resolved status
If reprocessing fails and a new exception code is generated, a new event is generated with the “created” status
Warnings
An event with level warning and status “created” needs to first be cancelled internally, managed by “Modify Attribute” handler and then rebilled on the modified attributes. The bill request for the original warning will get cancelled and a new rebill bill request will be generated.
The Modify Attribute handler (either edit existing attribute(s) or add new attribute(s)) will be applied to be effective on the new bill request created. Upon applying the handler, the status of the event will change to “resolved” and the request will be picked up by the next scheduled billing run. If the reprocessing succeeds, a rebill will be generated and invoiced to the client in the Bill Response Fil, no Manual status update will be required.
If reprocessing fails and the same exception code is generated, a new event is generated with the “created” status. This would NOT result in duplicate events since the original exception is resolved. The rebill bill is generated but is held at invoicing.
If reprocessing fails and a new exception code is generated (exception or warning), a new event is generated with the “created” status
Customer Data Handler
The Customer Data Handler will allow the user to update or modify the customer data such as entity_id, person_id, servicepoint_id, premise_id, active_flag, customer start and customer end date.
Any changes applied to the customer data using the Customer Data Handler will reflect in the customer table. A deactivate button will be provided in this handler to deactivate a selected customer.
Exceptions
An event with level exception and status “created” can be managed by “Modify Customer Data” handler. Upon applying the handler, the status of the event will change to “resolved” and the request will be picked up by the next scheduled billing run and reprocessed.
If reprocessing succeeds, the bill will be generated and invoiced to the client in the Bill Response File, no Manual status update will be required. If reprocessing fails and the same exception code is generated, a new event is generated with the “created” status. This would NOT result in duplicate events since the original exception is already in resolved status
If reprocessing fails and a new exception code is generated, a new event is generated with the “created” status
Warning
An event with level warning and status “created” needs to first be cancelled internally, managed by “Modify Customer Data” handler and then rebilled on the modified customer data. The bill request for the original warning will get cancelled and a new rebill bill request will be generated. The Modify Customer Data handler will be applied to be effective on the new bill request created
Upon applying the handler, the status of the event will change to “resolved” and the request will be picked up by the next scheduled billing run. If the reprocessing succeeds, a rebill will be generated and invoiced to the client in the Bill Response File, no Manual status update will be required.
If reprocessing fails and the same exception code is generated, a new event is generated with the “created” status. This would NOT result in duplicate events since the original exception is resolved. The rebill bill is generated but is held at invoicing
If reprocessing fails and a new exception code is generated (exception or warning), a new event is generated with the “created” status
Usage Modifier Handler
Exception:
An event with level exception and status “created” can be managed by “Modify Usage” handler. Upon applying the handler (by adding or removing kWh from TOU buckets), the status of the event will change to “resolved” and the request will be picked up by the next scheduled billing run and reprocessed.
If reprocessing succeeds, the bill will be generated and invoiced to the client in the Bill Response File, no Manual status update will be required. If reprocessing fails and the same exception code is generated, a new event is generated with the “created” status.This would NOT result in duplicate events since the original exception is already in resolved status.
If reprocessing fails and a new exception code is generated, a new event is generated with the “created” status
Warning:
An event with level warning and status “created” needs to first be cancelled internally, managed by “Modify Usage” handler and then rebilled on the modified usage data. The bill request for the original warning will get cancelled and a new rebill bill request will be generated.
The Modify Usage handler will be applied to be effective on the new bill request created. Upon applying the handler, the status of the event will change to “resolved” and the request will be picked up by the next scheduled billing run. If the reprocessing succeeds, a rebill will be generated and invoiced to the client in the Bill Response File, no Manual status update will be required.
If reprocessing fails and the same exception code is generated, a new event is generated with the “created” status. This would NOT result in duplicate events since the original exception is resolved. The rebill bill is generated but is held at invoicing.
If reprocessing fails and a new exception code is generated (exception or warning), a new event is generated with the “created” status
Cancel/Rebill Handler
The Cancel/Rebill handler supports the cancelOnly part and generates a new internal billing request for the rebill. If usage needs to be modified, the user will need to call 3 different handlers to finish the job:
cancel/rebill to cancel the bill (probably held at invoicing stage) and prepare the new billing request;
usage modifier
rebill
Scenario 1: Cancel
An event with level warning and status “created” can be cancelled internally without rebill by using the Cancel/Rebill handler
The associated bill request will be cancelled and the status of the event will change to “resolved”
Scenario 2: Cancel,Rebill
An event with level warning and status “created” can be cancelled internally and rebilled without any modifications to the rebill request by using the Cancel/Rebill handler
The associated bill request will be cancelled and rebilled with the next billing run and the status of the original event will change to “resolved”
Scenario 3: Cancel, Modify & Rebill
An event with level warning and status “created” can be internally cancelled, modified by using other handlers and then rebilled based on the the modification by using the Cancel/Rebill handler
The associated bill request will be cancelled and an internal rebill request will be generated for the user to apply any other handler(s)
Once the user applies the handlers and clicks “Rebill”, the rebill will be generated in the next billing run and the status of the event will change to “resolved”
If rebill succeeds, a rebill is generated and invoiced to the client in the billing response file
If rebill fails for another event is generated with status “created”
Reject Request Handler
A Reject Request Handler will allow the user to mark certain bill requests as “Rejected” from the UI. This would be reflected in the customerbillingrequest table where the Bill_ID would appear as “Rejected”. A Rejected Request will not be reprocessed by GridX and the client will send a new bill request
The Reject Request Handler can be applied if:
An event (exception/warning) is generated and the client determines they want to reject the request associated with this event
The Reject Request handler can be applied to reject the bill request associated with the event
The handler will mark the status of the event as “request_rejected” and the request as “Rejected”
The client will send another bill request for the rejected request
Scenarios for a rejected request are:
An exception is generated and the code is predefined to be rejected
The event will have a level = “Exception” and status = “request_rejected” automatically triggered
The user will use the handler to mark the bill request as Rejected and close the loop on the Bill_ID. The client will send another bill request for the same bill period for GridX to process
An exception has been unresolved for more than 30 days since its creation (this is automated and configured in the workflow)
If an Invoice_Id is rejected by the client in the Invoice Report, the bill request should be automatically rejected and set at Rejected status
An informational level event with message “The invoice is rejected by the client“ is generated on the UI indicating an invoice was rejected by the client