Data migration blueprint legacy to sap

of 79

Beacon Programme

Data Migration Blueprint

Version No. : 2.0Document Owner : Ajay UppalDocument Reference : BN514 Data Migration Blue

printAuthor(s) : Data Migration TeamDate Created : 15/03/2006Status : Approved

of 79

External Document ReferencesDocument Ref. Title Version

BW118 Data MigrationStrategy e2e version3.1

Data MigrationStrategy Document 1.0

BW230 Data MigrationBusiness Rules 1.0

Data MigrationBusiness Rules 1.0

Data stage EE(PX) BestPractices v2.0

Data stage EE(PX)Best Practices 2.0

Beacon Migration GLAccount Approach V0.4

Beacon MigrationGL AccountApproach V0.4

0.4

of 79

Table of Contents

1 Document Scope...............................................................................................................61.1 System Scope ............................................................................................................61.2 Summary of Approach ..............................................................................................71.3 Migration Objects .....................................................................................................9

2 Proposed Deployment....................................................................................................113 SAP Design .....................................................................................................................12

3.1 Business Partner......................................................................................................123.1.1 Requirements ......................................................................................................123.1.2 Data Cleaning .....................................................................................................153.1.3 Load and Replication..........................................................................................163.1.4 Outstanding Issues ..............................................................................................16

3.2 Business Partner Relationships ...............................................................................173.2.1 Requirements ......................................................................................................173.2.2 Data Cleaning .....................................................................................................183.2.3 Load and Replication..........................................................................................183.2.4 Outstanding Issues ..............................................................................................19

3.3 Site Contacts ...........................................................................................................193.3.1 Requirements ......................................................................................................193.3.2 Data Cleaning .....................................................................................................203.3.3 Load and Replication..........................................................................................203.3.4 Outstanding Issues ..............................................................................................21

3.4 Business Agreements / Contract Account...............................................................213.4.1 Requirements ......................................................................................................213.4.2 Data Cleaning .....................................................................................................223.4.3 Load and Replication..........................................................................................223.4.4 Outstanding Issues ..............................................................................................22

3.5 Connection Object...................................................................................................233.5.1 Requirements ......................................................................................................233.5.2 Data Cleaning .....................................................................................................233.5.3 Load and Replication..........................................................................................233.5.4 Outstanding Issues ..............................................................................................24

3.6 Premise....................................................................................................................243.6.1 Requirements ......................................................................................................243.6.2 Data Cleaning .....................................................................................................243.6.3 Load and Replication..........................................................................................243.6.4 Outstanding Issues ..............................................................................................25

3.7 Installation including Installation Facts, DPOD and Site Contact ..........................253.7.1 Requirements ......................................................................................................253.7.2 Data Cleaning .....................................................................................................273.7.3 Load and Replication..........................................................................................273.7.4 Outstanding Issues ..............................................................................................28

3.8 Technical POD including POD Link, AQ table and Device Allocation.................283.8.1 Requirements ......................................................................................................293.8.2 Data Cleaning .....................................................................................................303.8.3 Load and Replication..........................................................................................303.8.4 Outstanding Issues ..............................................................................................31

3.9 Devices....................................................................................................................313.9.1 Requirements ......................................................................................................313.9.2 Data Cleaning .....................................................................................................32

of 79

3.9.3 Load and Replication..........................................................................................323.9.4 Outstanding Issues ..............................................................................................32

3.10 Device Installation ..................................................................................................323.10.1 Requirements..................................................................................................333.10.2 Data Cleaning.................................................................................................333.10.3 Load and Replication......................................................................................333.10.4 Outstanding Issues..........................................................................................33

3.11 Register Relationships.............................................................................................343.11.1 Requirements..................................................................................................343.11.2 Data Cleaning.................................................................................................343.11.3 Load and Replication......................................................................................343.11.4 Outstanding Issues..........................................................................................35

3.12 Service Providers ....................................................................................................353.12.1 Requirements..................................................................................................353.12.2 Data Cleaning.................................................................................................363.12.3 Load and Replication......................................................................................363.12.4 Outstanding Issues..........................................................................................37

3.13 MAQ3 .....................................................................................................................373.13.1 Requirements..................................................................................................373.13.2 Data Cleaning.................................................................................................373.13.3 Load and Replication......................................................................................373.13.4 Outstanding Issues..........................................................................................38

3.14 Move-In and Contract Creation ..............................................................................383.14.1 Requirements..................................................................................................383.14.2 Data Cleaning.................................................................................................393.14.3 Load and Replication......................................................................................393.14.4 Outstanding Issues..........................................................................................41

3.15 Finance related migration........................................................................................413.15.1 Data Cleaning.................................................................................................423.15.2 Load and Replication......................................................................................433.15.3 Outstanding Issues..........................................................................................43

4 Load Sequencing............................................................................................................455 Performance Targets .....................................................................................................49

5.1 Performance optimisation in ISU............................................................................495.2 Performance optimisation in CRM Replication......................................................505.3 Performance optimisation in the staging area .........................................................50

6 SAP Configuration and Development Changes ..........................................................517 Deletion/Change Programs ...........................................................................................528 Data Sources...................................................................................................................52

8.1 Historical Data ........................................................................................................549 Supplier Ids and MAM Appointment..........................................................................5510 Legacy System Closure..................................................................................................55

10.1 Requirements to close the Legacy systems .............................................................5710.2 Splitting of Payments post Go-Live........................................................................58

11 Data Cleansing Requirements ......................................................................................5912 Extract and Transformation.........................................................................................6013 Exclusion Rules (Stage I)...............................................................................................6114 Rejection Rules (Stage IV) ............................................................................................6115 Reporting Rules .............................................................................................................6216 Reconciliation Procedure ..............................................................................................62

16.1 Reconciliation between Legacy and SAP Systems .................................................6216.1.1 Functional Reconciliation...............................................................................6316.1.2 Technical / Volume Reconciliation ................................................................64

of 79

16.1.3 General Ledger Audit and Reconciliation......................................................6416.2 Process Reconciliation ............................................................................................6416.3 Reconciliation between ISU and CRM...................................................................64

16.3.1 Volume Reconciliation:..................................................................................6416.3.2 Quality Reconciliation:...................................................................................65

17 Appendix A– Data Migration Rules.............................................................................6518 Appendix B– Single Customer View ............................................................................6719 Appendix C– Attachments ............................................................................................79

of 79

1 Document Scope

This document provides the approach to the migration of the data from the legacy systemsinto SAP ISU and CRM systems using the ETL option. A high-level design of the objects tobe migrated into SAP, with extract and cleansing criteria, is provided. This document alsoprovides an insight into different aspects such as performance of the migration andreconciliation procedures. It also outlines the various activities that are triggered upon thecompletion 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 theexternal documents to cover them in more detail.

1.1 System Scope

This document references the Data Migration Strategy document - BW118 Data MigrationStrategy e2e version 1.0, prepared with the inputs from the workshops conducted with thebusiness during High Level Design. The scope of this document is the migration of the Gascustomers’ data from the legacy systems outlined below.

Source Systems

TGB – Tariff Gas Billing – contains BGB and BGRE customers. The DSPA andBSMART systems are attached with the TGB system and contain the gas industrydata. Note, BSMART and DSPA are not in scope as source systems for migration.

CGABS – Contract Gas Billing System – contains BGB customers. The SPA systemis attached with the CGABS system and contains the gas industry data.

OXFORD Systems – Also known as Service Desk / Cash Desk / Contracts / CODAsystems. The business is currently discussing moving the migration of gas customersfrom 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 andiMAM’s

pH Group

It is assumed that Industry Source will be able to provide the entire asset and related data asrequired for Migration. Legacy sources such as B-Smart and DSPA will not be required forany extracts. All other systems are considered out of scope for the migration of Gas customersusing the ETL approach.

Title BN514_Data Migration Blueprint Control InternalVersion 2.0 Date 06/04/2006

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 forindustry 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 SAPstandard ISU to CRM replication program will then be used to transfer the appropriate itemsfrom ISU to CRM. In cases where standard programs do not exist, custom load programs willbe 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 populatedvia industry flows, such as Devices, will be uploaded directly into ISU. The summary belowoutlines some of the key changes between the Loss and Re-registration approach and the ETLapproach.

Customer and Account Information

The Business Partner, Business Partner Relationships, and Business Agreements will becreated 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 informationwill be loaded into SAP ISU and replication to SAP CRM. The reverse approach was utilisedfor 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 andreplicated to the CRM IBASE. Supply point and meter point details are contained on theInstallation and Deregulation POD and the Technical POD. This information was previouslypopulated primarily from the industry flows. This information will now be obtained from acombination of legacy systems extractions and industry sourced files. The DPOD containsthe confirmation reference number and the start date for registration. These details will nowrelate to the earlier registration processed in legacy.


of 79

The Meter Reading Units allocated to the Installation were previously determined as part ofthe Transfer of Ownership industry flow. The allocation of the MRU will now occur via theMove-In object. The Meter Reading Agency selection was previously occurring as part of theTransfer of Ownership industry flow. The MRA will now be appointment to the TPOD viamigration 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 andService 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 willbe utilised as the Installation read.

Contract Information

Contracts and Sites will be created in a ‘live’ status. The customer will be moved into the sitefrom the last bill date in legacy plus one day. The Move-In read will be the last bill read fromlegacy. This read may be either an actual read or an estimate read. The Move-In read will beflagged appropriately.

The Installation and Facts will be updated with product and pricing information prior to theMove-In being performed in ISU. The ISU to CRM contract replication program will beutilised to create the contract in CRM. Enhancement to this replication program will berequired to enable the correct product and pricing information to be populated on the CRMcontract. A custom change contract upload program will be utilised to update the BGBspecific 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 thecontract in legacy.

Financial Information

The scope and the migration approach for the migration of financial information will notchange from that currently in ETL2 (Loss & Re-registration approach). The trigger for theETL2 load will no longer be the final billing of the customer in legacy. Instead, the financialinformation will be loaded in bulk for all customers that have been successfully migrated andhave their accounts in a live and billable state. Open financial information will only be loadedfor accounts that are currently live in the legacy systems.

The payment splitter tables will continue to be updated with the migrated account referencesonce the financials have been loaded.


of 79

1.3 Migration Objects

The table below outlines the ISU object and the respective CRM object. For each object thesystem of upload and the direction of the replication are listed. In addition, a determination ofwhether additional development would be required to move to this option from the Loss / Re-registration option is stated.

ISU Object CRM Object UploadSystem

ReplicationDirection

AdditionalDevelopment inExtraction andTransformation

AdditionalDevelopmentin Load

ReplicationAmendmentRequired

BusinessPartner

BusinessPartner

ISU ISU to CRM No Yes No

BusinessPartnerchange (postTGBmigrations) *

BusinessPartner

ISU ISU to CRM Yes Yes No

BusinessPartnerRelationships

BusinessPartnerRelationships


Site ContactsTable

IBASErelationships

ISU andCRM

n/a Yes Yes No

BusinessAgreement

ContractAccount


ConnectionObject

IBASE (CO,Premise)


Premise IBASE (CO,Premise)


DeregulationPOD

IBASE(DPOD)


UtilityInstallationand Facts

ContractProducts andPrices

ISU ISU to CRM Yes Yes Yes(appropriateproduct andpricing notsupported)

N/a MRUAllocation

ISU N/a Yes Yes N/a

N/a MRASelection

ISU N/a Yes Yes N/a

TechnicalPOD

Contract LineItems MeterDetails

ISU Part ofChangecontract inCRM

Yes Yes Yes

POD LinkTable

N/a ISU N/a Yes Yes N/a

Devices N/a ISU N/a Yes Yes N/aDevicesInstallation


AllocateDevices toPODs



of 79

ISU Object CRM Object UploadSystem

ReplicationDirection

AdditionalDevelopment inExtraction andTransformation

AdditionalDevelopmentin Load

ReplicationAmendmentRequired

RegisterRelationships


AQ table N/a ISU N/a Yes Yes N/aMAQ3 N/a ISU N/a No No N/aServiceProvidersAppointment– GT / IGT


ServiceProvidersAppointment– MAM


ServiceProvidersAppointment– MRA


ISU Contract(Move-In)

CRMContract

ISU ISU to CRM Yes Yes Yes

ISU Contract(Move-In)

CRMContract(change)

CRM N/a Yes Yes N/a

Open Items N/a ISU N/a No No (ETL2) N/aPayments N/a ISU N/a No No (ETL2) N/aInstalmentPlans

N/a ISU N/a No No (ETL2) N/a

PaymentSchemes

N/a ISU N/a No No (ETL2) N/a

CreditWorthinessScore

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 TimeframeThe exact time frame for the deployment of the system is yet to be finalized by thebusiness. 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 theexact timing of migration event along with ‘Pilot’ is being discussed with Business.

Legacy System SequencingThe migration events will follow a system-by-system approach. TGB will be migrated inthe first instance followed by CGABS and then Service desk. This applies to allcustomers even if they have multiple accounts/Sites across multiple systems. Althoughthe actual migration events are system driven and independent, the single customer viewcapability requires access to and visibility of all legacy systems and as such a crossmigration event dependency exists. pH group will provide the identification of samecustomers across the system as part of Single Customer View discussed in detail in thisdocument.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 wouldbe migrated together independent of the legacy system from which they came.

Roll Out ApproachThe 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 thetarget is to complete each of the migration events outlined below over a weekend(Friday afternoon to Monday morning). However, for some of the larger migrationevents an extended period maybe required (i.e. several working days at either side ofthe weekend);

Manual migration – As outlined in section 15 Appendix A Business Rules, there aremultiple reasons why a customer and their related accounts will be excluded from theautomated migration events. These customers will remain on the legacy systems untilthey are in an appropriate state for transfer to SAP. There will be no final automatedclean 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 beapproximately 4 – 6 weeks after the TGB pilot load. The timing of thismigration will be based on the success of the pilot;

CGABS ‘Big Bang’ – all CGABS customers that are eligible for migrationwill then be migrated 4 – 6 weeks after the TGB final load; and


of 79

Service Desk ‘Big Bang’ – the assumption is that the gas customers on Service Desk will bemigrated with the electricity customers as part of the Release 2 migration activities. Thetiming 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 thatmust be met as part of the upload, any key data cleansing requirements, details of the systemsfrom which data will be extracted, a summary of the load and replication programs and anyoutstanding issues.

In the Analysis and Design phase of the Migration, a mapping specification with the list of thecomplete 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 ofthe business object in to SAP.

This document primarily captures business requirements for the migration objects built inSAP, and the ETL processes that have to be built to support it. Requirements around thelegacy changes and third party interfaces are captured in the following documents. Thesedocuments have to be updated to incorporate the ETL approach.

1. End to End Rel 1 Migration Requirements v1.0.doc2. 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 beassigned 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.


of 79

The information required for the Business Partner will vary based on the Business Partnercategory and the Business Partner role. For example, a person Business Partner will require atitle 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. Thesefields are not populated for other Business Partners.

The Sold To Party Business Partner (Customer) will be the Business Partner for which theaccounts and contracts are linked. Sold to parties in the Beacon Solution can be onlyBusiness Partners of the category organisation. Therefore, all Sold To Parties created in SAPshould represent a trading company, partnership, sole proprietor, etc. and not a person. Insome cases the legacy system account will contain information of the person associated withthe account and not the organisation name. In these cases data cleaning will be required toobtain the organisation information, either from other fields in the legacy record or manualfollow up. Where this information cannot be obtained, a Business Partner organisation and aseparate Business Partner person will be created with the same information. This is requiredbecause 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 namebut are instead created in the name of ‘The Occupier’. The business has taken the decision notto manually clean these accounts and identify the actual name of the customer. The SAPBusiness 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 corporateor commercial based on information in legacy systems and agreed transformationrules. 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 thatthis accurately reflects their view of their portfolio.

Addresses - Multiple addresses can be stored against a Business Partner. EachBusiness Partner must have at least one address, which is flagged as the primaryBusiness 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 directdebit.

Industry sector – the industry sector will be populated primarily for the sold toBusiness Partner (Customer). This filed will be defaulted to a value of ‘Unknown’ forall migrated customers. The Data Leaders team took this decision as the informationcontained in the legacy systems is viewed as inaccurate.

SIC – this information will be provided by pH Group for SME customers and TMSfor I&C customers.

Customer class – the customer class for a Business Partner will be either managedaccount, strategic account, and core. This will be determined based on information inlegacy.

Single Customer View (SCV)


of 79

A customer (Business Partner with a role of Sold To Party) may have multiple accountswithin one legacy system or across legacy systems. Currently, in the legacy systems thesecustomers are not recognised as a single customer. When migrated to SAP, only onecustomer 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’sAccount(s) may be migrated at different times. The migration design will therefore need tocater for adding additional Business Agreement s / Contract Accounts to an existing BusinessPartner. (Note this is currently subject to change request.) This same approach will be appliedwhere 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 aCorporate or Commercial Customer:

Corporate Customers – The Corporate team are providing a file of the CorporateCustomers containing the relevant customer details and account details. Thisinformation will be utilised to create the Business Partners and the related BusinessAgreement s.

Commercial Customer –o The customers and account information will be extracted from the legacy

systems. Automated data cleaning and transformation will then be performedon 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 DataCleaning for additional information. Note that the customers included in theSCV feed will include both gas and electricity customers.

o pH Group will then analyse the data and based on defined matching rulemake an automated assessment of the single customers. The customers andaccount name and address information will be utilised to determine a positivematch.

o pH Group will then provide a file containing the customers and their relatedaccounts. A lead record will be provided which includes the name andprimary address to be utilised in the Business Partner. This lead recordinformation will be independent of a system and can therefore relate to any ofthe system information. (Note subject to CR.) The business partner will notbe migrated until at least one of their accounts is to be migrated.

o The lead record after this additional transformation will then be utilised tocreate 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 etcwill be extracted from legacy.

The scope of the single customer view does not extend to the following Business Partnerroles:

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


of 79

3.1.2 Data Cleaning

Data cleaning of the customer information contained in legacy will be automatically andmanually 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 intoPAF + Vanity

2. The Vanity information is then submitted to QualityStage where business rules willbe applied to ‘understand’ the legacy data. Names, Roles, FAO, T/A, C/O, etc. aredetected and moved into the appropriate fields.

3. The results are passed to pH, who identify customers across and within systems andprovide 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) iscompared and a “Superset” of best quality data is derived using survivorship rulesdefined by the business.

5. This best quality data is then passed to subsequent stages of migration where it isjoined to its associated legacy data using legacy keys which were retained at all stagesof 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 + Q

S

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

DataMigration

BusinessRules

QAS

Legacy

Time


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 loadobject PARTNER will be utilised.

The load of the Business Partners will be performed in 2 separate migrations based on the roleof the Business Partner: As specified in the section 4 - Load Sequence, customers will beloaded 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 andwill not be part of this automated migration.

Subject to the approval of the SCV CR, a Change Business Partner load will be required forpost TGB migrations. This change object will add additional information, such as anadditional address and bank details, to an existing SAP business partner but will not changeexisting information such as the BP name and primary address. This object is not required forthe TGB migration as it is assumed that SCV customers contained within TGB will bemigrated 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 totransfer the Business Partners from ISU to CRM. The Business Partners will be replicated toCRM in several stages consistent with he load approach outlined above. The method ofreplication 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 multipletimes for each relationship they have to a different ‘sold-to’ party (customer). Asoutlined in Appendix B SCV, if required it is assumed that the business will manuallychange this set up in SAP post ‘go live’.

A CR has been raised in relation to enabling the achievement of the single customerview when one customer exists on multiple systems. The design approach outlinedabove has been written on the basis that this CR is approved.

Duplicate organisation Business Partner and person Business Partner – whereinformation is not included in legacy on both the organisation and the person, anddata cleaning is not performed, the information contained will be duplicated in boththe records. This will impact the correspondence, as there will be a repeat of thename details. It is recommended that an indicator is included on the contact record tohighlight that it is a duplicate record and therefore exclude its name from thecorrespondence. This will require a change to the standard correspondence functionmodel and therefore a CR will be required.


of 79

Additional automated and manual data cleaning of the customer details mayberequired to ensure the quality of the information provided. The business are currentlyanalysing the data quality to determine the requirements and a change request will beraised as required.

It has been identified that some customers in legacy contain both an organisationname and a ‘Trading As’ name. The ‘Trading As’ name is currently not mapped intoan 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 BusinessPartners. 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 otherBusiness 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 asBusiness Partners of the type ‘Person’. The broker and external agencies Business Partnerwill be created as Business Partner of the type ‘Organisation’. The creation of these BusinessPartners 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 bediscussed in sections 3.3. Site Contacts and section 3.14 Move-In and Contract Creationrespectively.

Only current Business Partner relationships will be migrated. The relationship will beestablished from the date of migration. Each ‘sold-to’ Business Partner (Customer) can haveone 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 thecontact person.

As part of the single customer view design for migration, multiple accounts in legacy maybelinked to one ‘sold-to’ Business Partner (Customer). These customers / accounts in legacymay have different or the same contacts. Where the contact is the same, only one BusinessPartner 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 singlecustomer view of the contact persons will only be supported with a change request. The


of 79

proposal is for a manual clean up of these duplicate contact persons to be performed aftermigration.

Contact relationships will be created with relationship functions. These functions formigration include:

Partner Director Proprietor Manager

The determination of the appropriate function to assign will be based on information inlegacy. 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 willbe only one ‘has account manager’ Business Partner relationship for each ‘sold-to’ BusinessPartner. 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 partnerrelationships will be impacted to achieve the single customer view during subsequentmigrations 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’ BusinessPartner (Customer) name. In TGB in particular not all accounts have contacts. Theaccount 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 Ilegacy. The automated cleaning tools will be utilised to extract the contact namefrom the customer or account records and based on agreed business rules determinethe organisation name. As outlined above where there is not a unique organisationname 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 accountmanager’ 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 BusinessPartners have been loaded in ISU.


of 79


Standard SAP replication program BUPA_REL will be utilised to transfer the BusinessPartner relationships from ISU to CRM. The method of replication will be parallel requestswith multiple queues.


Questions for follow up:

There is no SCV of contacts. Therefore, the same person many be created multipletimes for each relationship they have to a different ‘sold-to’ party (customer). Asoutlined in Appendix B SCV, if required it is assumed that the business will manuallychange this set up in SAP post ‘go live’.

No relationship between Sold To Party Business Partners (Customer) is currentlysupported. For example, the head office and branches Business Partner relationship isonly maintained at the account level if the customers are part of a collective orcollation billing arrangement. As outlined in Appendix B SCV, if required it isassumed that the business will manually add the business partner relationship in SAPpost ‘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 thereforeneed to be created from information in the current account. Without data cleaningthis may result in the same name being populated in the contact Business Partner andthe ‘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 impactthe addressing of some correspondence. Several options for resolving this arecurrently under evaluation. A change request will be raised as required to support thenew requirements. The data migration design may also require change.

A new requirement has been raised to maintain credit controllers relationshipsin SAP. This requirement in currently not in scope and therefore it’s inclusionwill be managed via the change control process.

3.3 Site Contacts

The Site Contacts are the relationships between the emergency contacts and the individualSites.

3.3.1 Requirements

The site contacts will be created as Business Partner with the Business Partner type of personand role of contact. These contacts will be created via the standard Business Partnermigration, refer to section 3.1 Business Partner.

Site contacts are represented in CRM via a relationship between the site contact BusinessPartner 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 thosemaintained in ISU. Therefore, the site contacts will be migrated separately to both CRM andISU.


of 79

Not all Sites will have site contacts. The number of contacts required for each site is based onthe 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, isolationcontact or consumer contact. The start date of the relationship will be extracted from the startdate in legacy.

The table below outlines the industry rules for the number of contacts that must exist for thedifferent types of sites.

Supply point Supply pointManned 24hours

Minimumnumber ofEmergencycontacts

Maximumnumber ofEmergencycontacts

Additional requirements

FirmCompetitive

Yes 1 5If Large firm competitive (AQ> 1464000 KWH), at least 1fax number should beprovided

FirmCompetitive

No 3 5If Large firm competitive (AQ> 1464000 KWH), at least 1fax number should beprovided

InterruptibleCompetitive

Yes 1 4

InterruptibleCompetitive

No 3 4

A single view of the emergency contacts will not be provided. That is where the same personis 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 foreach 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 theBusiness Partners have been loaded in ISU and replicated to CRM and all IBASEs replicatedto CRM.

The Site Contacts in ISU will be loaded into ZTUSM_CONTACT2 table, as part of theDPOD migration. Event functionality of the Migration workbench will be will be utilised toupload this data


of 79


There is no standard replication program between the IBASE site contact in CRM and the sitecontacts in the custom table in ISU. As outlined above the site contacts will be loadedindependently into CRM and ISU. When the site contacts are loaded into the IBASE inCRM, standard IBASE replication program from CRM to ISU will be stopped for themigration 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 aspayment terms, reference to the customer bank accounts, credit follow up, etc. The ContractAccount is the ISU equivalent of the Business Agreement in CRM. The Contract Accountholds 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 collationContract Accounts are used to support group-billing arrangements. Collective ContractAccounts will be utilised when the parent Business Partner or the individual Business Partnerwith multiple Sites, wishes to pay for all Sites as a group. The collative Contract Accountwill be required where the parent Business Partner receives a summary statement for all oftheir Sites but the individual Sites continue to pay for their individual invoices. The collectiveand 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 theBusiness Partner and referenced in the Business Agreement. By default the BusinessPartner’s primary address will be referenced in the Business Agreement. However, where thebilling address for the site is one of the secondary addresses of the Business Partner, thisaddress will be referenced.

The payment method and payment terms for the account are included in the BusinessAgreement. The payment method can only be direct debit or blank. Where the paymentmethod is set to direct debit, the Business Agreement must also include a reference to one ofthe bank accounts contained in the Business Partner. The payment terms set in the BusinessAgreement must be equivalent to the payment terms included in the terms and condition ofthe CRM contract.


of 79

A default dunning procedure will be set based on whether the Business Partner is an I&Ccustomer or a SME customer.

The Business Agreement will also contain any alternative billing recipients, alternativepayers, alternative dunning recipients and alternative correspondence recipients. A separateBusiness Partner of the type organisation will be created as part of the Business Partnermigration for each of these alternates.

Business locks will also be set as part of the Contract Account load. Only dunning locks willbe 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 businessagreements will be impacted to achieve the single customer view during subsequentmigrations 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 loadobject 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 organisationhave been loaded. The collective and collation Contract Accounts must be loaded before thestandard Contract Accounts.


The standard SAP replication program BUAG_MAIN will be utilised to replicate the ContractAccounts 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 BusinessPartners. The collective and collation Contract Accounts must be replicated before thestandard Contract Accounts.

The business locks are not resident in CRM. Therefore, they will not be included in thereplication from ISU to CRM.


The following are the outstanding issues in relation to the Business Agreement / ContractAccount:

As outlined in the business partner relationship section contacts cannot be maintainedat contract account level. Some of the legacy system contacts relate to only one of thecustomer’s account.. A change request will be raised if this is required.


of 79

3.5 Connection Object

The ISU Connection Object typically represents a building, but can also be property or facilitysuch as a construction site or streetlight. The Connection Object is represented in CRM as acomponent of an Installation Base (IBASE).

3.5.1 Requirements

The Connection Object contains the customer’s view of the site address. The ConnectionObject 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 thePremise;

There will be a one to one relationship between the Connection Object / Premise andInstallation 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 specificcherished information and will therefore not go through QAS Batch for PAF validating. Theenhanced address from pH Group will be then be transferred to the staging area and utilised inthe upload.

The I&C Customer’s addresses will be sourced from TMS no QAS validation will beperformed on these addresses.



The Data Migration Workbench will be utilised to load the Connection Object. Standard loadobject 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 inCRM. The Installation and DPOD correspond to the IBASE components in CRM. Thereplication to CRM will therefore not occur until after all of the objects (Connection, Premiseand 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. theDPOD 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.


of 79



3.6 Premise

The ISU Premise is a unit that is supplied with energy, such as an apartment or Factory. ThePremise is allocated to a Connection Object and the address of that Connection Object. Therecan be a one to many relationship between the Connection Object and the Premise. At BGBthere 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. Asper the Connection Object, the Premise will only be created for Sites that have live supplypoints.

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 thePremise;

There will be a one to one relationship between the Connection Object / Premise andInstallation and Deregulation POD. There will therefore be some ConnectionObjects / Premises set up with duplicate address, if there is a site with multiple supplypoints.

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 objectPREMISE will be utilised. No enhancements to this object will be required.

The Premise must be loaded after the Connection Object is successfully loaded.


The Connection Object and the Premise together make up the site layer of the IBASE inCRM. The Installation and DPOD correspond to the IBASE components in CRM. Thereplication to CRM will therefore not occur until after all of the objects 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


of 79

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.



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. Itgroups together the Devices, Registers, (Rate Categories) and Installation Facts. It is the linkbetween the technical Master Data and the business Master Data.

Installation Facts are attributes of an Installation, used to hold pricing information (used inBilling) 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 pointinformation such as confirmation reference, confirmation effective date. The deregulationPOD is represented in CRM as an IBASE. The CRM deregulation POD IBASE is allocatedto the CRM Connection Object IBASE.

3.7.1 Requirements

The Installation and DPOD represent the supply point. Only supply points currently inBGB’s ownership will be migrated. Sites that are mid registration or mid withdrawal will notbe migrated. After the site is registration is complete, the Installation and DPOD will bemigrated manually. To reduce the volumes of manual migration, the initiation of theregistrations in the legacy systems, just prior to migration, could be delayed until postmigration. For those Sites mid withdrawal where an objection is upheld, a manual migrationwill also be required.

Sites that have been isolated and are pending a voluntary withdrawal should be withdrawn inthe 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 startinguntil after migration. The voluntary withdrawal or re-registration process will then beinitiated in SAP.

During the creation of the Supply points in SAP, a need to reference the ConfirmationReference Number taken from the legacy or Xoserve extract. Using the ConfirmationReference number, the supply points will be identified and any accounts where the supplypoints exist across accounts and systems will be excluded

Installation

The Installation contains information relevant for billing and invoicing and the industrysupply point information including:


of 79

Rate Category – the Rate Category will be derived from the product. The BillingTeam has provided the translation logic. The Rate Category will be set based on theproduct at the site as of the last bill. Where there has been a product change sincethe 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 thecustomer currently associated with the site.

Temperature Area – the Temperature Area determines the profile to be used forestimation. The Temperature Area will be determined based on the end usercategory obtained from legacy and the Temperature Area table in SAP. TheTemperature Area table in SAP will be downloaded to the staging area and thedetermination 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 thisinformation.

MRU – the Meter Reading Unit will be set to a default MRU as part of theInstallation migration. The correct MRU to be assigned will be allocated as part ofthe Move-In migration. Refer to section 3.14 Move-In and Contract Creation forfurther 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 referencefor the site when it was registered in legacy, i.e. the confirmation reference numberobtained when the site was first registered or re-registered. Therefore, only oneconfirmation reference will be migrated to the DPOD. The start date of thisconfirmation 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 bebilling 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 fornon 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 ofmigration.

Tax related Facts including - CCL Exemption Percentage, domestic consumptionpercentage, commercial consumption percentage, exemption percentage for VATcalculations. This Fact will contain the different values since the last bill date. Ifthere has been a change since the last bill date then there will be more then one-timeslice.


of 79

Tariff based prices and CCL rates will be maintained manually as part of the system set upactivities. 12 months of tariff prices will be maintained. This is on the basis that there willonly 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 ofthe Installation was obtained from the flows. This information now needs to beextracted from a combination or legacy systems sources and industry provided filesunder ETL approach.



The Data Migration Workbench will be utilised to load the Installation object. Standard loadobject INSTLN will be utilised. The custom fields in the DPOD will be migrated utilising theevent functionality of migration workbench as part of the Installation migration. The sitecontacts contained in a custom table in ISU will be loaded utilising the event functionality ofmigration workbench as part of the Installation load, refer to section 3.3 Site Contacts forfurther details.

The correct MRU will be allocated as part of the Move-In process. A dummy MRU will beallocated 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 providersrelevant to the Grids also will be part of this manual upload


of 79


The Connection Object and the Premise together make up the site layer of the IBASE inCRM. The Installation and DPOD correspond to the IBASE components in CRM. Thereplication to CRM will therefore not occur until after all of the objects 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. theDPOD 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.

Some of the information contained in the Installation, Installation Facts and DPOD will beutilised to populate the CRM contract. The details of this replication will be discussed insection 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-registrationapproach was the industry registration flows. This data will now be sourced from acombination of legacy system sources and industry provided files. The exact sourceof each field is as yet not finalised and will be agreed during the Detailed Designphase. The current view is that the following information will be obtained from theindustry (note that some of this information will be populated o the objects discussedbelow):

o Must Read Dateo Collar Fitted Indicatoro Collar Status Codeo Gas Nomination Type Codeo Meter Access Instructionso Last Inspection Dateo MRA Referenceo NDM EZCo Supply Point Categoryo Shipper Referenceo 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 requireadditional MRUs than have been configured than they will only be able to beimplemented 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 ourcontext

The POD Link Table maintains the relationship between the supply point (deregulation pointof delivery) and the meter point (technical point of delivery). For each relationship itmaintains the validity period of the relationship. That is the start date of the relationship is


of 79

equivalent the confirmation effective date and the end date is set on losing the site and will beequal to the ceased responsibility date.

The Meter Point AQ is a custom table used to maintain annual quantity history for meterpoints.

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’sownership.

MPRNS that relate to sub meters that are not in BGB’s ownership will be created manuallypost migration of the related prime meters. MPRNS for sub meters within BGBs ownershipwill 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 industryfile 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 areoutlined below.

POD Link TableOnly supply points and meter points that are currently in BGB’s ownership will be loadedinto SAP. As such the POD link table will be loaded with the relationships for Sites that arecurrently live.

The start date will be equal to the date the supply point was confirmed in the legacysystems.

As the only relationships for live Sites will be loaded the end date will not bepopulated.

The serial number should be set to a default of 1, as there will only be onecombination of DPOD and TPOD loaded.

Meter Point AQ TableFor every MPRN created an entry will be made in the Meter Point AQ table. This table willcontain 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.


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 comparedBSMART. 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 willbe utilised. The decision will be dependent on the AQ that will provide the mostaccurate 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 PODwill 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 andDevice Installation migrations.


The TPOD is not managed a separate object in SAP CRM. Instead, it is maintained in acustom tab in the CRM contract line item. The relationship between the contract, the IBASEand the TPOD is stored in a custom table in CRM. There is no standard SAP replication ofthe TPOD to the contract and the custom table. The approach for replicating these details willbe discussed in section 3.14 Move-In and Contract Creation.

The POD link relationships are only resident in ISU. Therefore, no replication to CRM isrequired.

The customer’s view of the MPRNS AQ and the industry AQ at the point of sale is containedin the CRM contract. For migration these AQ’s are not necessarily the same as the AQ thatwill be stored in the Meter Point AQ table. As outlined above the AQ in this table will be the


of 79

industry AQ at the point of migration. Therefore, there will be no replication of theinformation 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 CRMcontract industry AQ will be equal to the point of migration AQ and the customer AQ will notbe 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 isassumed 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 thisinformation will be sourced from the industry.

3.9 Devices

The Device corresponds to a piece of equipment installed. A separate Device will bemaintained 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 becreated and installed in SAP.

If a meter exchange has been performed in legacy, since the last bill, then these will beprocessed manually in SAP after the site is set up. It is anticipated that the volume of meterexchanges from the last bill in legacy to the time of migration will be low. Therefore, limitedmanual work should result. If the business wish to reduce the number of manual meterexchanges to be performed in SAP after ‘go live’ then prior to migration the accounts couldbe billed in legacy at the time of meter exchange. This will facilitate migration of the latestDevice details into SAP.

Both the prime and sub meters will be created as separate Devices, where both are in BGB’sownership. Sub meters that are not owned by BGB will not be part of the automatedmigration 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


of 79

dials. Device class and characteristics functionality will be used to store some additionalDevice attributes.

3.9.2 Data Cleaning

The cleaning of the asset information is essential for the success of the ETL migration. Someof the key areas that will require cleaning include:

Confirmation that the right asset for the supply point and meter point is allocated inlegacy;

Reconciliation of the serial number and meter model number assigned to the meter inlegacy with industry information;

Validation of the details assigned to the meter in legacy including such information asthe metric imperial indicators, register Factors, and the number of dials;

Confirmation that the meter model code is a valid code based on Market DomainData; 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 objectDEVICE will be utilised. The Device characteristic information also will be loaded using thesame object.

Device Master Data can be loaded independently. However, the Device should be loadedbefore 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 currentassumption is that this information will be obtained from the industry as it is viewedas 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 abouthow SAP calculates consumption from reads loaded against the Device and which reads willbe used for billing.


of 79

3.10.1 Requirements

Meters created as Devices in SAP will be installed onto their relevant Installation. Meters andconverters will be installed by a process of full installation. Data loggers will be onlytechnically installed. Data logger installation will be performed as part of the TPODmigration 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 thisdate will not be loaded. The last bill read will be used as the Installation read. This read willthen be utilised by the Move-In process as the Move-In read. The last billed read can be basedon the estimated read or the actual read

As outlined in section 3.9 Devices, meter exchanges since the last bill date will be managedmanually. The Device will be manually created in SAP and manually installed.

The installation process also populates data relevant for billing including periodicconsumption (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 outlinedin sections 3.9.2 Device Data Cleaning.



The Data Migration Workbench will be utilised to fully install the meters and convertersDevices. Standard load object INST_MGMT will be utilised. The data logger devices willonly require technical installation. Data Migration Workbench will be utilised to technicallyinstall the data loggers. Standard load object TECHINST will be utilised.

The Devices Installation will be performed after the Devices and Installations have beenmigrated.


No replication to CRM is required.



The current scope is that no read history will be migrated. Only the read on the lastbill will be migrated. This will mean that reads since the last read date would not bemigrated. 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 dateand the sites read window, meter read requests may or may not have been generated


of 79

from legacy. An interim process will need to be developed to support these initialreads. The business are currently investigating how this can be managed in SAPand with the read agencies. The document assumes that no additional data or readswill be required. If changes are required to the current meter read request or receiptinterfaces a change request will be required.

3.11 Register Relationships

Register relationships are SAP relationships created between Devices. These relationshipsenable 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 readingrelationships will be set up automatically. The prime and subs relationships will beestablished 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. thelast bill date in legacy.

Where meter exchanges have occurred since the last bill date, the meter exchange will beprocessed manually in SAP. Similarly, register relationships between these Devices will becreated manually.


No specific data cleansing requirements have been identified.



The Data Migration Workbench will be utilised to establish the meter register and convertersrelationships. Standard load object REGRELSHIP will be utilised.

The register relationships will be migrated after the Devices have been migrated.




of 79



As specified above Register Relationship will be established between the MeterRegister and Converted Register of the Converter. This relationship ensures that theconsumption 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. Thisrequired is under discussion with the business. Discussions are currently underwaywith 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) providedfor a supply point or meter point. Beacon will need to maintain records of the Gas transportersfor 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 Partnerswill be created as organisation Business Partner types and will have roles of vendor. TheseBusiness Partners will then be created as service providers in ISU. The creation of theBusiness Partners and the set up of service providers in ISU will be performed manually aspart of the system set up.

The Contract References between the service providers and BGB will be set up as ‘ServiceProvider Agreements’ in SAP. This is currently limited to MAM service and will be donemanually as part of the system set up.

Three types of service providers will be appointed:

1. Gas transporters2. Meter Asset Managers3. Meter Reading Agencies

Gas Transporters

The Gas Transporters will be appointed at the deregulation Pod for every supply point. EitherXoserve 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 oran 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 determinedmanually.

IGT sites were previously excluded from the Loss and Re-registration migration. These sitesand 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.


of 79

Meter Asset Managers

The MAM will be appointed at the technical POD for all meter points. The MAM that iscurrently 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 9Supplier Id Changes for further details on this process.

The start date for the appointment will be equal to the new appointment date after the supplierid change. Note that this will mean that the MAM is not appointed to the MPR for the wholeperiod 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 theTPOD will be utilised to derive the MRA for the correcting postcode regions contained incustom table in SAP.

This varies from the business as usual process for MRA selection and appointment. Thereason for the variance is to increase the efficiency of the data load. It is not anticipated thatthis will have an impact on the MRA selection: The details of the variances are outlinedbelow:

In future business as usual processes the read frequency is used in conjunction withthe postcode to derive the MRA. Currently in legacy the same MRA is appointedwhether he site is monthly read or quarterly read.

In future BAU the Connection Object / supply point postcode will be utilised toderive the MRA. In legacy there are few variance between the Connection Objectpostcode and the TPOD postcode. It is also unlikely that these postcodes will fall intodifferent 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 canbe identified. This would be required to correctly carry out supplier id change in the stagingarea. Along with this, it would be required to cleanse data about gas act ownership for meterpoints in BGB’s portfolio as this could impact future MAM appointment.



The Data Migration Workbench will be utilised to appoint the Gas Transporters and theMAM. Standard load object PODSERVICE will be utilised. Gas Transporters will beappointed using events at the time of uploading Installations and de-reg PODs.


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. TheMAM 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 meterpoints. This address is considered a more reliable address than the industry address held onthe TPOD. This address if present will be used in place of the TPOD address and sent to themeter reading agencies.

3.13.1 Requirements

Only a small percentage of the meter points will also have a MAQ3 address. The table willcontain the MPRN reference and the address details. The address will be loaded as it ismaintained 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. Themigration can occur independently to the other migrations.


of 79





3.14 Move-In and Contract CreationThe Move-In process in ISU generates the ISU contract and the link between the customerand 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 tabon the contract line item.

3.14.1 Requirements

The Move-In will be performed to link every active supply point to the correct businesspartner and contract account. The Move-In date will be equal to the date the customer waslast billed in legacy plus one day.

The Move-In read will be equal to the device installation read. As outlined above this readwill be equal to the last billing read in legacy.

Customers that have not been billed for an extended period will not be migrated. Datacleaning of these sites is required before migration can occur. It is recommended thataccounts not billed for more then 2 months for monthly billed accounts and 6 months forquarterly billed accounts will not be migrated.

The contract in CRM will be created based on the information in ISU. The contract will thenbe supplemented with additional information that is not contained in ISU. Some of the keydetails included in the contract area as follows:

The contract line item equates to the ISU contract and will therefore include thesupply point (IBASE);

The contract start date will be equal to the Move-In date. The planned contract startdate will be equal to the actual contract start date in legacy. The planned contract enddate will be equal to the planned end date in legacy. TGB accounts are not related to acontract and therefore will not have a contract start and end date. For TGB accountsthe CRM contract planned start date will be equal to the move in date in legacy andthe planned end will be set to a default future date. Where the Move-In date has beenarchived 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 theindustries view of the AQ at the point of sale. As there is no related contractinformation 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;


of 79

Product including the configurable attributes of the product and prices will be basedon 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 inlegacy. TGB customers that have multiple sites will be created in different contract. TGBsites are managed separately and do not have one contract for all sites. In addition, the termsand 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 productsthat are applicable before the termination. The contract termination actions will then betriggered manually after migration. The details of the termination including the terminationreason 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 bemigrated with the details as of the last billing date. Further analysis is required to determinehow 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 Contractswill be impacted to achieve the single customer view during subsequent migrations afterTGB.


The data cleaning requirements of the contract attributes will be consistent with therequirements outlined for the Loss and Re-registration approach. The additional data cleaningrequirements include:

Customers who have not been billed for an extended period must be billed to their lastbilling date before migration.


3.14.3.1 Load ApproachThe 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 onmost 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 populatedvia the replication. The standard BAPI Contract Change will be utilised. The following arethe key groups that will be updated via this BAPI:

Partner functions at header and line item


of 79

Custom fields at head and line item (This will also include the details of the meterpoint 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 replicationwill be parallel requests with multiple queues. Customisation of this object will be required tosupport 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), weare required to run program ECRM_GENERATE_EVERH. This program populatesEVERH 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 requireconfiguration of service types equal to number of products and population of this in theinstallation. There are 80 products and therefore 80 service types would need to beconfigured. This is redundant configuration not required for business as usual. It hastherefore been decided that it will be more efficient to use a custom approach. Modificationof ECRM_GENERATE_EVERH will update EVERH with the product id based on theinformation 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 linkthem into one contract with multiple line items.


of 79

The other fields will be populated via updating the CRM contract directly.

Contract Process Type Determination

The CRM contract type for BGB will be determined based on the customer type, i.e. differentcontract types will be utilised for SME and I&C. The standard program allows for differentcontract types based on the division, e.g. gas or electricity. A custom development is requiredto support the determination of the contract type by customer type.

Several options are currently being considered to determine the most appropriate means ofdetermining the contract type.


The following outstanding issues have been identified in relation to the Move-In load andcontract replication:

Currently there are performance issues with contracts with a large number of lineitems. To resolve these performance issues a redesign of the contracts may berequired. This document is based on the current design approach. If a change ismade to the management of multiple line item contracts then the data migrationapproach of this object will require change. This impact will be managed through therelevant Multiple Line Item change request.

Further analysis of the contract replication is required to finalise the developmentrequirements. This analysis will continue in the design phase.

The standard replication program does not support the migration of contracts withmultiple line items. An allowance has been made for customisation of the replicationobject to support the creation of contracts with multiple line items.

The approach for managing contracts that are mid renewal will need to be defined. Ithas been assumed that this will be managed manually by the business and that therewill be no migration of renewal details.

Contracts that have been terminated in legacy since the last bill will require manualupdate in SAP of the termination. An interim process will need to be developed bythe business outlining the manual migration of the termination details. Confirmationof the number of contracts that are mid termination will be required to ensure that themanual update can be supported.

A new requirement has been identified to have contracts in the name of the Brokerinstead of the individual customers. This requirement is not currently supported bythe data model. A change request will be raised if this requirement is to be includedin scope.

3.15 Finance related migration

As specified in the section 1.2, the scope and the migration approach for the migration offinancial information will not change from that currently in ETL2 (Loss & Re-registrationapproach). The trigger for the ETL2 load will no longer be the final billing of the customer inlegacy. Instead, the financial information will be loaded in bulk for all customers that havebeen successfully migrated and have their accounts in a live and billable state. Open financialinformation will only be loaded for accounts that are currently live in the legacy systems.


of 79

Following objects will be migrated

Open Items Payments Instalment Plans Payment Schemes Creditworthiness

The document Beacon Migration GL Account Approach v04 outlines the approach and thebusiness decisions made for the above objects.Please refer Appendix C- Attachments, for additional information

Some of the key rules that have been agreed to manage exceptions are as follows:

The approach for performing the update of the banks with the new account referencesfor all customers on direct debit needs to be finalised. The bank requires 14 daysfrom the time of update until the first claim is made. For the purpose of migration theclaim of the first direct debit will not be amended to allow for this 14 days period.The direct debit due dates will be in accordance with the legacy system due dates.The interaction with the banks to set p the new account details will be managedoutside of SAP.

There are currently approximately 3 customers that have made advance paymentsprior to the introduction of VAT. These customers therefore will not be eligible topay VAT on their open items or further invoices while these invoices are below theadvance payment amount. The open items for these customers will be createdmanually in SAP. No special migration rules will therefore be required to cater forthese customers.

The business rules agreed by the business for payment schemes allows for onlymonthly direct debit payment schemes. In addition, payment schemes will only becreated for customers will a quarterly bill frequency. There are currently a fewthousand customers in legacy systems that do not compile with these business rules.These accounts will be manually cleaned before migration to remove the customerfrom payment schemes.


Open items relating to finalised accounts will not be migrated. The business must manage thecollection of these open items either in he legacy system or via an alternative manualapproach.A clean up of the open items will be required to ensure that:

Write offs are performed before migration; Open items relating to cancelled / r-versed bills are appropriately closed and matched

against other items.

The payment scheme will need to be cleaned to ensure that payment schemes exist thatcomplies with the business rules.


of 79



The Data Migration Workbench will be utilised to load the finance details. The financeobjects will be loaded after the accounts and sites are fully set up in a billable state. The orderof the finance migrations will be as follows:

1. Open items2. Instalment Plans3. Payments4. Payment Schemes

The creditworthiness (subject to business approval), will be loaded using a custom BAPI.


The finance details are no resident in CRM. Therefore there will be no replication to CRM.



The approach for performing the update of the banks with the new account referencesfor all customers on direct debit needs to be finalised by the business. The requiredcustomer communication is also to be determined.

The following issues remain in relation to the migration of TGB open items:o TGB is not an open item managed system therefore debit and credit line items

will need to be migrated for an account until the balance pf these items isequal to the account balance. TGB archives open items after three years.The design assumption is that a balancing open item will be generated andposted to account for the archived open items.

o Currently five sources of open items have been accounted for in the financialmigration design. However there are potentially 14 other different types ofopen items could contribute to the open balance in TGB. The Business needto made a determination of how this items will be treated.

Credit worthiness score - SAP maintains an internal credit worthiness score. Thisscore is derived from the customer’s payment history, i.e. dunning activities andreturn activities. The Business has a requirement to include a starting position for thiscredit worthiness score. A value will be set for each customer based on theinformation in legacy systems and the business rules outlined below.

Good customers: All customers on a Direct Debit payment plan Or allcustomers with a zero or credit balance Or all customers whose oldestoutstanding debt is less than 28 days old (From the invoice date)

Bad customers: All customers not on a Direct Debit payment plan andwhose oldest outstanding debt is greater than 180 days old (From theinvoice date).

Average customers: All customers not on a Direct Debit payment planand whose oldest outstanding debt is less than 180 days old but greaterthan 28 day old (From the invoice date).


of 79

The impact of this design on the dunning procedures and the follow up of thecustomers post ‘go live’ is to be determined and agreed with the Business prior tofinalising the design.

Open items relating to finalised accounts are not in the scope of migration. Theprocess for managing this debt is to be determined.

The people responsible for the pre migration clean of the financial data, includingwrite off of open items, matching of open items and removal of invalid paymentscheme types are to be determined.


of 79

4 Load Sequencing

Data will be loaded into SAP in a particular order. The order of loading is derived from thedependencies between the migration objects. The sections below explains how Migrationobjects can be grouped to achieve maximum performance considering the dependenciesbetween the objects.

It should be noted that the order specified here is just a starting point and will be revisitedduring the testing phases of Data Migration to optimise the performance.

Load Sequence 1

As shown in figure, Bank Master Data, Register Groups and GL codes will be uploaded toSAP to support the other master and transactional data. These datasets will be loaded withouthaving any dependencies just before the migration of critical objects listed in the next setsstarts. There are no dependencies to load these objects in SAP

Load Sequence 2

1. Site Contact Persons will be loaded into ISU.2. Customers will be loaded once the site contacts are finished loading.3. This will be followed by the replication of customers into CRM.4. When the replication is underway, the Contract Accounts will be loaded in ISU.

CRM ISU

BanksLoad BankMaster Data

Register GroupsLoad RegisterGroups

GL AccountsLoad GLAccounts

MAQ3Load MAQ 3Address

CRM ISU

BanksLoad BankMaster Data

Register GroupsLoad RegisterGroups

GL AccountsLoad GLAccounts

MAQ3Load MAQ 3Address

No Replication

CRM ISUCRM ISU

CustomersSold To PartyBill ToPayer To

Site Contact

Site ContactPerson Load

Replicate Customer

Contract AccountIndividual CACollective CACollative CA

Partner Change

BP Change

* SD, CGABSMigrations

CustomersSold To PartyBill To PartyPayer To

Site Contact


Replicate Customer


Replicate CA as BA

Partner Change

BP Change

* SD, CGABSMigrations

CustomersSold To PartyCustomersMKK Contract Partner

Site Contact


Site Contact

Site Contact Person


Business AgreementIndividual BACollective BACollative BA

Replicate CustomerSite Contact person


of 79

Load Sequence 3

5. Connection object will be loaded in ISU in parallel to Contract Account load6. Premise will be loaded once the Connection object migration is complete7. Installation along with DPOD, Site Contacts, GT assignments and Facts will be loaded

once the Premise is loaded in ISU8. The replication of IBASE to CRM will start once the above three objects are loaded in

ISU9. In CRM, IBASE change program will run to Update the site contacts at DPOD level

Load Sequence 4

10. When the replication of IBASE components to CRM is underway, the Device related datawould be migrated in ISU. Alternatively, it is proposed to load the Device Master dataalong with Load Set 1 as this is relatively static information. This can be done only if theDevice exchanges / removals are stopped during the cutover window

11. Device Installations will be set up in ISU once the Devices are loaded this activity alsodepends on the completion of the Installations load. This will be followed by a small loadof Technical Installation for the Data Loggers

12. Technical POD along with Device Allocations, MRA update and POD Link update willbe uploaded

13. Register Relationships will be loaded.

CRM ISUCRM ISU

Device

Load AssetMaster data

Technical PODDevice Alloc,PODLink, AQ & MRAUpload

Device InstallationFullInstallation

REG REL

RegisterRelationship

Tech InstallationData LoggerInstallation

Device


Device Alloc,PODLink, AQ & MRAUpload,MAM Appointment


REG REL



No ReplicationSUN Process

Trigger SUN file

Staging Area

MAM Process

OANGE ApptONAGE De-APPT

SUN Process

Trigger SUN file

Staging Area

MAM Process


CRM ISUCRM ISU

Device


Technical PODDevice Alloc,PODLink, AQ & MRAUpload


REG REL



Device


Device Alloc,PODLink, AQ & MRAUpload,MAM Appointment


REG REL



No ReplicationSUN Process

Trigger SUN file

Staging Area

MAM Process


SUN Process

Trigger SUN file

Staging Area

MAM Process


CRM ISUCRM ISU

Connection Object

ConnectionObject

Premise

Premise Load

InstallationDPOD, FactsGT & Site ContactUpdate

Replicate IBASEIBASE Change

Update Sitecontacts inDPOD

Connection Object

ConnectionObject

Premise

Premise Load

DPOD, FactsGT & Site ContactUpdate

Replicate IBASEIBASE

Connection Object &DPOD link

IBASE ChangeUpdate Sitecontacts inDPOD

IBASE ChangeUpdate Sitecontacts inDPOD


of 79

Load Sequence 5

14. ISU contract (Move-In) will be uploaded in ISU15. ECRM_GENERATE_EVERH program will be run in ISU soon after Move-In loaded16. ISU- CRM linking program (EVERH update) will be run17. Replication of the ISU contracts into CRM will start once above three activities are over.18. A batch program will run in CRM to update the CRM contracts line items. Updating the

contracts with multi line items is an issue.19. SUN file flow will be triggered in the staging area to initiate the Supplier ID change. This

activity will happen during the initial extraction and exclusion of the data independent ofother loads

20. Once this activity is complete, MAM will be appointed at the MPRN using the PODSERVICE Object

21. BP Contact and BP Relationship will be loaded once all the critical objects are completed22. Replication of the BP Contacts and Relationships will be replicated to CRM.

MOVE IN

MOVE InMRU Update

Run EVERHprogram

EVERH Update

ISU-CRMLinkage Update

Create ContractCRM ServiceContract

MOVE IN

MOVE InMRU Update

ECRM_GEN_EVERH

Run EVERHprogram

EVERH Update

ISU-CRMLinkage UpdateContract

CRM ISUCRM ISU

Change ContractChange Contract

Updation ofAdditional attributes

Replicate Move INReplicate Move IN

BP ContactBrokers, ContactPersons,Employees

BP Relationship

PartnerRelationships

Replicate BP ContactBP ContactBrokers, ContactPersons,Employees

BP Relationship


Replicate BP ContactBP ContactBrokers, ContactPersons,Employees

BP Relationship


BP ContactBrokers, ContactPersons,Employees

BP Relationship


Replicate BP ContactReplicate BP Relationships


of 79

Load Sequence 6 – ETL2

23. All financial related transactional data will be migrated at the end of migration cycle. Thisincludes the Payment schemes, Instalment Plans, Open Items and Payments

The order shown above will be followed during the migration. Objects that are not shown inthis diagram, but are within scope, are secondary objects and hence not included.

CRM ISU

CRM ISU

No Replication

OpenItems

Load OpenItems

PaymentsLoadPayments

InstalmentPlansInstalmentPlans

PaymentSchemesLoad PaymentSchemes

Load OpenItems

PaymentsLoadPayments

InstalmentPlansInstalmentPlans

Load PaymentSchemes

CreditWorthinessCreditWorthiness


of 79

5 Performance Targets

The performance targets of the SAP Upload are to complete the migration event including thereconciliation over the weekend. The target will be defined with clarity once the initial trialloads are done during the Component and ETL Testing. Some details on performance tuningof the SAP upload are covered below. Development of the cutover plan will assist inclarification of the time allowed for the technical migration.

5.1 Performance optimisation in ISU

The following measures will be taken to optimise the performance of the SAP upload and toensure that the migration of the data will be completed within the weekend of the cutover. .

1. Pre-migration of objects: Some of the static Master Data will be migrated before themajority of the data (the weekend before going live, for example). Few objects whichcan fall under this category are given below

a. GL Master data,

b. Bank data

c. Register Groups

d. Device Master Data - This is a key object, which can be created beforehand,provided no removals/exchanges happen during the period.

.2. Parallel load / Replication: Some of the objects in the Technical Master and

Business Master categories will be run in parallel until Device Installation and Move-In are reached. The Device Installation object has a very slow throughput and hencesome effort will be required to reduce the runtime of this object before reaching thispoint. Section 4 describes the sequence of the migration objects for performanceoptimisation.

3. Size of Import files: The SAP upload will split the import file for a Business Objectinto multiple smaller files to reduce the demands on system resources. SAP bestpractices will be used to arrive at optimum lot size.

4. Restart Options: During the data upload in SAP, if, due to the system problems, thejob terminates before reaching the end of the file, it can be restarted. Key and StatusManagement (KSM) functionality of the migration workbench prevents data objectsthat have already been imported from being loaded again. For this, every data objectin the file must have a legacy system key (or Old key), which is checked against theKSM during import. When this happens, the ‘Restart’ option of the workbench willbe used, which start from the point where the job is terminated. An operationaldocument detailing how the re-start is triggered & executed will be provided as partof the detailed design.

The appropriate operational documentation for the extract and transformation processes willbe defined during the subsequent detailed design.


of 79

There are number of performance tuning measures which are available as part of 'IS Migrationperformance Analysis and Improvement version 1.6'. These performance improvementtechniques will be evaluated and applied during the load testing.

5.2 Performance optimisation in CRM Replication

Some of the performance monitoring options available for CRM replication and Migration aregiven below. These will be tested during the component testing cycles of the Migration

1. Parallelisation of queues2. Usage of Requests instead of Initial Loads3. Apply appropriate filters4. Adjust block size5. Deactivate change documents6. Restart options for failed loads using the keys7. Transfer of messages from BW queue should be stopped

Middleware performance during the ISU to CRM replication

There are four methods that can be utilised to replicate objects between CRM and ISU.

Delta downloads: The replication will proceed to CRM at the same time as the objectis being loaded into ISU. (Transaction R3AC4 in CRM). This method hasperformance issues and is only suitable for small volumes of data.

Initial loads: This method downloads data from ISU to CRM once data is migrated toISU. (Transaction R3AS) This method is the standard method and while it is fasterthan the delta download method still has performance issues.

Parallel requests with multiple queues: A request is a set of data that can bedetermined by the user to be loaded to CRM. This method allows for several requeststo be executed at the same time and each request can be run with multiple queues.(Transaction R 3AR2, R3AR4).

After analysis of these methods it has been decided that the Parallel requests with multiplequeues method will be utilised. This approach utilises all of the capacity of the database andapplication servers and will therefore enable the best performance of the above method.

5.3 Performance optimisation in the staging area

Some of the performance optimisation techniques, which will be adopted in the Staging Areaare given below

1. General

The recommendations and best practices recommended by DataStage to achieve highperformance will be followed for job development. The key aspects used will be –

For maximum performance flat files will be the mode of communicationbetween the staging area and the non core systems


of 79

Wherever possible parallel and native database drivers will be used to acquiredata. ODBC drivers will be used only as the last resort

Data loads into the staging area will be through native parallel “upsert”operations

Scratch Disk / sort / interim storage will be on storage spaces mounted on theSAN and not on NAS

Recommendations for Ascential DataStage development are in the DataStage EE(PX)Best Practices v2.0_final.doc document. Awaiting the updated version of thisdocument will be updated.

Refer the section Appendix C – Attachments for more information

2. Extract Phase (Stage I)

TGBo All data will be acquired in the form of ‘]’ separated flat files. The

data loads for the files will be executed in parallel.o A strategy of breaking down the jobs into small technical

components will be followed. This will enable maximum number ofjobs in parallel.

CGABSo Data from the core CGABS system will be pre-selected during the

extract phase.o It was suggested that a table be created on the legacy system to

maintain the list of customers, contracts, accounts, connection objectsand meters that have to be migrated. This would have enhanceperformance.

File Generation Stage (Stage IV)

o Appropriate indexes will be created to optimise the creation of theseflat files.

6 SAP Configuration and Development Changes

Listed below are the specific settings, which need to be done for the SAP configuration andDevelopment to support the ETL migration

1. Number range settings: As detailed in the section 4 migration of data will start in ISUfollowed by replication to CRM and migration in CRM.

Currently as per BAU, CRM is the lead system and ISU is secondary system. SoInternal Numbering for the objects in CRM and External Numbering for the Objectsin ISU are followed. For ETL, we need to reverse this setting. After migration iscomplete, this will be reversed again. The Internal number in CRM for BAU will startfrom the last number created in the system due to Migration

2. Customisation of BDT events: Specific coding will be done in the user exists of BDTevents related to Business Partner object to move the data from custom fields ofMigration workbench to target structure of the Business Partner Object

3. Middleware settings


of 79

a. Break the link of replication between ISU and CRM systems till theMigration is complete for the relevant objects

b. Stop delta replication. The delta replication between ISU to CRM and Viceversa will be stopped till the migration is complete

c. No Bdocs are created during Migration

4. Configuration for specific Business Partner Roles- With L& R approach, some of theBP Roles such as Broker are not created in ISU. Now with ETL approach, we need tocreate these roles in ISU in addition to CRM through configuration

5. Changes to the Interfaces/Enhancement objects: There is few design changes toimplement the ETL approach of the data migration. Some of theInterfaces/enhancement objects in Metering, which will be modified to are givenbelow.

NRO TRF4 NCIME –NCI Month End Extract NCIMM – NNI Midmonth Extract NCI-INT – NCI Interruption Extract GDFE – Gas Demand Forecasting Engine MET32B - ONAGE(A) – ONAGE Appointment

This is based on assumption that switch documents will not be created through ETL,but TRF process will be changed to align BAU with ETL.

6. Changes related to Performance optimisation – Section 5 describes differentperformance optimisation techniques for Data Migration. As per SAPrecommendations, some tables settings related to migration objects need to be alteredto improve performance. This will be undertaken during the performance testingcycle of the Migration

7 Deletion/Change Programs

Data loading in SAP will happen as per the sequence specified in the section 4 LoadSequencing. While loading the data object by object in SAP, there could be situations wherethe data is not loaded correctly or need some update. To deal with such situations, change/deletion programs will be prepared. However, the use of such programs will be restricted inthe production client where no change/deletion of the loaded data is expected normally due tostringent tests carried out in the prior test stages/dress rehearsals

The details and exact requirement of such programs is currently not known. These programswill be built as and when required during the build / test stages and will be used in all thephases of Data Migration

8 Data Sources

The main source of data for migration is the three gas billing systems, TGB, Oxford Systemsand CGABS. The tender management system will also be a key system for customerinformation. Several supporting systems will also be the source of some key migration data.The details of these systems are outlined below:


of 79

1. TGB (Tariff Gas Billing) - This billing system only supports customers on tariff basedpricing. Customers on this billing engine have only gas supplied to them. It is expectedthat the number of customers to be migrated from this system would be of the order of300,000. The data is stored in eight separate database images. TGB is a Fujitsu IDMSMainframe based system. IDMS is a network hierarchical database and can be accessedonly through its native interface. All communication to this system is through flat files.Ancillary systems supporting this application are a) BSMART and b) DSPA. Both thesesystems hold gas industry data. Note that BSMART and DSPA are not in scope as sourcesof data.

2. CGABS (Contracts Gas Billing System) - Two primary applications constitute this system- a) CGABS - the billing engine and b) SPA - the supply point administration system.These systems are on Oracle 7.1 and have a custom written DEC VMS front end. It isexpected that the volume of customers to be migrated from the CGABS/SPA systemcombination would be of the order of 35,000.

3. Oxford Suite - Also known as the Service Desk / Contracts / CODA systems. Threeprimary applications constitute this system. They are a) Service Desk - The sales &customer support application b) CODA - the financials application and c) PSL Shipper -the gas industry flows application. These applications run on MS SQL Server with aVisual Basic front end. Both tariff & contract based pricing is supported on this system.Customers on this application can have both gas and electricity being supplied to them. Itis expected that the number of gas customers to be migrated from this system would be ofthe order of 20,000.

Supporting Systems –

Apart from the above, data will be sourced from the following ancillary data sources tosupport or enhance the quality of data -

1. MAQ3 - Contains information about the gas meters including the meter address. Thisinformation is provided to the Portfolio Administrator. Since this data is updated on aregular basis, its accuracy is likely to be much better than the same data that might bepresent in the main billing systems. No data cleaning is to be performed on this data.

2. e-mail database – BGB maintains a list of legacy customer and account numbers andassociated e-mail addressed on a MS-Access database. E-mail addresses will be extractedfrom this system and migrated with the appropriate business partners.

3. TMS (Tender Management System) - TMS contains the single view, customer, contractand contract related information for all corporate customers. This information is sourcedfrom TMS and not the legacy source systems (Oxford Suite, CGABS) since they havesystem constraints and data gaps. This data either does not exist in the legacy systems oris not accurate. The information sourced from TMS is -

1. Single View Information2. Customer / Organisation Information3. Contract Information4. Commission Information5. Organisation Contact Information6. Sales Manager Information7. Account Manager Information8. Account Executive Information9. Retention Manager Information


of 79

The billing, pricing and financial transaction information for all corporate customerswill be picked up from the legacy systems.

No data transformation rules are required on the TMS data.

4. Industry Data Extracts – Extracts will be acquired from the gas industry for critical gasindustry information that would include asset information. The industry marketparticipants involved are the Gas Transporters and the Meter Asset Managers. The GasTransporters are XoServe and the Independent Gas Transporters (IGT’s). The MeterAsset Managers are National Grid Metering (NGM) and the Independent MAM’s(IMAM). Where industry data is to be the data source it is assumed that it is accurate andno cleaning is required. The industry data may also be used as a means of data cleaningor confirming the accuracy of legacy data that is to be used as the source data.

5. pH Group – Data Extracts from pH Group provide single view consolidation informationfor the SME/Commercial customers. pH Group also provides the following dataenhancements –

i. Address enhancements when the address in legacy does not result in a successfulretrieval from QAS

ii. SIC Codesiii. Legal Entityiv. Company Registration Number

6. Employees Data Extract - BGB provided list of employees and employee associatedinformation. This data is provided in a flat file. No data cleaning or transformations are tobe performed on this data.

7. Consultants Data Extract - BGB provided list of consultants and consultant associateddata that are to be migrated into Beacon. This data is provided in a flat file. No datacleaning or transformations are to be performed on this data.

8. Other Systems – Data from other systems is anticipated to be acquired to perform manualdata fixes. The current systems that would be required are –

i. SAM – This database has a repository of all information that is acquired throughcontact with the customer during the contract sale phase. This system will be usedto gather the following information

Interruptible Hours Transport Costs

8.1 Historical Data

No historic information will be migrated as part of the data migration process, althoughhistorical data will be migrated as part of the delivery of Historical Data Store . There will beno read or bill history. The data that is to be loaded via the ETL approach is consistent withthe data that was either loaded or obtained from the industry.

Only the following historical information will be loaded:


of 79

Calorific Value (CV) value – 12 months of CV history will be updated as part of thesystem set up. This is on the assumption that no account will be migrated that has notbeen billed for more then 12 months.

Tariff based pricing history and CCL rates – the tariff based prices and CCL rates willbe migrated for the last 12 months. These will be manually migrated as part of thesystem set up. This is on the assumption that no more then 2 price changes haveoccurred for each tariff.

Site based pricing information – prices since that last bill date will be maintained. Insome cases more than one price will be maintained. Refer to section 3.7 Installationfor further details.

LPA history – LPA file for the previous year i.e. from last October will be processedto enable estimation after the Go – Live. This will be a one time processing of all thedaily LPA files since the previous October – the beginning of the current gas year

Outstanding Issues

At present the scope of the migration does not include the migration of meter readhistory. The only reads that will be migrated will be the last bill read. Reads sincethe last bill date will not be migrated. The same rule will apply for DM sites as well.Legacy systems currently hold only month-end reads for DM sites without dailyreads. Only the last billed month-end read will be migrated to SAP.

9 Supplier Ids and MAM Appointment

The SAP design supports only one supplier id. The Loss and Re-registration approach wasbeing utilised to change the supplier id. The ETL approach will utilise the SUN industry flowto change the supplier ids in mass for GT sites as they are migrated. The SUN process will bemanaged in the migration staging area. The site will be migrated to SAP with the newsupplier id. The final approach for the change of supplier id is yet to be finalised.

The supplier id for IGT sites will also similarly be changed. There is no SUN process forIGTs. Instead a manual approach via emails and faxes will be utilised.

As the supplier ids will change, the MAM will need to be de-appointed for the old supplier idand re-appointed for the new supplier id. This process will be managed in the migrationstaging area. The MAM to be appointed in SAP will be as per the legacy MAM. Noappointment flows will be triggered from SAP. A bulk upload process will be utilised toinform the MAM rather than individually appointing and de-appointing the MAMs. Finalagreement with the MAMs is required in relation to the approach and file layouts.

10 Legacy System Closure

The legacy systems will no longer be closed automatically via the withdrawal process thatwas triggered in the Loss and Re-registration migration approach. Separate programs will beneeded to close down the relevant accounts in the required legacy systems.

The change to an ETL approach means that a full review of the legacy system impacts and theassociated changes to support the migration method is required. These changes can besummarised in the following categories


of 79

1. Marking of accounts so a clear view of what has migrated to Beacon is available toany personnel accessing that record

2. Closure of legacy account3. Suppression of any activity on a migrated account with legacy4. Suppression of any secondary processes with the legacy landscape post migration5. Ensure that all relevant flows of data are redirected from legacy to Beacon post

migration

Some customers will be excluded from the automated migration process based on thebusiness rules defined in section 15 – Appendix A: Data Migration Business Rules. Therewill be no automated delta migration of these customers. Before the legacy systems canbe closed some of these customers and accounts must be manually migrated to SAP. Forexample customers that were mid acquisition during the migration window will bemanually migrated. Customer that were mid withdrawal during the migration windowand have subsequently fully withdrawn will not require manual migration.

To reduce the number of customers requiring manual migration the following activitieswill be undertaken by the business:

A report will be provided to the business containing the customers that would beexcluded based on the exclusion rules. This will allow the business to complete datacleaning to reduce the volume for exclusions.

There is also a plan to investigate which processes can be temporarily suspended untilafter migration. For example, initiation of new acquisitions could be delayed a fewdays prior to migration.

The following systems may all require activity to ensure a seamless migration can occur.

TGB CGABS SPA DSPA BSMART SERVICEDESK ICON SIEBEL

The changes within the BGRE landscape will be managed by the Beacon BIT team to meetthe requirements specified by the Beacon Migration team. These requirements have alreadybeen submitted and are subject to impact analysis.

The changes within the BGB landscape require further progression and it is anticipated thatthe work will be handled by the migration team directly with suppliers, a full list ofrequirements for these is to be produced by 24th March with engagement of the varioussuppliers to follow shortly after. The process for dealing with these suppliers is yet to beestablished.

It is recognised that the code will be given to BGB as sub system tested, however, testenvironments will be required to carry out migration testing end to end as part of the dressrehearsals. These environment requirements should be completed as part of the design phase.


of 79

Currently Business Requirement Specifications have been raised to identify the requiredchanges to Legacy systems to support the migration to Beacon. These changes need to ensurethat post migration further activity cannot be completed on those Legacy accounts that havebeen migrated to SAP and all future activity for the customer is processed within Beacon.

10.1 Requirements to close the Legacy systems

TGB - ensure accounts are 'frozen' on completion of the Beacon migration to prevent anyfurther updated from being actioned on the accounts. The TGB accounts also need to bemarked to clearly state that the account has migrated to Beacon, differentiating these fromJupiter migrated accounts. The preferred proposed option consists of a data fix, which willresult in the appearance of the account being altered to look like a 'finalised' account. Thiswill be triggered on successful completion of the migration. When accounts have migrated afile will be sent to the developers of the system to action the required data fix. The accountwill also be updated with a migration flag, which will result in the account being made read-only. A further update will then be made on the accounts to create a bulk customer contact,stating that the account has migrated to Beacon.

CGABs - ensure accounts are 'frozen' on completion of the Beacon migration to prevent anyfurther updated from being actioned on the accounts. A Business Requirements Specificationhas been raised, the High Level Design is still outstanding. Again the preferred approachwould consist of a data fix triggered by the successful migration of accounts to freeze theaccount and to set migration markers/indicators to visibly identify the account as migrated.

Service Desk - ensure accounts are 'frozen' on completion of the Beacon migration to preventany further updated from being actioned on the accounts. A Business RequirementsSpecification has been raised, the High Level Design is still outstanding. Again the preferredapproach would consist of a data fix to freeze the account and to set migrationmarkers/indicators to visibly identify the account as migrated.

Secondary Processing - ensure that any existing Legacy secondary processes do not prevent orinterfere with the migration of an account or action updates against Legacy accounts postmigration. A Business Requirements Specification has been raised, the High Level Design isstill outstanding. It is proposed that a similar development to that which has been delivered byJupiter is used. This consists of a file splitter that splits files prior to them being loaded intothe various Secondary Processing applications to identify those accounts that have beenmigrated. The migrated accounts are then removed from the files prior to them being loadedin to the SP programs.

ICON - ensure that post migration all flows for migrated accounts are directed to Beacon,regardless of Supplier ID and ensure that the new 'BGB' Supplier ID is recognised andaccepted. This requirement involves the Split Rules Table within ICON being updated via adata fix. The billing system will need to be amended from Legacy to Beacon on successfulmigration of accounts. Once the Supplier ID is changed, ICON will also need new BusinessRules to process flows being received with the BGB Supplier ID.

DSPA - ensure that post migration, the DSPA record is closed to ensure no further action ispossible for that MPR. The preferred option again involves a data fix to amend the recordwithin DSPA to appear as a withdrawn site and to close the record.

SPA - ensure that post migration, the SPA record is closed to ensure no further action ispossible for that MPR. The preferred option again involves a data fix to amend the recordwithin SPA to appear as a withdrawn site and to close the record.


of 79

Siebel - ensure the migration of accounts on TGB are visible via Siebel. This will be achievedby the bulk customer contact within TGB. When contacts are raised within TGB, these are fedup to Siebel and are visible to Siebel users. Once the account has successfully migrated, abulk contact will automatically be raised on TGB.

BSmart - ensure that post migration, the BSmart record is closed to ensure no further action ispossible for that MPR. The preferred option again involves a data fix to amend the recordwithin BSmart to appear as a withdrawn site and to close the record.

CTCS - Customer Transfers System, used to monitor the Shipper Agreed Reads process.Operates on a demand basis for registration and withdrawal process management. There is noportfolio management process in place in CTCS. As such, no action is required on CTCS forthe data fix migration process.

DACs - used to direct metering flows to the correct Meter Asset Manager based ongeographical area and job type. DACS has no internal knowledge of the Gas portfolio andtherefore the migration should have no impact.

HSS - HSS processing precedes the industry flows for Gas and the system is only applicableto new Domestic accounts on new housing estates. HSS has no internal knowledge of the Gasportfolio and therefore the migration should have no impact.

MCS - will not require amending as its function is to count read requests in and out andproduces MI on access rates. It does not hold a view of the portfolio

PVS - PVS has no internal knowledge of the Gas portfolio and therefore the migration shouldhave no impact.

10.2 Splitting of Payments post Go-Live

As specified in the section 3.15, In the case of customer accounts, migration will involve atransfer of any open item amounts for live customers to Beacon.

As billing associated with this debt, and the generation of the invoice would have occurred onthe legacy system, the payment stub will contain the legacy customer account, and bankaccount details. As such, when details of the payment are sent from the bank, there is a needto recognize that the payment belongs to a migrated account, and should be re-directed toBeacon. This is irrespective of the fact that the money has been physically paid into thelegacy system bank account.

All the source systems are affected by this issue, and will require the development of asolution to re-direct payments for the migrated accounts. Payment splitter is the system,which is proposed to mitigate this problem. All the file flows relevant for the payments willbe sent to Payment Director /Payment Splitter, which in turn will split the accounts and sendthem to either Beacon or to Legacy system.

The feed for the Payment Director will be generated from SAP and will be fed back to each ofthe legacy systems. This data will be acquired from SAP through the use of the AscentialDataStage SAP Plugin. The SAP Plugin will invoke the appropriate BAPI’s to retrieve datafrom the appropriate SAP Objects. This data will be merged with the data in the staging areaand then provided as a flat file to the respective legacy systems.


of 79

11 Data Cleansing Requirements

Data cleansing issues will be proactively identified and managed so that failures duringmigration are minimised. The following process will be followed to identify data defects –

The process for identifying data defects is –

1. Identification of the data validation business rules that are applied by SAP during andafter migration. These rules would be

a. Relevant data validation business rules applied by SAPb. The enhanced customised data validations built into the SAP system driven

through Functional Business Requirements

c.

2. Any interdependent data items will be identified so that data integrity issues can beidentified

Once a rule for identifying a data defect has been determined it will be agreed upon how itcan be handled and fixed. Automated data cleansing can be attempted when the defect appearsin predictable patterns. However if the defect cannot be fixed through automated means thenmanual data cleansing will be taken up on legacy systems –

Legacy Data Cleansing

The legacy data issues are identified, reported and cleaned as per the followingprocess –

o Issue Identification – This will be identified by –

Constraint Comparison of SAP and legacy data SAP Validation Business Rules identified Testing Results Feedback

o Issue Reporting – Queries are built and executed using AuditStage. Theconsolidated report provides information

o Cleaning – The data cleaning teams action the reports produced

Data to support the above identification and reporting process is extracted from thelegacy systems or acquired from external vendors on a monthly refresh cycle.

Automated Data Cleaning using the ETL tool

During the ETL transformation process data cleaning transformations will be appliedon the source data to convert the data into a standardized or corrected format based onbusiness rules. This is required so that a few of the commonly occurring data qualityissues can be handled in an automated way without having the need to manuallycleanse them in legacy.

An example of this is to automatically strip away the invalid characters occurring inthe legacy telephone numbers. SAP supports the domain values of A-Z, a-z, 0-9, (,) &-. However the legacy data source can contain characters in the invalid data set.


of 79

Transformation are applied on the telephone data in legacy to strip away characterslike spaces, [, ], <, >, @ etc.

One of the key Automated Data Cleansing processes is the cleaning andstandardization of the legacy addresses by having them validated and convertedthrough QAS. All the addresses in legacy – except the site addresses and theaddresses provided by the corporate team – will be validated and converted into astandard address. If QAS is not able to resolve the address with an acceptable match-code the address will be moved without any QAS enhancement from legacy.

The above business rules for data cleansing will be communicated through the data migrationFS’s (BW 227) created by the Data Migration Upload team.

12 Extract and Transformation

The approach to the extract and transformation remains unchanged. Refer the ‘BW232 DataMigration Staging Area Design doc’ for details. The pictorial view is below –

CGABS30K custs, 40 K

sitesCGABS

TGB

Pre Single ViewHold Area

Post SingleView Hold Area

Flat Files

SAPISU

TGB300 K custs,300 K sites

Select activecustomers & relateddata for migration

Align Data into SingleView

Convert Data to nearSAP format

Create Upload Files SAP UploadCopy subset of datato be migrated

LEGACY STAGE IIISTAGE II STAGE IV SAPSTAGE I

TMS, pH,MAQ3,

XoServe, NGM,Others

LEGACY TO SAP LOGICAL DATA FLOW

SAPCRM

Figure 3: Extract and Transform

Activities performed at each stage will be the following –

1. Stage I – Extract

1.1. Source Filters1.2. Include Lists


of 79

1.3. Exclude Lists1.4. Batch Size Filters1.5. Prioritisation1.6. Exclude accounts which fail the quality rules

2. Stage II – Transform to SAP

2.1. Join multiple source tables to single target2.2. Translate from legacy codes to SAP codes2.3. Data Cleansing based on business rules2.4. Enrichment of data from external sources

3. Stage III – Consolidate based on Single View

3.1. Acquire linking data from pH Group3.2. Perform code translation of dependent records

4. Stage IV – Convert to Flat Files

4.1. Reject data based on

4.1.1. Legacy Rules4.1.2.4.1.3. SAP Validation Rules

4.2. Create Flat Files to be used by the SAP upload process

5. The appropriate error handling routines need to be designed and incorporated within

the extraction, transformation data-stage jobs.

13 Exclusion Rules (Stage I)

Exclusion Rules are business driven rules that specify that data not meeting the rules are notto be selected as candidates for migration.

The full list of reasons can be found in the document ‘BW230 – ETL Data MigrationBusiness Rules. doc’. The exclusions in Data Migration will be managed in several ways.Initially accounts will be excluded automatically due to the Extraction Criteria applied foreach legacy system. The next step is 'Business Rules'. Business Rules have been developed inAudit Stage to identify accounts using Legacy data that are not suitable for migration. Thethird step is via Exclusion Lists. Lists will be obtained from the Business at a suitable timeprior to migration for different reasons why an account cannot be migrated. This lists will becreate in the staging area and accounts will be cross-referenced against this list at the time ofmigration. If an account appears in this list, the account will not be migrated.

Lists are to be provided only where the identifying data cannot be found in Legacy and wherepending jobs etc are help on external databases.

14 Rejection Rules (Stage IV)


of 79

Rejection rules are technical rules that specify that data not meeting specific criteria are not tobe prevented from migration. This is because the data in the staging area is not sufficient toperform a complete migration of the account. An example of this is that a service contractshould not be created if the supporting technical POD cannot be created successfully.

15 Reporting Rules

Reporting rules are created to generate reports in the staging area to generate lists of accountsthat have met/violated agreed rules. These rules will be coded and executed throughAuditStage (i.e.)

Meter Isolations Meter Exchanges Renewals

16 Reconciliation Procedure

Reconciliation of the data migrated into SAP will be done in two stages. Between SAP ISU toSAP CRM and Legacy to SAP Systems

16.1 Reconciliation between Legacy and SAP Systems

Reconciliation between Legacy and SAP will be done in four ways – functional, technical,process and General Ledger. Diagram given below provides high-level reconciliation design

Figure 4: High Level Reconciliation design


of 79

Operation AOperation A, comprising of Operations A1 and A2 is concerned with reconciling the functional controlitem values recorded in the data migration Staging Area 1 database with the control point itemsrecorded in SAP IS-U/CRM. As each account is processed during migration, control item values willbe recorded at FCP1STAGING1, FCP2STAGING4 and FCP3sap and if they do not reconcile, the accountrejected.

Operation BOperation B is concerned with demonstrating that the data extracted from the legacy source systems istransferred to the migration environment and loaded successfully into the data migration storagedatabase.

TCP1source system = TCP2STAGING

Operation COperation C demonstrates that the SAP IS-U/CRM load process has successfully loaded the SAP IS-U/CRM objects

TCP3FF = TCP4sap

Operation DOn completion of the transform and load process and successful functional reconciliation, a number offiles will be supplied to drive post migration system updates. Each file will be checked for row countand file size before transfer (TCP5) and after receipt (TCP6) to ensure that no data is lost during the filetransfer process

TCP5sap MAF = TCP6ss MAF

Operation EOperation E technical reconciliation point aims to confirm the successful replication operation betweenthe two modules of SAP

TCP7sapisu = TCP8sapcrm

Operation G1Upon successful completion of the data migration upload into SAP IS-U/CRM, updates will berequired in the source systems to close the account or inform the system that the account has beenmigrated. Process reconciliation is required to match the Migrated Accounts File from SAP with theAccounts marked as closed on TGB for each migration event.

Operation G2The change to ETL still requires Beacon to conduct a change of Supplier ID with industry participantsduring the migration window. Adopting the industry SUN process to facilitate this change requires apoint of reconciliation between Xoserve, National Grid Metering (NGM), iGTs, Commercial MeterAsset Managers (cMAMs), ICON and SAP.

16.1.1 Functional ReconciliationFunctional Reconciliation is concerned with the functional control itemsrecorded per migrated account.

The control items recorded per migrated object are associated with thefollowing high-level functional areas. Account Level – Description of the control item that will be recorded at

account level. A record of this control item will be stored for functionalcontrol points FCP1 and FCP2. The control item will be then reconciledbetween each functional control point to determine if a discrepancyexists.


of 79

Summated Level – For management information reporting purposes,data will be summated for the migrated accounts. The ‘Summated Level’column indicates the type of information produced by summating aparticular control item for all accounts. The summated control items canalso be grouped by control item values e.g. the total monetary VATamount could be broken down by account type (domestic / nondomestic). The content and layout of the audit and reconciliationfunctional report will be defined in conjunction with the business.

This is covered in details in the Data Migration Reconciliation Approach andRequirements document.

16.1.2 Technical / Volume ReconciliationTechnical (Volume) Reconciliation is performed at control point with datamovement.For example, row counts would be recorded after extract from legacy andafter load onto the migration platform. The two row counts would becompared to demonstrate that there has been no data loss during this process.This is covered in details in the Data Migration Reconciliation Approach andRequirements document.

16.1.3 General Ledger Audit and ReconciliationOn the successful completion of the migration process, the General Ledger(GL) will be updated to reflect the financial movement from the legacysystems to SAP IS-U/CRM. The GL update process requires a number offinancial reports to be produced and for the functional reconciliation to besuccessful. This is covered in more detail in the Data Migration GeneralLedger Approach document - Beacon Migration GL Account ApproachV0.4.doc

See the Appendix C – Attachments for reference

16.2 Process Reconciliation

Process reconciliation would reconcile the feeds that are sent out to externalinterfaces –

The SUN/RSN files The account closure indicator file Zero Balance File

16.3 Reconciliation between ISU and CRM

Reconciliation of the data migrated in ISU and replicated in CRM will be done in two ways

16.3.1 Volume Reconciliation:Standard tool Data Integrity Manager (DIMA) cannot be used for thereconciliation due to performance reasons looking at the volumes.


of 79

A custom tool will be developed for this activity, which will compare tablesin ISU & CRM give output in text files.

Following table lists the database tables in SAP which are used for volumereconciliation of the data replicated between ISU to CRM

Object Table in CRM Table in ISUBusiness Partner BUT000 BUT000Business PartnerRelationship

BUT051 BUT051

ContractAccount/BusinessAgreement:

CRMM_BUAG &CRMM_BUAG_H

FKKVK &FKKVKP

Connection Object ISU_CONNOBJ IFLOTPremise ISU_POD EVBSContract CRMD_ORDERADM_I EVER & EVERHCRM Line item MPRN& Tech POD

CRMD_Customer _I EUIHEAD

16.3.2 Quality Reconciliation:Sampling technique where data containing different businessscenarios. This will be done through inspection.

17 Appendix A– Data Migration Rules

The high-level business rules for the data migration are given below

1. Only live customers and their associated data will be migrated. Customers with thefollowing statuses will not be migrated.

1. Customers that have withdrawn successfully2. Customers that are currently in the withdrawal process3. Customers that are currently in the acquisition process4. Prepayment Sites5. Domestic Customers and mix usage customers that are to be retained in Jupiter.

(The final agreement on this customer base is still under discussion with Jupiter.)6. Incorrect/insufficient address data.7. Missing or incorrect MPRNs8. Missing Bank Details for Direct Debit Accounts9. Missing AQ details10. Duplicate Supply Points/Duel Billing11. Sites that are not live with Xoserve but still in BGB’s ownership12. Incorrect or Insufficient Contact details (either missing information on the contact

record or missing contacts)13. Provisional Accounts/On-hold Accounts14. Pending Meter Read Request15. Magnetic Card Accounts16. Unbilled Customers17. Missing GT Reads


of 79

18. Pending Erroneous Transfers19. Pending Site works/Work Orders20. Fuel Direct21. AQ Appeals22. Competitive Meters/3rd Party P&S Meters23. Incorrect VAT Registration Number (format check)24. Incorrect Agreement/Contract Start & end Dates25. Incorrect Date of Birth (format check)26. Insufficient Customer Details (including such things as missing name and post

code)27. Incorrect Billing Cycle28. Incorrect Pricing Start and End Dates29. Unsupported TGB Tariffs30. 8% Vat Accounts31. Open Complaints32. Pending COTs33. Pending Shipper Agreed Reads (9.4 – Disputed Reads)34. Joint Payment Arrangements (REQ03 – Exclude Joint Pay Arrangement)35. Held Bills (REQ25 – Exclude TGB Accounts with Out sorted Final Bill)36. Manual Employee Pensioner Discounts (6.2)37. XtraCare Accounts (7.2)38. Winter Rebate Vulnerable Customers (7.12)39. Outstanding Direct Debit Set-Up (9.1)40. Pending Prepayment (9.23)41. Pending Customer Payment Scheme (9.28)42. Write-offs, Authorisations, Refunds, Transfers (WARTS) (9.3)43. Suspended Direct Debit (9.4)44. Two Way Metering Flows

For more information, please refer to the document ‘BW230 Data Migration BusinessRules’ in Appendix C

2. Update Requirements – No requirements to update the data once it has been loadedinto SAP are anticipated. It is assumed that the legacy system will be in read onlymode during the period of migration. After the migration batch is signed off theaccounts in legacy will be flagged preventing any changes to the data.

3. No Contact History (Query and Response) data will be migrated into SAP. It will bemigrated into HDS.

4. Scope of historical data to be migrated will remain unchanged due to the change ofapproach.

Devices – Device Information at the time of last billed date will be broughtover. See the section 3.9.1 and 3.10 for more information

Meter Reads – Only the last billed read will be migrated Invoices – Closed invoices will not be migrated. Any open items related to

the invoices will be migrated as open financial documents. Prices – Site based prices from the last bill need to be brought over. See the

section 8 Historical information for more details Contract & Billing Information – Only current information will be migrated


of 79

Tariffs – Tariff pricing (price of the tariff plan) will be manually configuredon the Beacon.

Finance Data – Only open items will be migrated. Open Items are defined as

Open Invoices – These will be migrated as open financial documents Credit Notes – Any open credit notes will be migrated as such Charges – Any open charges will be migrated as such Payments – Any on account payments will be migrated as such

5. Mid Business Process Migrations

Internal Business Partners

i. Customers in the contract renewal process will be migrated into SAPmid-process. Interim processes will manage this process once thecustomer is in SAP. No reports are required to be provided since thelist of customers under renewal would already be available. (InterimProcesses).

ii. COT process will have to be worked out (Interim Processes).

iii. Centrica Energy flows have to be worked out

External Business Partners

1. Gas Industry Flows – ICON will be updated so that any flows intransit for customers that have been migrated are routed to Beacon.

2. Non Gas Industry Flows

Payment Director – no change is anticipatedBank Direct Debit set-up / cancellation – no changes areanticipated

18 Appendix B– Single Customer View

To clarify the set up of customers and accounts under a ‘single customer view’ several modelsare depicted below and an outline of the rules that will be followed in their set up. Themodels covered include:

1. Multiple accounts for a customer in TGB2. Multiple accounts for a customer in CGABS or Service Desk3. Multiple accounts for a customer in TGB and other legacy systems4. Group billing customer set up5. Head office branch business relationships6. Contact relationships with multiple accounts

Refer to the Beacon SAP Data Model v1.1 for further details on the relationship of thecustomers and accounts to he contracts and sites.


of 79

Multiple accounts for a customer in TGB

Key Set Up Rules

Business Partner The sold to party business partner (Customer) will always be of the category

organisation. pH Group will provide the business partner name to be utilised for the

business partner. This name will be the name on the contract and the namethat will appear on correspondences and the bill for all accounts associatedwith the business partner.

The business partner name should be the organisation / trading name and nota person’s name. In some cases TGB does not contain the organisation namein the appropriate field. Automated cleaning programs will be utilised toextend this name from other fields. Where the organisation name does notexist on the TGB account record and only a person’s name exists than manualdata cleaning should be undertaken to identify the organisation name. Wherethis is not undertaken the person’s name will be utilised. The complete namewill be populated as one string in one field.

pH Group will provide the primary address for the business partner. Thebusiness partner can contain multiple addresses. Data cleaning of the


of 79

addresses will be required to ensure that multiple addresses are not createdunnecessarily.

The business partner can also hold one or multiple bank accounts. Other details such as industry sector code, company registration number to be

utilised on the business partner will also be provided by pH Group. Only onevalue can e maintained.

Multiple phone numbers, and fax number can also be maintained on onebusiness partner.

Contact Business Partners The sold to (Customer) party business partner (organisation) and the contact

business partner are linked via business partner relationships. Therelationship type will be ‘has a contact’.

Each business partner organisation must have at least one contact businesspartner. Multiple contact business partners can also have a relationship to thebusiness partner organisation.

Contacts will have a relationship to the business partner organisation andtherefore will be a contact for all accounts. It is not possible to have a contactrelationship to account (business agreement).

Contacts are a mandatory link in each contract header and contract line item.Refer to discussion below. In this way it is possible to determine if there is aspecific contact related to the contract.

The same contact person will only be created once and linked to the samebusiness partner organisation, even when they are linked to the differentaccounts in legacy. For example, contact 1 will be created only once andlinked to the business partner organisation. pH Group will provide thecontact record only once in the return file. Note however, that where thesame contact person is also a contact for another business partnerorganisation then an additional business partner contact will be created in theSAP. Refer to the example below.

In some cases in TGB, a separate contact and organisation name does notexist. In these cases where manual data cleaning is not undertaken, the samename details will be repeated on the business partner organisation and thebusiness partner contact. This is because the contact is mandatory on thecontract. Therefore, one contact must be created. Refer to the outstandingissues section 3.1.4.

The contact address for TGB contacts will be equal to the billing address asno separate contact address is maintained in TGB. These addresses are notused in any further processing.

Where none of the accounts associated with the one business partnerorganisation have a contact, only one contact will be created. The address ofthe contact in this case will be the primary address of he business partner.

Business Agreement The business agreement is created with reference to a sold to party business

partner (Customer) In the Beacon data model, one business agreement will be created for each

site. In Release 1, joint invoicing is not supported. Therefore the businessagreement in release 1 will only ever be linked to one contract line item at atime.

The business agreement contains the billing address. This address will be oneof the business partners addresses. A reference to the appropriate address is


of 79

made when creating the business agreement. Different business agreementscan contain different billing addresses or the same billing address.

If the payment method for the account is direct debit, the business agreementmust contain reference to one of the bank accounts contained in the businesspartner. Different business agreements can reference different banks in thebusiness partner.

The business agreement can also reference alternative billing recipients,alternative dunning recipients, alternative payees and alternativecorrespondence recipients. These alternatives will be created as businesspartner in SAP. As outlined above if multiple accounts for the same ordifferent business partner contain one of these alternative, then separatebusiness partners will be created for each time they are used. A SCV ofalternative business partner is not in scope. The use of alternatives is notdepicted in the example provided.

Contract Set Up

TGB accounts will be created with separate contracts. This is because TGBdoes not have the concept of a contract. The terms and conditions in relationto the account may vary, for example separate payment terms. Therefore, aseparate contract model is the most appropriate match.

A contract is created for a sold to party business partner (Customer). Thebusiness partner organisation is maintained in the contract header.

Each contract must also contain a contact business partner. Different contactbusiness partner with a relationship to the business partner organisation canbe referenced in each contract. The contact business partner is maintained atthe header and at the line item level. For the purpose of migration the samecontact business partner will be reference in both places.

Each contract line item must include a business agreement. The businessagreement must relate to the business partner organisation for which thecontract was created.

The contract line item also contains a link to the supply point (IBASE), theMPRN details, and the product details. This is not depicted in the example.

Points of Clarification in Relation to the Model Depicted

Although the address is depicted as a separate object, it forms part of thebusiness partner record.

Although the example has accounts matching that have different addresses, inmost cases where the customer match is in TGB alone, all accounts will tendto have the same addresses. This example is provided to illustrate thetreatment of multiple addresses.

The discussion above refers to pH Group providing certain information.Service Desk and CGABS migration will include both SME and I&Ccustomers. The information for the I&C customer will be provided by a filefrom the I&C team instead of pH Group.


of 79

Multiple accounts for a customer in CGABS or Service Desk

Key Set Up Rules

Business Partner

Points 1 – 7 for the TGB migration will apply for the Service Desk and CGABSmigration. In most cases in these systems the organisation name is contained in thecustomer or account records. Therefore, less data cleaning may be required.

The name that is to appear in the business partner will be the name that appears oncorrespondence and the invoice, therefore appropriate cleaning will be required toensure that the primary record name selected by pH Group is consistent with theserequirements.

Additional, address, bank and phone details that are contained in the non-primarycustomer in the legacy system will be added to the same business partner.


of 79

Contact Business Partners Points 1, 2, 3, 4 and 5 for the TGB migration will apply for the Service Desk and

CGABS migration. In Service Desk and CGABS a separate contact record exists containing a specific

address for the contact. This record will be utilised to create the contact businesspartner in SAP and the address will be as per the legacy address for the contact. Asoutlined in point 5 of the TGB migration, the same contact will only be created once.

Business Agreement Points 1 – 5 for the TGB migration will also apply for the Service Desk and CGABS

migration.

Contract Set Up Points 2, 4 and for the TGB migration will also apply for the Service Desk and

CGABS migration. The SAP CRM contract will represent the paper contract with the customer. The

CRM contract will contain a line item for each site included in the paper contract.For Service Desk and CGABS, both SME and I&C customers may have contractswith multiple line items. The customer may also have multiple CRM contract in SAPif they have multiple paper contracts. This is not depicted in this particular example.Note this has potential to change based on the outcome of the multiple line item issuecurrently under discussion with SAP.

Each contract must also contain a contact business partner. Different contact businesspartner with a relationship to the business partner organisation can be referenced ineach contract. The contact business partner is maintained at the header and at theline item level. Different contacts can be linked to each line item in the contract.


of 79

Multiple accounts for a customer in TGB and other legacy systems

The comments outlined in the TGB and CGABS and Service Desk migration above will alsoapply where a SCV is identified across legacy systems. The current assumption is that themigration of data will be on a system by system basis instead of a customer by customer basisas was the previous assumption. Subject to the approval of the related change request thefollowing additional rules will apply. It is assumed that where a ‘big bang’ approach is notutilised within a single system, that all SCV customers within the system will be migrated atthe same time.

Business Partner The second and subsequent migrations will also need to take into consideration the

SAP business partner information in the determination of the SCV. The lead information for the business partner record can come from a system that is

not currently the system being migrated from. In the example provided the leadinformation will be the CGABS record and not the TGB record. The business partnerwill be created as part of the TGB migration with the CGABS name and address andthe TGB address details.

In subsequent migrations the existing SAP business partners will be changed toinclude the additional address, phone and bank information from the subsequentlegacy systems. The business partners name, primary address, existing bankinformation, existing phone, industry sector etc will not be changed.


of 79

Contact Business Partners Additional contacts will be added to the existing business partner in subsequent

migrations. The existing contact business partner will not be changed. If the contactfor the new migration is the same as the contact business partner already linked to thebusiness partner organisation a new business partner contact will not be created. Theexisting contact will be linked to the new contracts etc.

Business Agreement New business agreements created for the subsequent migrations can be linked to

business partners already existing in SAP. As the business agreements will be site specific no existing business agreement will

be utilised in the subsequent migrations.

Contract Set Up Contracts in the different legacy systems will be independent contracts Therefore no

additional line items will be added to an existing contract in subsequent migrations.


of 79

Group Billing Customer Set Up

Key Set Up Rules

The set up of customers with a collective and collation billing arrangement will be as outlinedin the TGB and CGABS and Service Desk migration section. The details below outline theadditional set up requirements.

Business Partner

The business partner will be linked to the collective or collation account in addition tothe standard contract account. For the purpose of migration it is assumed that boththe collective or collation account and the standard contract account will be linked tothe same business partner.

Business Agreements A collective and collation contract account will be created for each group billing

arrangement. The standard contract accounts will be linked to either the collective or collation

account.

Contract


of 79

The contract will be set up as outlined above. The standard contract account isreferenced in the contract. No reference is made to the collective or collationaccount. The link to these accounts is via the standard business agreement.


of 79

Head Office and Branch Relationships where no Billing Relationship

The creation of business partner hierarchies, i.e. head office branch relationships is notsupported in data migration.

If the business wishes to create this head office branch business partner relationship postmigration then the following activities will need to be manually executed:

Create the head office business partner if they don’t already exist. (I.e. businesspartner 5 in the example above);

Create a business partner relationship between the head office business partner andthe branch business partners. The relationship type will be ‘is the head office’. (I.e. arelationship between BP3 and BP 5 and between BP5 and BP4 in the example above)Note this business partner relationship is not currently configured in the system.Additional configuration will be required if this relationship is required.


of 79

Contact Relationships with Multiple Customers

A single view of contacts is not within the scope of the SCV. Where a person is a contact formore then one organisation they will be created in SAP as two separate business partnerpersons, each of which having a relationship to the relevant business partner organisation.This is depicted in the model above in the section SAP Proposed Model.

As outlined above if the same person is a contact for more than one account for an individualbusiness partner organisation then only one business partner contact will be created and onlyone business partner relationship to the business partner organisation. Refer to the examplesin the previous sections.

If the business wishes to create a single view of contacts post migration then some manualdata cleaning will be required in SAP. After the single view of the contacts is identified thefollowing manual steps would need to be performed in SAP:

Create a business partner relationship between the contact to be retained and the otherbusiness partner organisation. (I.e. business partner 3 and business partner 2 in theexample above.)

Remove the business partner relationship between the duplicate contact and thebusiness partner organisation and flag the duplicate business partner contact fordeletion. (I.e. business partner 4 in the example above)


of 79

19 Appendix C– Attachments

Beacon Migration GL Account Approach V0.4_CB.doc

. \24. Reconciliation\Beacon Migration GL AccountApproach V0.4_CB.doc

Data stage EE(PX) Best Practices

"DataStage EE(PX)Best Practices v2.0_final.doc"

Data Migration Decision Note

Data MigrationDecisions Note ...

Data Migration Business Rules

"BW230 DataMigration Business Rules - v0.6.doc"

Data migration blueprint legacy to sap

Technology

Transcript of Data migration blueprint legacy to sap