Customer Information System

Each entity through which a retailer serves customers has its own unique way of communicating with the retailer. In addition, utilities are notorious for providing incomplete and inaccurate data. REBO specializes in both facilitating communication with and managing data from those entities. Our systems automatically acquire, process, and validate the data, maintain schemas, and report results.

REBO offers a cost effective alternative to in house customer data management. Among the services we provide are:

• Utility and ISO file processing
• Data validation
• Reporting
• Integration into client systems

Data Acquisition

REBO provides in-house XML and flat file processing and validation. EDI files are processed by EC Infosystems (ECI) who validate EDI content & format. REBO tests incoming files per the business rules established by the retailer and REBO. REBO archives all inbound and outbound files.

Our automated data acquisition generally downloads files overnight allowing us to process, analyze and report by 7 am. Likewise, outgoing files are processed and sent to meet the utilities delivery schedule.

REBO provides file management for all retailer transactions with the utility and ISO.

• Testing with the utility or ISO, EDI, XML or flat file testing required to transact with the utility or ISO.
• Acquire and process customer enrollment and usage data from utilities/ISO
  • REBO offers an on line enrollment form if only a few customers need to be enrolled, or
  • For large a large number of enrollments, import of retailer generated flat files, or direct extraction for the retailer’s customer information system.
  • Daily preparation of enrollments and historic usage requests
  • Daily receipt and processing of EDI or XML transaction sets
  • Daily receipt and processing of flat files,
  • Acquisition and processing of MVWeb data
• Acquire and process billing & payment data from the utility or ISO
  • Daily receipt and processing of 810 and 820 EDI or XML transaction sets
  • Daily receipt and processing of flat files
• Acquire and process other utility and ISO data such as:
  • Daily and monthly customer status reports
  • Profile updates
  • Losses updates
  • Schema updates
  • Utility rates

Data Validation

Incoming customer data is validated based on a set of business rules established by REBO and the retailer, while outgoing files meet the rules set by the utility. For incoming customer enrollment and usage, data validation is performed for the 4C’s:

• Current –Is all of the data up to date?
• Complete – Are there missing days or billing cycles within the usage history?
• Correct – Is the usage what is expected and appropriate for each customer? Are there duplications or overlapping data?
• Consistent – Is the usage consistent with the enrollment start and end dates? Is the data consistent month-to-month? Year-to-year?

Reporting

Data access to via ASP or FTP, including reports such as:

• History of customer or aggregate usage
• Customers in service
• Exception reporting – notice of inconsistent data (i.e., data doesn’t satisfy the 4Cs)
• Forecasting files – short and long term
• Billing files
• Reconciliation of usage and settlement
• Reconciliation of usage and billing

REBO’s database is structured to allow the retailer maximum flexibility in analyzing and reporting customer data by organizing customer data at multiple levels. In addition to allowing aggregation by utility, utility rate code, and the retailer’s pricing, REBO allows customer meters to be grouped at five levels of corporate structure as shown in Figure DA1.

At the base level, we use a meter location key that relates each meter to an account number; equivalent to where a meter base is installed. Using this key allows us to track usage through meter and account number changes. In addition, each meter location is related to a utility rate and the customer’s price and retailer account number.

All accounts can be rolled up to a facility. The facility may represent the total operation on a site or just one definable component of that operation and is generally all accounts at a service address.

The aggregation level allows the user to define data aggregation and reporting for a group of facilities. For example this might be assembly operations for and auto company or franchisees restaurants for a fast food chain.

The company level than allows grouping aggregations, e.g., to North American operations for the auto company or KFC for the fast food chain.

Finally, the user can group to the parent or holding company level. This could be Ford Motor for the auto company or Yum! Brands for the fast food chain.

Each relationship can be defined at the time of enrollment or added later through an online user interface.