Customer Lifecycle Example - Another Look

This section expands on the example above, and provides specific references to the system data and objects used for each transaction.

• The Distributor is set up as a Service Provider and Market Participant in Customer Cloud Service
  • Billing Options for the Distributor are defined as "We Bill For Them, Rate Ready"
• Both Retailers are set up as Service Providers and Market Participants in Customer Cloud Service
• The Customer is defined as a Customer/Account/Premise/Service Point/Meter and a Registration Point in Customer Cloud Service

Business Process / Step	MTM USD Data and Objects
Customer Enrollment	A customer enrolls with a retailer.
Retailer A sends a Historical Usage Request transaction (814) to the Distributor.	The transaction is sent in standard EDI format. A Electronic Service Bus (ESB) or other integration component converts the message into the "MTM XML" format, based on the business object schema of the appropriate business object.
The Distributor receives the Historical Usage Request transaction, and validates that it has all the information needed to process the request. If the transaction passes validation, the Distributor sends an acceptance transaction (814) to Retailer A, and the Distributor sends an Historical Usage transaction (867) to Retailer A. If the transaction fails the validation, the Distributor sends a rejection transaction (814) to Retailer A.	As the message is received, an Inbound Market Message is created. The business object for this message is based on the Inbound 814 Historical Usage Request Root (U2-In814HUReqRoot) parent business object. Validation is performed based on the validation defined for the 814 Historical Usage Request Market Message Type, based on the In 814 Historical Usage Req Admin Root (U2-In814HUReqAdminRoot) parent business object. The Acceptance/Rejection transactions are Outbound Market Messages. The business object used for these is based on the Outbound 814 Historical Usage Resp Root (U2-Out814HUResponseRoot) parent business object. The Historical Usage transaction is an Outbound Market Message. The business object used for this is based on either the Outbound 867 Historical Usage Intrvl Root (U2-Out867HUIntervalRoot) or the Outbound 867 Historical Usage Scalar Root (U2-Out867HUScalarRoot) parent business object (depending on whether the customer is an interval or scalar customer).
Retailer A sends an Enrollment transaction (814) to the Distributor.	The transaction is sent in standard EDI format. A Electronic Service Bus (ESB) or other integration component converts the message into the "MTM XML" format, based on the business object schema of the appropriate business object.
The Distributor receives the Enrollment transaction, and validates that it has all the information needed to enroll the customer. If the transaction passes validation, the Distributor sends an acceptance transaction (814) to Retailer A, and the customer information system is updated as needed to reflect the customer's enrollment with Retailer A and enables the customer for billing. If the transaction fails the validation, the Distributor sends a rejection transaction (814) to Retailer A.	As the message is received, an Inbound Market Message is created. The business object for this message is based on the Inbound 814 Enrollment Request Root (U2-In814EnrolReqRoot) parent business object. Validation is performed based on the validation defined for the 814 Enrollment Request Market Message Type, based on the Inbound 814 Enrollment Request Admin Root (U2-In814EnrolReqAdminRoot) parent business object. The Acceptance/Rejection transactions are Outbound Market Messages. The business object used for these is based on the Outbound 814 Enrollment Response Root (U2-Out814EnrlNtfcnRspRoot) parent business object. Enabling the customer billing is performed by a Market Process that creates the data needed, including creating a Service Agreement and Starting service for the customer. The business object for the Market Process would be based on the Customer Registration Process Root (U2-CRPRoot) example business object.
Billing	The customer is billed for their service.
The customer's bill is calculated each billing period based on the customer's billing cycle (typically monthly).	This is done via the standard billing functionality provided with Customer Cloud Service.
When a bill is completed, the Distributor sends a Usage transaction (867) and an Invoice transaction (810) to Retailer A. If either or both are invalid for some reason, Retailer A sends a rejection transaction (824) to the Distributor.	The Add Bill Details to GenProc on Bill Completion (U2BILLGENPRC) Bill Completion algorithm defined on the SA Type creates records in the General Processing table containing bill details. The following batch processes create Outbound Market Messages: Create Outbound 867 Monthly Usage (U2CRE867): The business object for this message is based on the Outbound 867 Monthly Interval Usage Root (U2-Out867MUIntervalRoot) or Outbound 867 Monthly Usage Scalar (U2-Out867MUScalarRoot) parent business objects. Create Outbound 810 Charges (U2CRE810): The business object for this message is based on the Outbound 810 Invoice Charges Root (U2-Out810InvChargesRoot) parent business object. The specific business objects created by these batch processes are defined in corresponding Master Configurations. The messages are created in the "Pending" state. A Monitor batch process moves them into the "Created" state where a series of algorithms populates the messages with appropriate data. The Rejection transaction is an Outbound Market Message. The business object for this is based on the Outbound 824 Application Advice Root (U2-Out824AppAdviceRoot) parent business object.
Payment	The customer pays their bill.
The billing system sends a AP Request Adjustment to the Financial System, which is routed to the bank.	This is done via the standard billing functionality provided with Customer Cloud Service.
Once the payment has cleared, the Distributor sends a Payment transaction (820) to Retailer.	The Payment transactions is an Outbound Market Message. The business object used for this is based on the Outbound 820 Remittance Advice Root (U2-Out820RemittanceAdviceRoot) parent business object.
The Distributor receives the Payment transaction, and validates that it has all the information needed to process the payment. If the transaction passes validation, the Distributor sends an acceptance transaction (824) to Retailer A. If the transaction fails the validation, the Distributor sends a rejection transaction (824) to Retailer A.	The transaction is sent in standard EDI format. A Electronic Service Bus (ESB) or other integration component converts the message into the "MTM XML" format, based on the business object schema of the appropriate business object. As the message is received, an Inbound Market Message is created. The business object for this message is based on the Inbound 820 Remittance Pay Advice Root (U2-IN820RemittanceAdvRoot) parent business object. Validation is performed based on the validation defined for the 820 Remittance Pay Advice Market Message Type, based on the Inbound 820 Remittance Advice Admin Root (U2-IN820RemittanceAdviceAdmin) parent business object. The Acceptance/Rejection transactions are Outbound Market Messages. The business objects used for these are based on the Outbound 824 Application Advice Root (U2-Out824AppAdviceRoot) parent business object.
Switching Retailers	The customer decides to switch retailers from Retailer A to Retailer B.
Retailer B sends a Historical Usage Request transaction (814) to the Distributor.	The transaction is sent in standard EDI format. A Electronic Service Bus (ESB) or other integration component converts the message into the "MTM XML" format, based on the business object schema of the appropriate business object.
The Distributor receives the Historical Usage Request transaction, and validates that it has all the information needed to process the request. If the transaction passes validation, the Distributor sends an acceptance transaction (814) to Retailer B, and the Distributor sends a Usage transaction (867) to Retailer B. If the transaction fails the validation, the Distributor sends a rejection transaction (814) to Retailer B.	As the message is received, an Inbound Market Message is created. The business object for this message is based on the Inbound 814 Historical Usage Request Root (U2-In814HUReqRoot) parent business object. Validation is performed based on the validation defined for the 814 Historical Usage Request Market Message Type, based on the In 814 Historical Usage Req Admin Root (U2-In814HUReqAdminRoot) parent business object. The Acceptance/Rejection transactions are Outbound Market Messages. The business object used for these is based on the Outbound 814 Historical Usage Resp Root (U2-Out814HUResponseRoot) parent business object. The Historical Usage transaction is an Outbound Market Message. The business object used for this is based on either the Outbound 867 Historical Usage Intrvl Root (U2-Out867HUIntervalRoot) or the Outbound 867 Historical Usage Scalar Root (U2-Out867HUScalarRoot) parent business object (depending on whether the customer is an interval or scalar customer).
Retailer B sends an Enrollment transaction (814) to the Distributor.	The transaction is sent in standard EDI format. A Electronic Service Bus (ESB) or other integration component converts the message into the "MTM XML" format, based on the business object schema of the appropriate business object.
The Distributor receives the Enrollment transaction, and validates that it has all the information needed to enroll the customer. If the transaction passes validation, the Distributor sends an acceptance transaction (814) to Retailer B, and the customer information system is updated as needed to reflect the customer's enrollment with Retailer B and enable the customer for billing. If the transaction fails the validation, the Distributor sends a rejection transaction (814) to Retailer B.	As the message is received, an Inbound Market Message is created. The business object for this message is based on the Inbound 814 Enrollment Request Root (U2-In814EnrolReqRoot) parent business object. Validation is performed based on the validation defined for the 814 Enrollment Request Market Message Type, based on the Inbound 814 Enrollment Request Admin Root (U2-In814EnrolReqAdminRoot) parent business object. The Acceptance/Rejection transactions are Outbound Market Messages. The business object used for these is based on the Outbound 814 Enrollment Response Root (U2-Out814EnrlNtfcnRspRoot) parent business object. Enabling the customer billing is performed by a Market Process that creates the data needed, including creating a Service Agreement and Starting service for the customer. The business object for the Market Process is based on the Customer Registration Process Root (U2-CRPRoot) parent business object.
The Distributor sends a Drop transaction (814) to Retailer A.	The Drop transaction is an Outbound Market Message. The business object used for this is based on the Outbound 814 Drop Req Switch Root (U2-Out814DropReqSwRoot) parent business object.
The Distributor sends a Confirmation transaction (814) to Retailer B.	The Confirmation transaction is an Outbound Market Message. The business object used for this is based on the Outbound 814 Enrollment Response Root (U2-Out814EnrlNtfcnRspRoot) parent business object.
Customer Information Changes	The customer's phone number changes.
Retailer B sends a Change Request transaction (814) to the Distributor.	The transaction is sent in standard EDI format. A Electronic Service Bus (ESB) or other integration component converts the message into the "MTM XML" format, based on the business object schema of the appropriate business object.
The Distributor receives the Change Request transaction, and validates that it has all the information needed to process the request. If the transaction passes validation, the Distributor sends an acceptance transaction (814) to Retailer B. If the transaction fails the validation, the Distributor sends a rejection transaction (814) to Retailer B.	As the message is received, an Inbound Market Message is created. The business object for this message is based on the Inbound 814 Change Request Root (U2-In814ChangeReqRoot) parent business object. Validation is performed based on the validation defined for the 814 Change Request Market Message Type, based on the Inbound 814 Change Request Admin Root (U2-In814ChangeReqAdminRoot) parent business object. Updating the customer's phone number is performed by a Market Process that updates the data as applicable. The business object for the Market Process is based on the Change Process Root (U2-CPRoot) parent business object.
Meter Exchange	The distributor changes the meter at the customer's premise.
Distributor sends a Change Request transaction (814) to Retailer B. If the transaction is invalid for some reason, Retailer B sends a rejection transaction (824) to the Distributor.	The Change Request transaction is an Outbound Market Message. The business object used for this is based on the Outbound 814 Change Request Root (U2-PLOut814CRRoot) parent business object.
Customer Drops Retailer	The customer chooses to drop their retailer and purchase direct from the distributor.
Retailer B sends a Drop transaction (814) to the Distributor.	The transaction is sent in standard EDI format. A Electronic Service Bus (ESB) or other integration component converts the message into the "MTM XML" format, based on the business object schema of the appropriate business object.
The Distributor receives the Drop transaction, and validates that it has all the information needed to drop the customer. If the transaction passes validation, the Distributor sends an acceptance transaction (814) to Retailer B, and the customer information system is updated as needed to enable the customer for billing by the distributor. If the transaction fails the validation, the Distributor sends a rejection transaction (814) to Retailer B.	As the message is received, an Inbound Market Message is created. The business object for this message is based on the Inbound 814 Manual Drop Response Root (U2-In814DropRspRoot) parent business object. Validation is performed based on the validation defined for the 814 Change Request Market Message Type, based on the Inbound 814 Drop Request Admin Root (U2-In814DropReqAdminRoot) parent business object. Updating the customer's billing setup is performed by a Market Process that updates the data as applicable. The business object for the Market Process is based on the Change Process Root (U2-CPRoot) parent business object.
The Distributor sends a Drop transaction (814) to Retailer B.	The Drop transaction is an Outbound Market Message. The business object used for this is based on the Outbound 814 Manual Drop Req Root (U2-Out814MDropRequestRoot) parent business object.