Data migration blueprint legacy to sap

of 79
Beacon Programme
Data Migration Blueprint
Version No. : 2.0
Document Owner : Ajay Uppal
Document Reference : BN514 Data Migration Blue
print
Author(s) : Data Migration Team
Date Created : 15/03/2006
Status : Approved

of 79
External Document References
Document Ref. Title Version
BW118 Data Migration
Strategy e2e version
3.1
Data Migration
Strategy Document
1.0
BW230 Data Migration
Business Rules 1.0
Data Migration
Business Rules
1.0
Data stage EE(PX) Best
Practices v2.0
Data stage EE(PX)
Best Practices
2.0
Beacon Migration GL
Account Approach V0.4
Beacon Migration
GL Account
Approach V0.4
0.4

of 79
Table of Contents
1 Document Scope...............................................................................................................6
1.1 System Scope............................................................................................................6
1.2 Summary of Approach..............................................................................................7
1.3 Migration Objects .....................................................................................................9
2 Proposed Deployment....................................................................................................11
3 SAP Design .....................................................................................................................12
3.1 Business Partner......................................................................................................12
3.1.1 Requirements......................................................................................................12
3.1.2 Data Cleaning .....................................................................................................15
3.1.3 Load and Replication..........................................................................................16
3.1.4 Outstanding Issues..............................................................................................16
3.2 Business Partner Relationships ...............................................................................17
3.2.1 Requirements......................................................................................................17
3.2.2 Data Cleaning .....................................................................................................18
3.3 Site Contacts ...........................................................................................................19
3.3.1 Requirements......................................................................................................19
3.3.2 Data Cleaning .....................................................................................................20
3.4 Business Agreements / Contract Account...............................................................21
3.4.1 Requirements......................................................................................................21
3.4.2 Data Cleaning .....................................................................................................22
3.5 Connection Object...................................................................................................23
3.5.1 Requirements......................................................................................................23
3.5.2 Data Cleaning .....................................................................................................23
3.6 Premise....................................................................................................................24
3.6.1 Requirements......................................................................................................24
3.6.2 Data Cleaning .....................................................................................................24
3.7 Installation including Installation Facts, DPOD and Site Contact..........................25
3.7.1 Requirements......................................................................................................25
3.7.2 Data Cleaning .....................................................................................................27
3.8 Technical POD including POD Link, AQ table and Device Allocation.................28
3.8.1 Requirements......................................................................................................29
3.8.2 Data Cleaning .....................................................................................................30
3.9 Devices....................................................................................................................31
3.9.1 Requirements......................................................................................................31
3.9.2 Data Cleaning .....................................................................................................32

of 79
3.10 Device Installation ..................................................................................................32
3.10.1 Requirements..................................................................................................33
3.10.2 Data Cleaning.................................................................................................33
3.10.3 Load and Replication......................................................................................33
3.10.4 Outstanding Issues..........................................................................................33
3.11 Register Relationships.............................................................................................34
3.11.1 Requirements..................................................................................................34
3.11.2 Data Cleaning.................................................................................................34
3.12 Service Providers ....................................................................................................35
3.12.1 Requirements..................................................................................................35
3.12.2 Data Cleaning.................................................................................................36
3.13 MAQ3 .....................................................................................................................37
3.13.1 Requirements..................................................................................................37
3.13.2 Data Cleaning.................................................................................................37
3.14 Move-In and Contract Creation ..............................................................................38
3.14.1 Requirements..................................................................................................38
3.14.2 Data Cleaning.................................................................................................39
3.15 Finance related migration........................................................................................41
3.15.1 Data Cleaning.................................................................................................42
4 Load Sequencing............................................................................................................45
5 Performance Targets.....................................................................................................49
5.1 Performance optimisation in ISU............................................................................49
5.2 Performance optimisation in CRM Replication......................................................50
5.3 Performance optimisation in the staging area .........................................................50
6 SAP Configuration and Development Changes ..........................................................51
7 Deletion/Change Programs...........................................................................................52
8 Data Sources...................................................................................................................52
8.1 Historical Data ........................................................................................................54
9 Supplier Ids and MAM Appointment..........................................................................55
10 Legacy System Closure..................................................................................................55
10.1 Requirements to close the Legacy systems.............................................................57
10.2 Splitting of Payments post Go-Live........................................................................58
11 Data Cleansing Requirements ......................................................................................59
12 Extract and Transformation.........................................................................................60
13 Exclusion Rules (Stage I)...............................................................................................61
14 Rejection Rules (Stage IV) ............................................................................................61
15 Reporting Rules .............................................................................................................62
16 Reconciliation Procedure ..............................................................................................62
16.1 Reconciliation between Legacy and SAP Systems.................................................62
16.1.1 Functional Reconciliation...............................................................................63
16.1.2 Technical / Volume Reconciliation................................................................64

of 79
16.1.3 General Ledger Audit and Reconciliation......................................................64
16.2 Process Reconciliation............................................................................................64
16.3 Reconciliation between ISU and CRM...................................................................64
16.3.1 Volume Reconciliation:..................................................................................64
16.3.2 Quality Reconciliation:...................................................................................65
17 Appendix A– Data Migration Rules.............................................................................65
18 Appendix B– Single Customer View............................................................................67
19 Appendix C– Attachments............................................................................................79

of 79
1 Document Scope
This document provides the approach to the migration of the data from the legacy systems
into SAP ISU and CRM systems using the ETL option. A high-level design of the objects to
be migrated into SAP, with extract and cleansing criteria, is provided. This document also
provides an insight into different aspects such as performance of the migration and
reconciliation procedures. It also outlines the various activities that are triggered upon the
completion of the data migration, such as Supplier ID change and legacy system closure.
These activities are appropriately referenced in the below sections with mention to the
external documents to cover them in more detail.
1.1 System Scope
This document references the Data Migration Strategy document - BW118 Data Migration
Strategy e2e version 1.0, prepared with the inputs from the workshops conducted with the
business during High Level Design. The scope of this document is the migration of the Gas
customers’ data from the legacy systems outlined below.
Source Systems
 TGB – Tariff Gas Billing – contains BGB and BGRE customers. The DSPA and
BSMART systems are attached with the TGB system and contain the gas industry
data. Note, BSMART and DSPA are not in scope as source systems for migration.
 CGABS – Contract Gas Billing System – contains BGB customers. The SPA system
is attached with the CGABS system and contains the gas industry data.
 OXFORD Systems – Also known as Service Desk / Cash Desk / Contracts / CODA
systems. The business is currently discussing moving the migration of gas customers
from this system to Release 2.
Supporting Systems
 MAQ3 – OXFORD and CGABS
 E-mail Database
 TMS


 Employee Data Extracts
 Consultant Data Extracts
 SAM (to support manual migration only)
Third Party Systems
 Industry Data Extracts – Xoserve and National Grid Metering (NGM), IGTs and
iMAM’s
 pH Group
It is assumed that Industry Source will be able to provide the entire asset and related data as
required for Migration. Legacy sources such as B-Smart and DSPA will not be required for
any extracts. All other systems are considered out of scope for the migration of Gas customers
using the ETL approach.

Title BN514_Data Migration Blueprint Control Internal
Version 2.0 Date 06/04/2006
Page 7 of 79
Target Systems
Data extracted from the above systems will be uploaded to the following Target systems
SAP CRM
SAP ISU
SAP XI and BW will not be required for Data Migration. SAP XI might be utilised for
industry interaction for SUN and MAM Appointment files.
1.2 Summary of Approach
ISU Migration Workbench will be utilised to migrate objects into SAP ISU. The SAP
standard ISU to CRM replication program will then be used to transfer the appropriate items
from ISU to CRM. In cases where standard programs do not exist, custom load programs will
be developed to load or replicate specific information.
The following key groups of information will be migrated to SAP:
 Customer and account information;
 Site information
 Device information
 Contract information
 Financial information
The full listing of objects to be migrated is outlined in section 1.3
The Sites will not go through a registration process. Components that are currently populated
via industry flows, such as Devices, will be uploaded directly into ISU. The summary below
outlines some of the key changes between the Loss and Re-registration approach and the ETL
approach.
Customer and Account Information
The Business Partner, Business Partner Relationships, and Business Agreements will be
created with the same details and mapping rules as per the Loss and Re-registration approach.
The only distinction between the two migration approaches is that for ETL this information
will be loaded into SAP ISU and replication to SAP CRM. The reverse approach was utilised
for Loss and Re-registration. This includes all customer contact details.
Site Information
The site address details will be loaded into the ISU Connection Object and Premise and
replicated to the CRM IBASE. Supply point and meter point details are contained on the
Installation and Deregulation POD and the Technical POD. This information was previously
populated primarily from the industry flows. This information will now be obtained from a
combination of legacy systems extractions and industry sourced files. The DPOD contains
the confirmation reference number and the start date for registration. These details will now
relate to the earlier registration processed in legacy.

Page 8 of 79
The Meter Reading Units allocated to the Installation were previously determined as part of
the Transfer of Ownership industry flow. The allocation of the MRU will now occur via the
Move-In object. The Meter Reading Agency selection was previously occurring as part of the
Transfer of Ownership industry flow. The MRA will now be appointment to the TPOD via
migration of the TPOD in Migration Workbench.
Device Information
The Device will be created in SAP ISU based on information contained in the legacy systems.
Some of this information will be extracted from the billing system, i.e. TGB, CGABS and
Service Desk and some from industry sourced files.
The Devices will be installed on the Move-In Date and the same read as the Move-In read will
be utilised as the Installation read.
Contract Information
Contracts and Sites will be created in a ‘live’ status. The customer will be moved into the site
from the last bill date in legacy plus one day. The Move-In read will be the last bill read from
legacy. This read may be either an actual read or an estimate read. The Move-In read will be
flagged appropriately.
The Installation and Facts will be updated with product and pricing information prior to the
Move-In being performed in ISU. The ISU to CRM contract replication program will be
utilised to create the contract in CRM. Enhancement to this replication program will be
required to enable the correct product and pricing information to be populated on the CRM
contract. A custom change contract upload program will be utilised to update the BGB
specific fields in the CRM contract such as the MPR details and header details. For example,
the planned start date in the CRM Contract Header will be the actual contract start date of the
contract in legacy.
Financial Information
The scope and the migration approach for the migration of financial information will not
change from that currently in ETL2 (Loss & Re-registration approach). The trigger for the
ETL2 load will no longer be the final billing of the customer in legacy. Instead, the financial
information will be loaded in bulk for all customers that have been successfully migrated and
have their accounts in a live and billable state. Open financial information will only be loaded
for accounts that are currently live in the legacy systems.
The payment splitter tables will continue to be updated with the migrated account references
once the financials have been loaded.

Page 9 of 79
1.3 Migration Objects
The table below outlines the ISU object and the respective CRM object. For each object the
system of upload and the direction of the replication are listed. In addition, a determination of
whether additional development would be required to move to this option from the Loss / Re-
registration option is stated.
ISU Object CRM Object Upload
System
Replication
Direction
Additional
Development in
Extraction and
Transformation
Additional
Development
in Load
Replication
Amendment
Required
Business
Partner
Business
Partner
ISU ISU to CRM No Yes No
Business
Partner
change (post
TGB
migrations) *
Business
Partner
ISU ISU to CRM Yes Yes No
Business
Partner
Relationships
Business
Partner
Relationships
Site Contacts
Table
IBASE
relationships
ISU and
CRM
n/a Yes Yes No
Business
Agreement
Contract
Account
Connection
Object
IBASE (CO,
Premise)
Premise IBASE (CO,
Premise)
Deregulation
POD
IBASE
(DPOD)
Utility
Installation
and Facts
Contract
Products and
Prices
ISU ISU to CRM Yes Yes Yes
(appropriate
product and
pricing not
supported)
N/a MRU
Allocation
ISU N/a Yes Yes N/a
N/a MRA
Selection
ISU N/a Yes Yes N/a
Technical
POD
Contract Line
Items Meter
Details
ISU Part of
Change
contract in
CRM
Yes Yes Yes
POD Link
Table
N/a ISU N/a Yes Yes N/a
Devices N/a ISU N/a Yes Yes N/a
Devices
Installation
Allocate
Devices to
PODs

Page 10 of 79
ISU Object CRM Object Upload
System
Replication
Direction
Additional
Development in
Extraction and
Transformation
Additional
Development
in Load
Replication
Amendment
Required
Register
Relationships
AQ table N/a ISU N/a Yes Yes N/a
MAQ3 N/a ISU N/a No No N/a
Service
Providers
Appointment
– GT / IGT
Service
Providers
Appointment
– MAM
Service
Providers
Appointment
– MRA
ISU Contract
(Move-In)
CRM
Contract
ISU ISU to CRM Yes Yes Yes
ISU Contract
(Move-In)
CRM
Contract
(change)
CRM N/a Yes Yes N/a
Open Items N/a ISU N/a No No (ETL2) N/a
Payments N/a ISU N/a No No (ETL2) N/a
Instalment
Plans
N/a ISU N/a No No (ETL2) N/a
Payment
Schemes
N/a ISU N/a No No (ETL2) N/a
Credit
Worthiness
Score
N/a ISU N/a Yes Yes (ETL2) N/a
* Inclusion is subject to the confirmation by the business

of 79
2 Proposed Deployment
Proposed Timeframe
The exact time frame for the deployment of the system is yet to be finalized by the
business. The current assumption is that there will be a system-by-system ‘Big-Bang’
migration after a ‘Pilot’ run. The proposed Go-Live date is 1st
of January. However the
exact timing of migration event along with ‘Pilot’ is being discussed with Business.
Legacy System Sequencing
The migration events will follow a system-by-system approach. TGB will be migrated in
the first instance followed by CGABS and then Service desk. This applies to all
customers even if they have multiple accounts/Sites across multiple systems. Although
the actual migration events are system driven and independent, the single customer view
capability requires access to and visibility of all legacy systems and as such a cross
migration event dependency exists. pH group will provide the identification of same
customers across the system as part of Single Customer View discussed in detail in this
document.
This differs from the approach under the Loss and Re-registration migration approach,
which was a customer driven approach, i.e. all accounts and sites for a customer would
be migrated together independent of the legacy system from which they came.
Roll Out Approach
The final roll out approach is yet to be finalized. The current views are as follows:
 There will be several migration events for Release 1 deployment;
 A system-by-system approach will be utilised. That is, customers will be migrated
from only one of the billing systems in any of the given migration events;
 An initial pilot load is required by the business as this is viewed as an opportunity to
mitigate the risks that a ‘Big Bang’ migration would bring;
 After the pilot a system-system ‘Big Bang’ approach will be followed;
 The exact time required for each migration event is currently not known. These
timings will be formalised during the migration performance testing. At this stage the
target is to complete each of the migration events outlined below over a weekend
(Friday afternoon to Monday morning). However, for some of the larger migration
events an extended period maybe required (i.e. several working days at either side of
the weekend);
 Manual migration – As outlined in section 15 Appendix A Business Rules, there are
multiple reasons why a customer and their related accounts will be excluded from the
automated migration events. These customers will remain on the legacy systems until
they are in an appropriate state for transfer to SAP. There will be no final automated
clean up migration. These customers will be manually migrated to SAP.
 The proposed timeline for this migration is as follows:
 TGB pilot – the first migration event will be a pilot of between 50 – 75k
customers all sourced from TGB;
 TGB ‘Big Bang’ – the remaining TGB customer base that is eligible for
migration will then follow. At this stage, it is assumed that this will be
approximately 4 – 6 weeks after the TGB pilot load. The timing of this
migration will be based on the success of the pilot;
 CGABS ‘Big Bang’ – all CGABS customers that are eligible for migration
will then be migrated 4 – 6 weeks after the TGB final load; and

Page 12 of 79
Service Desk ‘Big Bang’ – the assumption is that the gas customers on Service Desk will be
migrated with the electricity customers as part of the Release 2 migration activities. The
timing of Release 2 and thus the roll out of the Service Desk customers has not been finalised.
3 SAP Design
This section outlines, for each migration object, the details of the functional requirements that
must be met as part of the upload, any key data cleansing requirements, details of the systems
from which data will be extracted, a summary of the load and replication programs and any
outstanding issues.
In the Analysis and Design phase of the Migration, a mapping specification with the list of the
complete attributes required for the migration of the each of these objects will be provided.
These mapping specifications will form the base for the extraction, transformation and load of
the business object in to SAP.
This document primarily captures business requirements for the migration objects built in
SAP, and the ETL processes that have to be built to support it. Requirements around the
legacy changes and third party interfaces are captured in the following documents. These
documents have to be updated to incorporate the ETL approach.
1. End to End Rel 1 Migration Requirements v1.0.doc
2. BW227 – SAP Object Wise Requirements for Data
3.1 Business Partner
Business Partners can be organisations (firms, branch offices) or persons.
3.1.1 Requirements
A Business Partner defined to have one of the following partner categories:
 Person
 Organisation
Each Business Partner will have a Business Partner role assigned. The roles that can be
assigned will depend on the partner category of the Business Partner as outlined below:
 Partner Category – Person:
 Contract Person
 Site contact
 Employee (e.g. account managers)
 Partner Category – Organisation:
 Sold To Party (Customer)
 Broker
 Sales Agency
 Bill To Party (created for alternative bill recipients)
 Payee (created for alternative payees)
 General (service providers). Note these Business Partners will be migrated
manually as part of the system set up.

Page 13 of 79
The information required for the Business Partner will vary based on the Business Partner
category and the Business Partner role. For example, a person Business Partner will require a
title field to be populated. This is not populated for the organisation Business Partner.
Business Partners with the role of contact may have special needs fields populated. These
fields are not populated for other Business Partners.
The Sold To Party Business Partner (Customer) will be the Business Partner for which the
accounts and contracts are linked. Sold to parties in the Beacon Solution can be only
Business Partners of the category organisation. Therefore, all Sold To Parties created in SAP
should represent a trading company, partnership, sole proprietor, etc. and not a person. In
some cases the legacy system account will contain information of the person associated with
the account and not the organisation name. In these cases data cleaning will be required to
obtain the organisation information, either from other fields in the legacy record or manual
follow up. Where this information cannot be obtained, a Business Partner organisation and a
separate Business Partner person will be created with the same information. This is required
because it is mandatory to have a contact on each CRM contract.
There are also accounts in TGB that do not contain an organisation name or a contact name
but are instead created in the name of ‘The Occupier’. The business has taken the decision not
to manually clean these accounts and identify the actual name of the customer. The SAP
Business Partner (customer) will be created with the name of ‘Business Owner’. Similarly,
the associated Business Partner contact person will be created with the same name.
Some of the key information contained in the Business Partner is as follows:
 Business Partner Type - The Business Partner Type will be either defined as corporate
or commercial based on information in legacy systems and agreed transformation
rules. The agreed rules vary by billing system and are as follows:
o TGB – all customers are assumed to be commercial customer (SME);
o CGABS – the bill frequency will be used to determine whether the customer
is a commercial or corporate customer;
o Service Desk – if an account manager is assigned to the account then the
customer will be considered a corporate customer.
The above rules have been agreed with the Business and it is therefore assumed that
this accurately reflects their view of their portfolio.
 Addresses - Multiple addresses can be stored against a Business Partner. Each
Business Partner must have at least one address, which is flagged as the primary
Business Partner address.
 Bank details - The Business Partner can hold one or multiple sets of bank details.
Bank details are mandatory if one of the Business Partner accounts pays by direct
debit.
 Industry sector – the industry sector will be populated primarily for the sold to
Business Partner (Customer). This filed will be defaulted to a value of ‘Unknown’ for
all migrated customers. The Data Leaders team took this decision as the information
contained in the legacy systems is viewed as inaccurate.
 SIC – this information will be provided by pH Group for SME customers and TMS
for I&C customers.
 Customer class – the customer class for a Business Partner will be either managed
account, strategic account, and core. This will be determined based on information in
legacy.
Single Customer View (SCV)

Page 14 of 79
A customer (Business Partner with a role of Sold To Party) may have multiple accounts
within one legacy system or across legacy systems. Currently, in the legacy systems these
customers are not recognised as a single customer. When migrated to SAP, only one
customer will be created in SAP corresponding to all of the customers and accounts in legacy.
Multiple Business Agreement s / Contract Accounts will be linked to one Business Partner.
As the new plan is to complete migration on a system-by-system basis, the same customer’s
Account(s) may be migrated at different times. The migration design will therefore need to
cater for adding additional Business Agreement s / Contract Accounts to an existing Business
Partner. (Note this is currently subject to change request.) This same approach will be applied
where the SCV is for customers with both gas and electricity accounts.
The determination of the single customer will vary based on whether the customer is a
Corporate or Commercial Customer:
 Corporate Customers – The Corporate team are providing a file of the Corporate
Customers containing the relevant customer details and account details. This
information will be utilised to create the Business Partners and the related Business
Agreement s.
 Commercial Customer –
o The customers and account information will be extracted from the legacy
systems. Automated data cleaning and transformation will then be performed
on this file. This will include execution of QAS batch on the addresses,
removal of names from address fields etc. Refer to section 3.1.2 Data
Cleaning for additional information. Note that the customers included in the
SCV feed will include both gas and electricity customers.
o pH Group will then analyse the data and based on defined matching rule
make an automated assessment of the single customers. The customers and
account name and address information will be utilised to determine a positive
match.
o pH Group will then provide a file containing the customers and their related
accounts. A lead record will be provided which includes the name and
primary address to be utilised in the Business Partner. This lead record
information will be independent of a system and can therefore relate to any of
the system information. (Note subject to CR.) The business partner will not
be migrated until at least one of their accounts is to be migrated.
o The lead record after this additional transformation will then be utilised to
create the Business Partner. This information will include the customer name,
primary address, company registration number, and industry sector code.
Other details including such things as additional addresses, bank details etc
will be extracted from legacy.
The scope of the single customer view does not extend to the following Business Partner
roles:
 Contract Person
 Site contact
 Bill To Party (created for alternative bill recipients)
 Payee (created for alternative payees)
 Broker
Refer to Appendix B – Single Customer View for more information

Page 15 of 79
3.1.2 Data Cleaning
Data cleaning of the customer information contained in legacy will be automatically and
manually performed. The details of the automated cleansing activities are outlined below.
Additional manual data cleaning may be required to ensure the quality of the data.
Figure 1-: SCV – Name and Address cleaning
1. Legacy Addresses are extracted and submitted to QAS where they are formatted into
PAF + Vanity
2. The Vanity information is then submitted to QualityStage where business rules will
be applied to ‘understand’ the legacy data. Names, Roles, FAO, T/A, C/O, etc. are
detected and moved into the appropriate fields.
3. The results are passed to pH, who identify customers across and within systems and
provide an SCV_ID to allow us to link these customers.
4. The pH provided data together with the data supplied to pH (Step 2 above) is
compared and a “Superset” of best quality data is derived using survivorship rules
defined by the business.
5. This best quality data is then passed to subsequent stages of migration where it is
joined to its associated legacy data using legacy keys which were retained at all stages
of the SCV process.
SCV - Name and Address Cleaning
-
Org Name
Tel#, Fax#
Vanity / Routing
PAF Address
QualityStage
DataStage
FAO, T/A, C/O
Name, Role
Org Name
Tel#, Fax#
Vanity/Routing
PAF Address
QAS+QS
SCV_ID
-
Name, Role
Org Name
Tel#, Fax#
-
PAF Address+ pH
SCV_ID
FAO, T/A, C/O
Name, Role
Org Name
Tel#, Fax#
Vanity/Routing
PAF Address+
Beacon
pH Group
QAS
Survivorship
Data
Migration
Business
Rules
QAS
Legacy
Time

Page 16 of 79
3.1.3 Load and Replication
3.1.3.1 Load Approach
The Data Migration Workbench will be utilised to load the Business Partners. Standard load
object PARTNER will be utilised.
The load of the Business Partners will be performed in 2 separate migrations based on the role
of the Business Partner: As specified in the section 4 - Load Sequence, customers will be
loaded first and all the contacts, employees and brokers will be loaded next.
The service providers, such as Xoserve, will be created manually during the system set up and
will not be part of this automated migration.
Subject to the approval of the SCV CR, a Change Business Partner load will be required for
post TGB migrations. This change object will add additional information, such as an
additional address and bank details, to an existing SAP business partner but will not change
existing information such as the BP name and primary address. This object is not required for
the TGB migration as it is assumed that SCV customers contained within TGB will be
migrated at the same time.
The Business Partners can be loaded independent of other objects.
3.1.3.2 Replication Approach
The standard adaptor objects BUPA_MAIN with object case of BUPA will be utilised to
transfer the Business Partners from ISU to CRM. The Business Partners will be replicated to
CRM in several stages consistent with he load approach outlined above. The method of
replication will be parallel requests with multiple queues.
3.1.4 Outstanding Issues
The following issues remain outstanding in relation to the Business Partner replication:
 There is no SCV of contacts. Therefore, the same person many be created multiple
times for each relationship they have to a different ‘sold-to’ party (customer). As
outlined in Appendix B SCV, if required it is assumed that the business will manually
change this set up in SAP post ‘go live’.
 A CR has been raised in relation to enabling the achievement of the single customer
view when one customer exists on multiple systems. The design approach outlined
above has been written on the basis that this CR is approved.
 Duplicate organisation Business Partner and person Business Partner – where
information is not included in legacy on both the organisation and the person, and
data cleaning is not performed, the information contained will be duplicated in both
the records. This will impact the correspondence, as there will be a repeat of the
name details. It is recommended that an indicator is included on the contact record to
highlight that it is a duplicate record and therefore exclude its name from the
correspondence. This will require a change to the standard correspondence function
model and therefore a CR will be required.

Page 17 of 79
 Additional automated and manual data cleaning of the customer details maybe
required to ensure the quality of the information provided. The business are currently
analysing the data quality to determine the requirements and a change request will be
raised as required.
 It has been identified that some customers in legacy contain both an organisation
name and a ‘Trading As’ name. The ‘Trading As’ name is currently not mapped into
an appropriate field in SAP and does not currently appear on the invoice.
3.2 Business Partner Relationships
A Business Partner relationship represents the business connection between two Business
Partners. For example, John Smith is a contact person of ABC Ltd.
3.2.1 Requirements
The ‘sold-to’ Business Partner (Customer) can have the following relationships with other
Business Partners:
 has contact person
 has account manager
 has broker
 has external agency
The contact Business Partner and the account manager Business Partner will be set up as
Business Partners of the type ‘Person’. The broker and external agencies Business Partner
will be created as Business Partner of the type ‘Organisation’. The creation of these Business
Partners will be via the migration workbench using the Business Partner object.
The site contacts and the contracts will be created via separate migrations and will be
discussed in sections 3.3. Site Contacts and section 3.14 Move-In and Contract Creation
respectively.
Only current Business Partner relationships will be migrated. The relationship will be
established from the date of migration. Each ‘sold-to’ Business Partner (Customer) can have
one or many of the above relationships.
All ‘sold-to’ Business Partners (Customer) will have at least one ‘has contact person’
relationship. However, some accounts in legacy do not currently have contact information.
In these cases the name from the legacy customer / account will be utilised to create the
contact person.
As part of the single customer view design for migration, multiple accounts in legacy maybe
linked to one ‘sold-to’ Business Partner (Customer). These customers / accounts in legacy
may have different or the same contacts. Where the contact is the same, only one Business
Partner contact will be created and only one relationship created between this contact and the
‘sold-to’ Business Partners (Customer).
Wherever, the same contact person is a contact for multiple ‘sold-to’ Business Partners,
multiple Business Partners will be created for each contact person. This is because the single
customer view of the contact persons will only be supported with a change request. The

Page 18 of 79
proposal is for a manual clean up of these duplicate contact persons to be performed after
migration.
Contact relationships will be created with relationship functions. These functions for
migration include:
 Partner
 Director
 Proprietor
 Manager
The determination of the appropriate function to assign will be based on information in
legacy. If this information does not exist than it will be left blank.
An I&C ‘sold-to’ Business Partner (Customer), must have an account manager relationship.
Only some SME ‘sold-to’ Business Partner will also have this relationship type. There will
be only one ‘has account manager’ Business Partner relationship for each ‘sold-to’ Business
Partner. However there is no validation to enforce this.
Broker and external agency relationships are optional and there may be many for each ‘sold-
to’ Business Partner.
Refer to Appendix B – Single Customer View for more information on how business partner
relationships will be impacted to achieve the single customer view during subsequent
migrations after TGB.
3.2.2 Data Cleaning
The data cleansing requirements will be as follows:
 Data cleaning will be required to obtain a unique contact name and ‘sold-to’ Business
Partner (Customer) name. In TGB in particular not all accounts have contacts. The
account is frequently created in the name of the person rather than the organisation.
In addition, the contact name is often embedded in the customer or account record I
legacy. The automated cleaning tools will be utilised to extract the contact name
from the customer or account records and based on agreed business rules determine
the organisation name. As outlined above where there is not a unique organisation
name and contact name the name will be duplicated in the business partners.
 Every ‘sold-to party’ I&C Business Partner (Customer), should have one ‘has account
manager’ relationship.
Further requirements will be communicated via the Data Migration FS documentation.
The Data Migration Workbench will be utilised to create the Business Partner relationships.
Standard load object PART_REL will be utilised.
The migration of the Business Partner relationships cannot occur until all of the Business
Partners have been loaded in ISU.

Page 19 of 79
Standard SAP replication program BUPA_REL will be utilised to transfer the Business
Partner relationships from ISU to CRM. The method of replication will be parallel requests
with multiple queues.
Questions for follow up:
 There is no SCV of contacts. Therefore, the same person many be created multiple
times for each relationship they have to a different ‘sold-to’ party (customer). As
outlined in Appendix B SCV, if required it is assumed that the business will manually
change this set up in SAP post ‘go live’.
 No relationship between Sold To Party Business Partners (Customer) is currently
supported. For example, the head office and branches Business Partner relationship is
only maintained at the account level if the customers are part of a collective or
collation billing arrangement. As outlined in Appendix B SCV, if required it is
assumed that the business will manually add the business partner relationship in SAP
post ‘go live’.
 Not all accounts in legacy have a contact. Each ‘sold-to’ Business Partner
(Customer) must have at least one contact person. The contact person will therefore
need to be created from information in the current account. Without data cleaning
this may result in the same name being populated in the contact Business Partner and
the ‘sold-to’ Business Partner. This will impact correspondence.
 The contact person relationship is with the sold-to-party business partner (customer).
There is no relationship between a contact and the contract account. This may impact
the addressing of some correspondence. Several options for resolving this are
currently under evaluation. A change request will be raised as required to support the
new requirements. The data migration design may also require change.
 A new requirement has been raised to maintain credit controllers relationships
in SAP. This requirement in currently not in scope and therefore it’s inclusion
will be managed via the change control process.
3.3 Site Contacts
The Site Contacts are the relationships between the emergency contacts and the individual
Sites.
3.3.1 Requirements
The site contacts will be created as Business Partner with the Business Partner type of person
and role of contact. These contacts will be created via the standard Business Partner
migration, refer to section 3.1 Business Partner.
Site contacts are represented in CRM via a relationship between the site contact Business
Partner and the IBASE. In ISU the site contact relationships are maintained in a custom table.
There is no standard or custom link between the site contacts maintained in CRM and those
maintained in ISU. Therefore, the site contacts will be migrated separately to both CRM and
ISU.

Page 20 of 79
Not all Sites will have site contacts. The number of contacts required for each site is based on
the site AQ, the product type, i.e. firm or interruptible, and whether the site is manned or not.
The site contacts will also be denoted as an emergency contact, interruptible contact, isolation
contact or consumer contact. The start date of the relationship will be extracted from the start
date in legacy.
The table below outlines the industry rules for the number of contacts that must exist for the
different types of sites.
Supply point Supply point
Manned 24
hours
Minimum
number of
Emergency
contacts
Maximum
number of
Emergency
contacts
Additional requirements
Firm
Competitive
Yes 1 5If Large firm competitive (AQ
> 1464000 KWH), at least 1
fax number should be
provided
Firm
Competitive
No 3 5If Large firm competitive (AQ
> 1464000 KWH), at least 1
fax number should be
provided
Interruptible
Competitive
Yes 1 4
Interruptible
Competitive
No 3 4
A single view of the emergency contacts will not be provided. That is where the same person
is a contact for multiple sites, a Business Partner will be created multiple times.
3.3.2 Data Cleaning
Based on the rules outlined above the relevant numbers of site contacts should be available for
each site.
The site contacts relationship to the IBASE will be created via the IBASE_Change BAPI.
The migration of the Business Partner relationships to the IBASE cannot occur until all of the
Business Partners have been loaded in ISU and replicated to CRM and all IBASEs replicated
to CRM.
The Site Contacts in ISU will be loaded into ZTUSM_CONTACT2 table, as part of the
DPOD migration. Event functionality of the Migration workbench will be will be utilised to
upload this data

Page 21 of 79
There is no standard replication program between the IBASE site contact in CRM and the site
contacts in the custom table in ISU. As outlined above the site contacts will be loaded
independently into CRM and ISU. When the site contacts are loaded into the IBASE in
CRM, standard IBASE replication program from CRM to ISU will be stopped for the
migration period.
No outstanding issues have been identified.
3.4 Business Agreements / Contract Account
The Business Agreement contains the details of the agreement with the customer such as
payment terms, reference to the customer bank accounts, credit follow up, etc. The Contract
Account is the ISU equivalent of the Business Agreement in CRM. The Contract Account
holds the financial position of the customer for all contracts associated with that account.
3.4.1 Requirements
There will be three types of Contract Accounts:
 Standard Contract Account;
 Collective Contract Account;
 Collation Contract Account.
One standard contract will be created for every active site. The collective and collation
Contract Accounts are used to support group-billing arrangements. Collective Contract
Accounts will be utilised when the parent Business Partner or the individual Business Partner
with multiple Sites, wishes to pay for all Sites as a group. The collative Contract Account
will be required where the parent Business Partner receives a summary statement for all of
their Sites but the individual Sites continue to pay for their individual invoices. The collective
and collation Contract Accounts will be linked to the individual standard Contract Accounts.
Refer to the Data Model v1.1 for further details.
The Business Agreement contains the billing address. This address is maintained in the
Business Partner and referenced in the Business Agreement. By default the Business
Partner’s primary address will be referenced in the Business Agreement. However, where the
billing address for the site is one of the secondary addresses of the Business Partner, this
address will be referenced.
The payment method and payment terms for the account are included in the Business
Agreement. The payment method can only be direct debit or blank. Where the payment
method is set to direct debit, the Business Agreement must also include a reference to one of
the bank accounts contained in the Business Partner. The payment terms set in the Business
Agreement must be equivalent to the payment terms included in the terms and condition of
the CRM contract.

Page 22 of 79
A default dunning procedure will be set based on whether the Business Partner is an I&C
customer or a SME customer.
The Business Agreement will also contain any alternative billing recipients, alternative
payers, alternative dunning recipients and alternative correspondence recipients. A separate
Business Partner of the type organisation will be created as part of the Business Partner
migration for each of these alternates.
Business locks will also be set as part of the Contract Account load. Only dunning locks will
be set. The dunning lock start date will be equal to the date the lock was set in legacy.
Refer to Appendix B – Single Customer View for more information on how business
agreements will be impacted to achieve the single customer view during subsequent
migrations after TGB
3.4.2 Data Cleaning
Data cleaning requirements will be communicated via the Data Migration FS documentation.
The Data Migration Workbench will be utilised to load the Contract Account. Standard load
object ACCOUNT will be utilised. No enhancements to this object will be required.
The Contract Account can only be loaded after the Business Partners of the type organisation
have been loaded. The collective and collation Contract Accounts must be loaded before the
standard Contract Accounts.
The standard SAP replication program BUAG_MAIN will be utilised to replicate the Contract
Accounts to CRM. The method of replication will be parallel requests with multiple queues.
The replication of the Contract Accounts must occur after the replication of the Business
Partners. The collective and collation Contract Accounts must be replicated before the
standard Contract Accounts.
The business locks are not resident in CRM. Therefore, they will not be included in the
replication from ISU to CRM.
The following are the outstanding issues in relation to the Business Agreement / Contract
Account:
 As outlined in the business partner relationship section contacts cannot be maintained
at contract account level. Some of the legacy system contacts relate to only one of the
customer’s account.. A change request will be raised if this is required.

Page 23 of 79
3.5 Connection Object
The ISU Connection Object typically represents a building, but can also be property or facility
such as a construction site or streetlight. The Connection Object is represented in CRM as a
component of an Installation Base (IBASE).
3.5.1 Requirements
The Connection Object contains the customer’s view of the site address. The Connection
Object will only be created for Sites that have live supply points.
The Connection Object will be set up with the following relationships to other objects:
 There will be a one to one relationship between the Connection Object and the
Premise;
 There will be a one to one relationship between the Connection Object / Premise and
Installation and deregulation POD. There will therefore be some Connection Objects
/ Premises set up with duplicate address, if there is a site with multiple supply points.
3.5.2 Data Cleaning
The SME Customer’s site address from the legacy systems will be sent on the pH Group file.
pH Group will then enhance the site address. This address will retain customer specific
cherished information and will therefore not go through QAS Batch for PAF validating. The
enhanced address from pH Group will be then be transferred to the staging area and utilised in
the upload.
The I&C Customer’s addresses will be sourced from TMS no QAS validation will be
performed on these addresses.
The Data Migration Workbench will be utilised to load the Connection Object. Standard load
object CONNOBJ will be utilised. No enhancements to this object will be required.
There are no dependencies on loading the Connection Object.
The Connection Object and the Premise together make up the site layer of the IBASE in
CRM. The Installation and DPOD correspond to the IBASE components in CRM. The
replication to CRM will therefore not occur until after all of the objects (Connection, Premise
and Installation) are loaded into ISU.
The standard SAP replication program SI_CONNOBJ will be utilised to create the IBASE.
Replication program SI_POD will then be executed to create the IBASE components, i.e. the
DPOD layer of the IBASE. No changes will need to be made to this replication program.
The method of replication will be parallel requests with multiple queues.

Page 24 of 79
3.6 Premise
The ISU Premise is a unit that is supplied with energy, such as an apartment or Factory. The
Premise is allocated to a Connection Object and the address of that Connection Object. There
can be a one to many relationship between the Connection Object and the Premise. At BGB
there will be a one to one relationship.
3.6.1 Requirements
The Premise will inherit the Connection Object address. It will also contain the SIC code. As
per the Connection Object, the Premise will only be created for Sites that have live supply
points.
The Premise will be set up with the following relationships to other objects:
 There will be a one to one relationship between the Connection Object and the
Premise;
 There will be a one to one relationship between the Connection Object / Premise and
Installation and Deregulation POD. There will therefore be some Connection
Objects / Premises set up with duplicate address, if there is a site with multiple supply
points.
3.6.2 Data Cleaning
As per the Connection Object address validations.
The Data Migration Workbench will be utilised to load the Premise. Standard load object
PREMISE will be utilised. No enhancements to this object will be required.
The Premise must be loaded after the Connection Object is successfully loaded.
replication to CRM will therefore not occur until after all of the objects are loaded into ISU.

Page 25 of 79
3.7 Installation including Installation Facts, DPOD and Site Contact
An Installation is allocated to a Premise and is specific to a division, e.g. gas or electricity. It
groups together the Devices, Registers, (Rate Categories) and Installation Facts. It is the link
between the technical Master Data and the business Master Data.
Installation Facts are attributes of an Installation, used to hold pricing information (used in
Billing) as well as supply point related information e.g. SOQ, supply type, interruptible days
The Deregulation POD is associated to an Installation and is used to hold supply point
information such as confirmation reference, confirmation effective date. The deregulation
POD is represented in CRM as an IBASE. The CRM deregulation POD IBASE is allocated
to the CRM Connection Object IBASE.
3.7.1 Requirements
The Installation and DPOD represent the supply point. Only supply points currently in
BGB’s ownership will be migrated. Sites that are mid registration or mid withdrawal will not
be migrated. After the site is registration is complete, the Installation and DPOD will be
migrated manually. To reduce the volumes of manual migration, the initiation of the
registrations in the legacy systems, just prior to migration, could be delayed until post
migration. For those Sites mid withdrawal where an objection is upheld, a manual migration
will also be required.
Sites that have been isolated and are pending a voluntary withdrawal should be withdrawn in
the legacy systems prior to migration. In addition, any Sites that are undergoing any re-
registration activities, aggregation, de-aggregation, AQ review, supply type change, etc,
should be completed in legacy prior to migration. Any voluntary withdrawals or re-
registrations that will not be effective in legacy prior to migration should be delayed starting
until after migration. The voluntary withdrawal or re-registration process will then be
initiated in SAP.
During the creation of the Supply points in SAP, a need to reference the Confirmation
Reference Number taken from the legacy or Xoserve extract. Using the Confirmation
Reference number, the supply points will be identified and any accounts where the supply
points exist across accounts and systems will be excluded
Installation
The Installation contains information relevant for billing and invoicing and the industry
supply point information including:

Page 26 of 79
 Rate Category – the Rate Category will be derived from the product. The Billing
Team has provided the translation logic. The Rate Category will be set based on the
product at the site as of the last bill. Where there has been a product change since
the last bill, then different rate categories will be provided for each time slice,
including their start and end dates.
 Billing class – the billing class will be defined as either SME or I&C based on the
customer currently associated with the site.
 Temperature Area – the Temperature Area determines the profile to be used for
estimation. The Temperature Area will be determined based on the end user
category obtained from legacy and the Temperature Area table in SAP. The
Temperature Area table in SAP will be downloaded to the staging area and the
determination of the Temperature Area will be performed in the staging area.
 LDZ Identifier – the LDZ identifier determines which CVs are to be used for billing.
The LDZ is maintained in legacy and SAP will be populated based on this
information.
 MRU – the Meter Reading Unit will be set to a default MRU as part of the
Installation migration. The correct MRU to be assigned will be allocated as part of
the Move-In migration. Refer to section 3.14 Move-In and Contract Creation for
further details.
Deregulation POD
The DPOD will contain information related to the supply point including:
 Confirmation reference number – this will be equal to the last confirmation reference
for the site when it was registered in legacy, i.e. the confirmation reference number
obtained when the site was first registered or re-registered. Therefore, only one
confirmation reference will be migrated to the DPOD. The start date of this
confirmation reference will be equal to the confirmation start date for this registration.
 The status of the DPOD will be defaulted to ‘live’.
 The Grid will be set to either Xoserve or IGT.
Installation Facts
Installation Facts are maintained against each Installation in SAP. Installation Facts can be
billing related, i.e. utilised in the billing calculations, non-billing related.
Billing Related Installation Facts include:
 Site based pricing information – prices since that last bill date will be maintained for
non tariff priced customers. In some cases more then one price will be maintained.
The multiple prices will be maintained as separate time slices in the Installation Facts.
The prices will include standard charge and unit charge.
 Direct debit discount applicability flag. This Fact will be populated as of the date of
migration.
 Tax related Facts including - CCL Exemption Percentage, domestic consumption
percentage, commercial consumption percentage, exemption percentage for VAT
calculations. This Fact will contain the different values since the last bill date. If
there has been a change since the last bill date then there will be more then one-time
slice.

Page 27 of 79
Tariff based prices and CCL rates will be maintained manually as part of the system set up
activities. 12 months of tariff prices will be maintained. This is on the basis that there will
only be between one and two prices changes in a year.
Non Billing Related Facts
 Supply types – firm or interruptible
 Xoserve and supplier interruptible days
 Minimum uptake quantity
 Interruptible firm elements indicator (this information will be obtained from SAM
and manually populated in SAP.)
 Interruption notice hours (this information will be obtained from SAM and manually
populated in SAP.)
 Transport Costs (this information will be obtained from SAM and manually populated
in SAP.)
 Xoserve related data – NDM SOQ, DM SOQ, DM SHQ, BSSOQ and MRF code.
The latest values, as at the migration date, will be stored in these Facts.
Site Contacts
Refer to section 3.3 Site Contacts for further details.
3.7.2 Data Cleaning
Key data cleansing requirements are given below
 Under the Loss and Re-Registration migration approach, the industry relevant data of
the Installation was obtained from the flows. This information now needs to be
extracted from a combination or legacy systems sources and industry provided files
under ETL approach.
The Data Migration Workbench will be utilised to load the Installation object. Standard load
object INSTLN will be utilised. The custom fields in the DPOD will be migrated utilising the
event functionality of migration workbench as part of the Installation migration. The site
contacts contained in a custom table in ISU will be loaded utilising the event functionality of
migration workbench as part of the Installation load, refer to section 3.3 Site Contacts for
further details.
The correct MRU will be allocated as part of the Move-In process. A dummy MRU will be
allocated as during the Installation load.
The Installation will be loaded once the Premise is migrated.
The grids will be created in SAP as part of the system set up (Manual). The service providers
relevant to the Grids also will be part of this manual upload

Page 28 of 79
replication to CRM will therefore not occur until after all of the objects are loaded into ISU.
Some of the information contained in the Installation, Installation Facts and DPOD will be
utilised to populate the CRM contract. The details of this replication will be discussed in
section 3.14 Move-In and Contract Creation.
Outstanding issues in relation to the Installation and DPOD object are given below
 The data source for a lot of the technical objects under the Loss and Re-registration
approach was the industry registration flows. This data will now be sourced from a
combination of legacy system sources and industry provided files. The exact source
of each field is as yet not finalised and will be agreed during the Detailed Design
phase. The current view is that the following information will be obtained from the
industry (note that some of this information will be populated o the objects discussed
below):
o Must Read Date
o Collar Fitted Indicator
o Collar Status Code
o Gas Nomination Type Code
o Meter Access Instructions
o Last Inspection Date
o MRA Reference
o NDM EZC
o Supply Point Category
o Shipper Reference
o Ownership received date
 The rules to be used to determine which MRU, i.e. meter reading and bill frequency,
is to be allocated are still to be agreed with the business. If these rules require
additional MRUs than have been configured than they will only be able to be
implemented in conjunction with the MRU CR.
3.8 Technical POD including POD Link, AQ table and Device Allocation
The Technical Point Of Delivery (TPOD) is the point to which a utility service is supplied,
or for which a utility service can be determined. It holds MPRN and meter point details in our
context
The POD Link Table maintains the relationship between the supply point (deregulation point
of delivery) and the meter point (technical point of delivery). For each relationship it
maintains the validity period of the relationship. That is the start date of the relationship is

Page 29 of 79
equivalent the confirmation effective date and the end date is set on losing the site and will be
equal to the ceased responsibility date.
The Meter Point AQ is a custom table used to maintain annual quantity history for meter
points.
Device allocation to the POD is the linkage of Devices to technical POD or meter point.
3.8.1 Requirements
A TPOD will be created for each MPRN, where the supply point is currently in BGB’s
ownership.
MPRNS that relate to sub meters that are not in BGB’s ownership will be created manually
post migration of the related prime meters. MPRNS for sub meters within BGBs ownership
will be migrated as per other MPRNs.
The key information maintained in the TPOD includes:
 Industry’s address for the MPRN - This address will not be validated by QAS.
 Meter access instructions – These access instructions can be customer provided or
industry provided. The meter access instructions will be obtained from the industry
file for TGB sites and from MAQ3 for CGABS and Service Desk.
 AQ and conversion Factors.
 Last Inspection and Last Read dates to support the Must-Inspect process
As part of the same upload object additional system updates will be performed. These are
outlined below.
POD Link Table
Only supply points and meter points that are currently in BGB’s ownership will be loaded
into SAP. As such the POD link table will be loaded with the relationships for Sites that are
currently live.
 The start date will be equal to the date the supply point was confirmed in the legacy
systems.
 As the only relationships for live Sites will be loaded the end date will not be
populated.
 The serial number should be set to a default of 1, as there will only be one
combination of DPOD and TPOD loaded.
Meter Point AQ Table
For every MPRN created an entry will be made in the Meter Point AQ table. This table will
contain the:
 MPRN;
 AQ; and
 the Start and End date of the AQ. – (The start date will be the confirmation effective
date of the site in SAP. The end date will be a default date in the future.)
Only the AQ for the meter point as of the date of migration will be loaded.

Page 30 of 79
Device Allocation
One TPOD will be linked to only one meter. One TPOD can be linked to multiple Devices,
where the site set up includes data loggers or converters.
3.8.2 Data Cleaning
The following areas should be considered for data cleansing:
 Reconciliation of the legacy system industry addresses with the industry address;
 Reconciliation of access instructions from the industry. TGB does not contain access
instructions. The industry access instructions for TGB sites will need to be compared
BSMART. If there is a variance the industry will need to be updated.
 Confirmation of source of the AQ. Either the legacy system or the industry AQ will
be utilised. The decision will be dependent on the AQ that will provide the most
accurate estimations;
 Confirmation of the gas act owner;
 Confirmation of the MAM;
 Reconciliation of the confirmation start dates from the legacy systems with the
industry.
The Data Migration Workbench will be utilised to load the TPOD. Standard load object POD
will be utilised.
The event functionality of migration workbench will be utilised to:
 Upload the POD link table;
 Upload the Meter Point AQ table; and
 Perform Device allocation to the TPOD.
The TPOD and related objects must be loaded after the completion of the DPOD, Device and
Device Installation migrations.
The TPOD is not managed a separate object in SAP CRM. Instead, it is maintained in a
custom tab in the CRM contract line item. The relationship between the contract, the IBASE
and the TPOD is stored in a custom table in CRM. There is no standard SAP replication of
the TPOD to the contract and the custom table. The approach for replicating these details will
be discussed in section 3.14 Move-In and Contract Creation.
The POD link relationships are only resident in ISU. Therefore, no replication to CRM is
required.
The customer’s view of the MPRNS AQ and the industry AQ at the point of sale is contained
in the CRM contract. For migration these AQ’s are not necessarily the same as the AQ that
will be stored in the Meter Point AQ table. As outlined above the AQ in this table will be the

Page 31 of 79
industry AQ at the point of migration. Therefore, there will be no replication of the
information in the AQ table to CRM. The CRM contract will be populated via other means.
Note that as there is no point of sale customer or industry AQ for TGB accounts, the CRM
contract industry AQ will be equal to the point of migration AQ and the customer AQ will not
be populated. Refer to section 3.14 Move-In and Contract Creation for further details.
Devices and there allocation to meter points is information that will only be resident in ISU.
Therefore, no replication to CRM is required.

The following outstanding issues have been identified:
 The source of the confirmation start date is yet to be finalised. At present it is
assumed that it will be sourced form the industry.
 The source of the AQ is yet to be agreed with the Business. It is assumed that this
information will be sourced from the industry.
3.9 Devices
The Device corresponds to a piece of equipment installed. A separate Device will be
maintained for meters, converter, and data logger.
3.9.1 Requirements
A separate Device will be maintained in SAP for:
 Meters;
 Converters (correctors); and
 Data loggers.
Devices installed at the supply point and meter point, as of the last legacy system bill, will be
created and installed in SAP.
If a meter exchange has been performed in legacy, since the last bill, then these will be
processed manually in SAP after the site is set up. It is anticipated that the volume of meter
exchanges from the last bill in legacy to the time of migration will be low. Therefore, limited
manual work should result. If the business wish to reduce the number of manual meter
exchanges to be performed in SAP after ‘go live’ then prior to migration the accounts could
be billed in legacy at the time of meter exchange. This will facilitate migration of the latest
Device details into SAP.
Both the prime and sub meters will be created as separate Devices, where both are in BGB’s
ownership. Sub meters that are not owned by BGB will not be part of the automated
migration and will be created manually post migration.
The Device will contain key information about the meter including the meter serial number,
the meter model number, the metric imperial indicators, the register Factor and the number of

Page 32 of 79
dials. Device class and characteristics functionality will be used to store some additional
Device attributes.
3.9.2 Data Cleaning
The cleaning of the asset information is essential for the success of the ETL migration. Some
of the key areas that will require cleaning include:
 Confirmation that the right asset for the supply point and meter point is allocated in
legacy;
 Reconciliation of the serial number and meter model number assigned to the meter in
legacy with industry information;
 Validation of the details assigned to the meter in legacy including such information as
the metric imperial indicators, register Factors, and the number of dials;
 Confirmation that the meter model code is a valid code based on Market Domain
Data; and
 Validation that the register attributes of the meter and corrector correspond to valid
‘register groups’ or combinations.
The Data Migration Workbench will be utilised to load the Devices. Standard load object
DEVICE will be utilised. The Device characteristic information also will be loaded using the
same object.
Device Master Data can be loaded independently. However, the Device should be loaded
before loading the technical POD and Device Installation objects.
The Devices will only be resident in SAP ISU. Therefore, no replication to CRM is required.
 The source of the prime and sub relationships details is to be confirmed. The current
assumption is that this information will be obtained from the industry as it is viewed
as being more reliable information than that contained in legacy systems.
3.10 Device Installation
Device Installation is the linkage of Devices to Installations. This holds information about
how SAP calculates consumption from reads loaded against the Device and which reads will
be used for billing.

Page 33 of 79
3.10.1 Requirements
Meters created as Devices in SAP will be installed onto their relevant Installation. Meters and
converters will be installed by a process of full installation. Data loggers will be only
technically installed. Data logger installation will be performed as part of the TPOD
migration via event functions, refer to section 3.8 Technical Point of Delivery.
The Devices will be installed as of the Sites last bill date in legacy. Read history prior to this
date will not be loaded. The last bill read will be used as the Installation read. This read will
then be utilised by the Move-In process as the Move-In read. The last billed read can be based
on the estimated read or the actual read
As outlined in section 3.9 Devices, meter exchanges since the last bill date will be managed
manually. The Device will be manually created in SAP and manually installed.
The installation process also populates data relevant for billing including periodic
consumption (AQ), gas procedure (which determines consumption calculation procedures)
and the volume correction Factor.
3.10.2 Data Cleaning
The data cleaning requirements for the Device Installation are consistent with those outlined
in sections 3.9.2 Device Data Cleaning.
The Data Migration Workbench will be utilised to fully install the meters and converters
Devices. Standard load object INST_MGMT will be utilised. The data logger devices will
only require technical installation. Data Migration Workbench will be utilised to technically
install the data loggers. Standard load object TECHINST will be utilised.
The Devices Installation will be performed after the Devices and Installations have been
migrated.
No replication to CRM is required.
 The current scope is that no read history will be migrated. Only the read on the last
bill will be migrated. This will mean that reads since the last read date would not be
migrated. Therefore, the daily reads from daily-metered sites will not be migrated.
These reads are currently not maintained in the legacy billing systems.
 The site will be set up from the last billed date. Dependent on the migration date
and the sites read window, meter read requests may or may not have been generated

Page 34 of 79
from legacy. An interim process will need to be developed to support these initial
reads. The business are currently investigating how this can be managed in SAP
and with the read agencies. The document assumes that no additional data or reads
will be required. If changes are required to the current meter read request or receipt
interfaces a change request will be required.
3.11 Register Relationships
Register relationships are SAP relationships created between Devices. These relationships
enable validation of reads loaded on one Device against those loaded on another Device.
Typically, this enables validation of corrector reads against meter reads.
3.11.1 Requirements
The two type of relationships supported are:
 Prime and sub meter relationships;
 Converter and meter registers.
As per scope of loss and re-registration migration only converters and meter reading
relationships will be set up automatically. The prime and subs relationships will be
established manually after the relevant Devices have been created.
The relationships will be created from the date that the Devices were installed in SAP, i.e. the
last bill date in legacy.
Where meter exchanges have occurred since the last bill date, the meter exchange will be
processed manually in SAP. Similarly, register relationships between these Devices will be
created manually.
No specific data cleansing requirements have been identified.
The Data Migration Workbench will be utilised to establish the meter register and converters
relationships. Standard load object REGRELSHIP will be utilised.
The register relationships will be migrated after the Devices have been migrated.

Page 35 of 79
 As specified above Register Relationship will be established between the Meter
Register and Converted Register of the Converter. This relationship ensures that the
consumption between these two registers of an Installation will be within 2.5%
tolerance limit. Based on these validations many readings will fail post Go-Live. This
required is under discussion with the business. Discussions are currently underway
with the Business to agree to an increased tolerance limit.
3.12 Service Providers
POD Services are records of services (and service providers providing the service) provided
for a supply point or meter point. Beacon will need to maintain records of the Gas transporters
for a supply point and meter asset manager and meter reading agent for a meter point
3.12.1 Requirements
Service providers, e.g. Xoserve will be created as Business Partners. These Business Partners
will be created as organisation Business Partner types and will have roles of vendor. These
Business Partners will then be created as service providers in ISU. The creation of the
Business Partners and the set up of service providers in ISU will be performed manually as
part of the system set up.
The Contract References between the service providers and BGB will be set up as ‘Service
Provider Agreements’ in SAP. This is currently limited to MAM service and will be done
manually as part of the system set up.
Three types of service providers will be appointed:
1. Gas transporters
2. Meter Asset Managers
3. Meter Reading Agencies
Gas Transporters
The Gas Transporters will be appointed at the deregulation Pod for every supply point. Either
Xoserve or Independent Gas Transporters (IGT) will be appointed as the Gas Transporter.
The MPR number ranges will be used to determine if the supply point belongs to Xoserve or
an IGT.
Unique sites do not have an MPRN. Some of these supply points will be GTs and some IGTs.
As the number of unique Sites is low the Gas Transporter to be appointed will be determined
manually.
IGT sites were previously excluded from the Loss and Re-registration migration. These sites
and the related IGT service provider’s relationships will be included in the ETL migration.
The Gas Transporter will be appointed from the legacy system confirmation start date.

Page 36 of 79
Meter Asset Managers
The MAM will be appointed at the technical POD for all meter points. The MAM that is
currently assigned to the meter point in legacy will also be appointed to the TPOD in SAP.
As part of the supplier id change the MAM will need to be de-appointed and re-appointed.
This process will be managed in the staging area, via a bulk updated. Refer to section 9
Supplier Id Changes for further details on this process.
The start date for the appointment will be equal to the new appointment date after the supplier
id change. Note that this will mean that the MAM is not appointed to the MPR for the whole
period in SAP, i.e. from the last bill date to the new appointment date.
Meter Reading Agencies
The MRA will be appointed at the technical POD for all meter points.
The postcode will be utilised to derive the MRA for each meter point. The postcode from the
TPOD will be utilised to derive the MRA for the correcting postcode regions contained in
custom table in SAP.
This varies from the business as usual process for MRA selection and appointment. The
reason for the variance is to increase the efficiency of the data load. It is not anticipated that
this will have an impact on the MRA selection: The details of the variances are outlined
below:
 In future business as usual processes the read frequency is used in conjunction with
the postcode to derive the MRA. Currently in legacy the same MRA is appointed
whether he site is monthly read or quarterly read.
 In future BAU the Connection Object / supply point postcode will be utilised to
derive the MRA. In legacy there are few variance between the Connection Object
postcode and the TPOD postcode. It is also unlikely that these postcodes will fall into
different regions and thus result in a different MRA being appointed.
The MRA will be appointed from the last bill date.
Data cleansing may be required to ensure that the MAM appointed to the Sites in legacy can
be identified. This would be required to correctly carry out supplier id change in the staging
area. Along with this, it would be required to cleanse data about gas act ownership for meter
points in BGB’s portfolio as this could impact future MAM appointment.
The Data Migration Workbench will be utilised to appoint the Gas Transporters and the
MAM. Standard load object PODSERVICE will be utilised. Gas Transporters will be
appointed using events at the time of uploading Installations and de-reg PODs.

Page 37 of 79
The MRA will be appointed as part of the TPOD migration utilising event functionality.
The Gas Transporters can be appointed after the creation of DPOD and Installation. The
MAM appointment migration will be performed after the TPOD migration.
No replication to CRM of the service providers appointed is required.
The following issues are still outstanding in relation to the Service Provider objects:
 The MAM’s currently appointed to the site are not contained in the legacy systems.
The source of this information is to be determined.
 The process for obtaining data from the IMAMs and IGTs is still to be finalised.
3.13 MAQ3
The MAQ3 table is a custom SAP table that contains an additional address for some meter
points. This address is considered a more reliable address than the industry address held on
the TPOD. This address if present will be used in place of the TPOD address and sent to the
meter reading agencies.
3.13.1 Requirements
Only a small percentage of the meter points will also have a MAQ3 address. The table will
contain the MPRN reference and the address details. The address will be loaded as it is
maintained in legacy with no data cleaning.
No specific data cleansing requirements have been identified.
A custom batch program will be utilised to upload the addresses into the MAQ3 table. The
migration can occur independently to the other migrations.

Page 38 of 79
3.14 Move-In and Contract Creation
The Move-In process in ISU generates the ISU contract and the link between the customer
and the site, i.e. the SAP business partner and contract account and the installation.
The CRM contract represents the paper contract. The contract can contain multiple line items.
Each line item represents a supply point. Meter point details are maintained in a custom tab
on the contract line item.
3.14.1 Requirements
The Move-In will be performed to link every active supply point to the correct business
partner and contract account. The Move-In date will be equal to the date the customer was
last billed in legacy plus one day.
The Move-In read will be equal to the device installation read. As outlined above this read
will be equal to the last billing read in legacy.
Customers that have not been billed for an extended period will not be migrated. Data
cleaning of these sites is required before migration can occur. It is recommended that
accounts not billed for more then 2 months for monthly billed accounts and 6 months for
quarterly billed accounts will not be migrated.
The contract in CRM will be created based on the information in ISU. The contract will then
be supplemented with additional information that is not contained in ISU. Some of the key
details included in the contract area as follows:
 The contract line item equates to the ISU contract and will therefore include the
supply point (IBASE);
 The contract start date will be equal to the Move-In date. The planned contract start
date will be equal to the actual contract start date in legacy. The planned contract end
date will be equal to the planned end date in legacy. TGB accounts are not related to a
contract and therefore will not have a contract start and end date. For TGB accounts
the CRM contract planned start date will be equal to the move in date in legacy and
the planned end will be set to a default future date. Where the Move-In date has been
archived from TGB the planned start date will also be equal to an agreed default date
 The contract header and line item status will be set to live;
 The meter point details will be populated with the MPRN, MPR AQ, postcode etc.
Note that the CRM contract contains both the customers view of the AQ and the
industries view of the AQ at the point of sale. As there is no related contract
information for TGB accounts only the industry view of the AQ will be populated.
This AQ will be the meter point AQ at the point of migration;

Page 39 of 79
 Product including the configurable attributes of the product and prices will be based
on details from legacy;
 The terms and conditions in the header will be as per the legacy terms and conditions;
 The external reference number will include the legacy contract number;
 The contract line items will be flagged to denote that it has been migrated.
Contracts will be created with multiple line items to align to the contracts maintained in
legacy. TGB customers that have multiple sites will be created in different contract. TGB
sites are managed separately and do not have one contract for all sites. In addition, the terms
and conditions of these sites may vary. Therefore a separate contract is required.
Sites that are mid registration or mid withdrawal will not be migrated and therefore no Move-
In will occur and not contract in CRM created for these customers.
Contracts that are mid termination will be migrated and set to a status of live and the products
that are applicable before the termination. The contract termination actions will then be
triggered manually after migration. The details of the termination including the termination
reason and the date the termination was received will be updated manually via this action.
Contracts that are mid renewal or have been renewed since the last billing date will be
migrated with the details as of the last billing date. Further analysis is required to determine
how the contract will be manually progressed to the mid renewal or post renewal state.
Refer to Appendix B – Single Customer View for more information on how ISU Contracts
will be impacted to achieve the single customer view during subsequent migrations after
TGB.
The data cleaning requirements of the contract attributes will be consistent with the
requirements outlined for the Loss and Re-registration approach. The additional data cleaning
requirements include:
 Customers who have not been billed for an extended period must be billed to their last
billing date before migration.
The Data Migration Workbench will be utilised to execute the Move-In process in ISU.
Standard load object MOVE_IN will be utilised. The Move-In migration is dependent on
most of the other migration activities and will therefore be scheduled as the last activity.
This object will also update correct MRU at the Installation using the event functionality.
After the replication of the contract to CRM, refer to section 3.14.3.2 Replication Approach,
the CRM contract will be changed to update it with the additional information not populated
via the replication. The standard BAPI Contract Change will be utilised. The following are
the key groups that will be updated via this BAPI:
 Partner functions at header and line item

Page 40 of 79
 Custom fields at head and line item (This will also include the details of the meter
point such as MPRN.)
 Contract dates
 Pricing information and configurable attributes
This contract change program is required as not all of the information is resident in ISU.
The standard replication object SI_CONTRACT will be utilised. The method of replication
will be parallel requests with multiple queues. Customisation of this object will be required to
support BGB requirements. The areas that will require change include:
 Product determination
 Multiple line items on a contract
 Contract processing type to enable different types for SME and I&C.
Refer to the sections below for further details.
 EVERH Table population program enhancement
As per the standard process once Move-In is completed in ISU (ISU Contract created), we
are required to run program ECRM_GENERATE_EVERH. This program populates
EVERH table with the following details.
 ISU Contract Number
 Valid to
 Valid from
 Installation
 Replication Controls
 Indicators (NOD)
The following fields are not populated via the replication program.
 CRM Contract Header GUID
 CRM Contract Line item GUID
 CRM Product (*)
 CRM PRODUCT GUID
 CRM Transaction Number
 Item number
The product is determined based on the service type in the installation. . This would require
configuration of service types equal to number of products and population of this in the
installation. There are 80 products and therefore 80 service types would need to be
configured. This is redundant configuration not required for business as usual. It has
therefore been decided that it will be more efficient to use a custom approach. Modification
of ECRM_GENERATE_EVERH will update EVERH with the product id based on the
information provided from staging. The key would be the installation.
The standard program does not support the creation of multiple line items in a contract.
Amendments will be required to select the approach ISU contracts for a customer and link
them into one contract with multiple line items.

Data migration blueprint legacy to sap

Data migration blueprint legacy to sap

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Data migration blueprint legacy to sap

Similar to Data migration blueprint legacy to sap (20)

More from Ajay Kumar Uppal

More from Ajay Kumar Uppal (20)

Recently uploaded

Recently uploaded (20)

Data migration blueprint legacy to sap