Electricity retail market business processes in Datahub · Web viewA GLN code is a 13-character code, which comprises a GS1 company ID, freely selectable numbers (3-5 of them) and

Electricity retail market business processes in Datahub31.10.2019

20.12.2019


2 (203)

Table of Contents

Change log ......................................................................................................................................

Definitions and abbreviations .......................................................................................................

1 Introduction .............................................................................................................................

1.1 To reader ...........................................................................................................................

1.2 Legislation supporting Datahub .........................................................................................

1.2.1 Datahub services ........................................................................................................

1.2.2 The data stored in the Datahub and assigning of it ....................................................

1.2.3 Market parties that are using Datahub services .........................................................

1.2.4 Duties and responsibilities of parties ..........................................................................

1.2.5 Degrees supporting the Electricity Market Act ...........................................................

1.3 Development in retail market information exchange .........................................................

1.4 Business operations in the Datahub environment .............................................................

1.4.1 The following chapters summarize by their roles how datahub will change operators' daily business. Suppliers .........................................................................................

1.4.2 Distribution system operators .....................................................................................

1.4.3 Customers ..................................................................................................................

1.4.4 Third parties ................................................................................................................

1.4.5 Datahub operator ........................................................................................................

1.5 Data protection ..................................................................................................................

1.6 Process map ......................................................................................................................

1.7 The content of this document ............................................................................................

1.8 How to read UML descriptions ..........................................................................................

1.8.1 Common notation .......................................................................................................

Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code

FI27455435, VAT regLäkkisepäntie 21 P.O.Box 530 [email protected] Helsinki FI-00101 Helsinki +358 30 395 5000 +358 30 395 5196 www.fingrid.fi


3 (203)

1.8.2 Class diagrams ...........................................................................................................

1.8.3 Sequence diagrams ...................................................................................................

2 Datahub's data model and parties' rights to data ...............................................................

2.1 Description of conceptual model .......................................................................................

2.2 Parties' rights to data .........................................................................................................

2.3 Data storage period ...........................................................................................................

2.4 Party user interface ............................................................................................................

2.5 Data interface for market parties .......................................................................................

3 Description of market processes ..........................................................................................

3.1 DH-100 Management of customer and accounting point data ..........................................

3.1.1 DH-120 Maintenance of accounting point data ..........................................................

3.1.2 DH-110 Maintenance of customer information ...........................................................

3.1.3 DH-130 Retrieval of customer and accounting point data ..........................................

3.2 DH-300 Agreement processes ..........................................................................................

3.2.1 Agreement information ...............................................................................................

3.2.2 DH-310 Reporting new agreements ...........................................................................

3.2.2.1 Making a grid agreement ........................................................................................

3.2.2.2 Process description ................................................................................................

3.2.2.3 Rules .......................................................................................................................

3.2.2.4 Examples ................................................................................................................

3.2.2.5 Fixed-term sales agreements .................................................................................

3.2.2.6 Exceptional termination clauses .............................................................................

3.2.3 DH-320 Reporting changes to agreements ................................................................

3.2.4 DH-330 Reporting the ending of an agreement .........................................................

3.2.4.1 Process descriptions ...............................................................................................

3.2.4.2 Separate move-in and move-out reports ................................................................

3.2.4.3 Separate move-out notification as part of the customer's move-in .........................




4 (203)

3.2.4.4 The customer disputes a sales agreement .............................................................

3.2.5 DH-340 Cancelling an agreement and correcting errors ............................................

3.2.5.1 Cancelling a sales agreement ................................................................................

3.2.5.2 Retrospective error correction ................................................................................

3.2.6 Other types of agreement ...........................................................................................

3.2.6.1 Small-scale production purchase agreements ........................................................

3.2.6.2 Electricity delivery agreements ...............................................................................

3.3 DH-200 Processing metering data ....................................................................................

3.3.1 Metering data ..............................................................................................................

3.3.2 DH-210 Reporting metering data ...............................................................................

3.3.2.1 Time limits for reporting metering data ...................................................................

3.3.2.2 Metering data validation ..........................................................................................

3.3.2.3 Status processing ...................................................................................................

3.3.2.4 Monitoring of metering data reports ........................................................................

3.3.2.5 Transmitting metering data .....................................................................................

3.3.3 Processing reading metering and unmetered sites ....................................................

3.3.4 Correction of metering data ........................................................................................

3.3.5 Processing reactive energy data ................................................................................

3.3.6 Processing exchange point and production unit metering ..........................................

3.4 DH-400 Connection and disconnection processes ...........................................................

3.4.1 General description ....................................................................................................

3.4.2 Process descriptions ..................................................................................................

3.5 DH-500 Distribution system operator's imbalance settlement ...........................................

3.5.1 Initial data for balance settlement ...............................................................................

3.5.2 Virtual production units ...............................................................................................

3.5.3 Imbalance settlement calculations and calculated data .............................................

3.5.4 Information exchange in imbalance settlement ..........................................................




5 (203)

3.5.5 Data reported to eSett ................................................................................................

3.5.5.1 Structural information ..............................................................................................

3.5.5.2 Time series data .....................................................................................................

3.5.6 Supplier's imbalance settlement data .........................................................................

3.5.7 Distribution system operator's imbalance settlement data .........................................

3.5.8 Imbalance settlement calculations outside the balance window ................................

3.6 DH-600 Management of balance deviation .......................................................................

3.6.1 Balance deviation calculation and handling process ..................................................

3.6.2 Balance deviations caused by metering data corrections ..........................................

3.6.3 Balance deviation of metering grid area losses ..........................................................

3.6.4 Performance of balance deviation calculations ..........................................................

3.6.5 Balance deviation data ...............................................................................................

3.7 DH-700 Maintenance and retrieval of product and invoice row data .................................

3.7.1 Product data ...............................................................................................................

3.7.2 Invoice row data .........................................................................................................

3.8 DH-800 Authorisations and delegations ............................................................................

3.8.1 Authorisations granted by the customer .....................................................................

3.8.2 Delegations and party authorisations granted by the parties .....................................

3.8.2.1 Party authorisations ................................................................................................

3.8.2.2 Delegations between parties ..................................................................................

3.9 DH-900 Maintaining party information ...............................................................................

3.10 Structural changes to metering grid area ..........................................................................

3.10.1 Transferring control of a metering grid area ...............................................................

3.10.1.1 The transfer of grid agreements to a new DSO ..................................................

3.10.1.2 The transfer of rights to the new DSO .................................................................

3.10.1.3 Rights to accounting point data ...........................................................................

3.10.1.4 Imbalance settlement ..........................................................................................




6 (203)

3.10.1.5 Calculating balance deviations ............................................................................

3.10.1.6 Process diagram for transferring control of a metering grid area ........................

3.10.2 Division and merging of metering grid areas ..............................................................

3.10.2.1 Accounting points ................................................................................................

3.10.2.2 Exchange points ..................................................................................................

3.10.2.3 Production units ..................................................................................................

3.10.2.4 Imbalance settlement ..........................................................................................

3.10.2.5 Calculating balance deviations ............................................................................

3.10.2.6 Division and merging of MGAs under one DSOs administration ........................

3.10.2.7 Division and merging of MGAs with different DSOs ............................................

3.10.3 Complex changes and reporting ................................................................................

3.11 Customer access to own information ................................................................................

3.12 Report required by the Finnish Energy Efficiency Act .......................................................

3.13 System availability .............................................................................................................

3.13.1 Users associated with system administration .............................................................

3.13.2 System support service model ...................................................................................

3.13.2.1 Reporting disturbances .......................................................................................

3.13.2.2 On-call support ....................................................................................................

3.13.3 Scheduled service interruptions .................................................................................

4 Source list ...............................................................................................................................

Appendix A Descriptions of imbalance settlement calculations ...........................................

A.1 Supplier's metered sum delivery ........................................................................................

A.2 Supplier's profiled sum delivery .........................................................................................

A.3 Supplier's small-scale production ......................................................................................

A.4 Supplier's metered own consumption sum ........................................................................

A.5 Supplier's profiled own consumption sum .........................................................................

A.6 Exchange point sum (MGA Exchange) .............................................................................

A.7 Metering grid area losses ..................................................................................................Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



7 (203)

A.8 Supplier's total small-scale production sum .......................................................................

A.9 Metering grid area's metered sum delivery ........................................................................

A.10 Metering grid area's profiled sum delivery .........................................................................

A.11 Metering grid area's small-scale production ......................................................................

A.12 Metering grid area's metered own consumption sum ........................................................

A.13 Metering grid area's profiled own consumption sum .........................................................

A.14 Metering grid area's production unit sum ...........................................................................

A.15 Metering grid area's total exchange point sum ..................................................................

A.16 Metering grid area's total small-scale production sum .......................................................

A.17 Metering grid area's total production unit sum ...................................................................

Change log ......................................................................................................................................

Definitions and abbreviations .....................................................................................................

1 Introduction ...........................................................................................................................

1.1 To reader .........................................................................................................................

1.2 Legislation supporting Datahub .......................................................................................

1.2.1 Datahub services ......................................................................................................

1.2.2 The data stored in the Datahub and assigning of it ..................................................

1.2.3 Market parties that are using Datahub services .......................................................

1.2.4 Duties and responsibilities of parties ........................................................................

1.2.5 Degrees supporting the Electricity Market Act .........................................................

1.3 Development in retail market information exchange .......................................................

1.4 Business operations in the Datahub environment ...........................................................

1.4.1 Suppliers ...................................................................................................................

1.4.2 Distribution system operators ...................................................................................

1.4.3 Customers ................................................................................................................




8 (203)

1.4.4 Third parties ..............................................................................................................

1.4.5 Datahub operator .....................................................................................................

1.5 Data protection ................................................................................................................

1.6 Process map ....................................................................................................................

1.7 The content of this document ..........................................................................................

1.8 How to read UML descriptions ........................................................................................

1.8.1 Common notation .....................................................................................................

1.8.2 Class diagrams .........................................................................................................

1.8.3 Sequence diagrams .................................................................................................

2 Datahub's data model and parties' rights to data .............................................................

2.1 Description of conceptual model .....................................................................................

2.2 Parties' rights to data .......................................................................................................

2.3 Data storage period .........................................................................................................

2.4 Party user interface .........................................................................................................

2.5 Data interface for market parties .....................................................................................

3 Description of market processes ........................................................................................

3.1 DH-100 Management of customer and accounting point data ........................................

3.1.1 DH-120 Maintenance of accounting point data ........................................................

3.1.2 DH-110 Maintenance of customer information .........................................................

3.1.3 DH-130 Retrieval of customer and accounting point data ........................................

3.2 DH-300 Agreement processes ........................................................................................

3.2.1 Agreement information .............................................................................................

3.2.2 DH-310 Reporting new agreements .........................................................................

3.2.2.1 Making a grid agreement ......................................................................................

3.2.2.2 Process description ..............................................................................................




9 (203)

3.2.2.3 Rules .....................................................................................................................

3.2.2.4 Examples ..............................................................................................................

3.2.2.5 Fixed-term sales agreements ...............................................................................

3.2.2.6 Exceptional termination clauses ...........................................................................

3.2.3 DH-320 Reporting changes to agreements ..............................................................

3.2.4 DH-330 Reporting the ending of an agreement .......................................................

3.2.4.1 Process descriptions .............................................................................................

3.2.4.2 Separate move-in and move-out reports ..............................................................

3.2.4.3 Separate move-out notification as part of the customer's move-in .......................

3.2.4.4 The customer disputes a sales agreement ...........................................................

3.2.4.5 DH-323 Accounting points without supplier ..........................................................

3.2.5 DH-340 Cancelling an agreement and correcting errors ..........................................

3.2.5.1 Cancelling a sales agreement ..............................................................................

3.2.5.2 Retrospective error correction ..............................................................................

3.2.6 Other types of agreement .........................................................................................

3.2.6.1 Small-scale production purchase agreements ......................................................

3.2.6.2 Electricity delivery agreements .............................................................................

3.3 DH-200 Processing metering data ................................................................................

3.3.1 Metering data ..........................................................................................................

3.3.2 DH-210 Reporting metering data ...........................................................................

3.3.2.1 Time limits for reporting metering data ...............................................................

3.3.2.2 Metering data validation ......................................................................................

3.3.2.3 Status processing ...............................................................................................

3.3.2.4 Monitoring of metering data reports ....................................................................

3.3.2.5 Transmitting metering data .................................................................................

3.3.3 Processing reading metering and unmetered sites ................................................

3.3.4 Correction of metering data ....................................................................................

3.3.5 Processing reactive energy data ............................................................................

3.3.6 Processing exchange point and production unit metering ......................................




10 (203)

3.4 DH-400 Connection and disconnection processes .......................................................

3.4.1 General description ................................................................................................

3.4.2 Process descriptions ..............................................................................................

3.5 DH-500 Distribution system operator's imbalance settlement .......................................

3.5.1 Initial data for balance settlement ...........................................................................

3.5.2 Virtual production units ...........................................................................................

3.5.3 Imbalance settlement calculations and calculated data .........................................

3.5.4 Information exchange in imbalance settlement ......................................................

3.5.5 Data reported to eSett ............................................................................................

3.5.5.1 Structural information ..........................................................................................

3.5.5.2 Time series data .................................................................................................

3.5.6 Supplier's imbalance settlement data .....................................................................

3.5.7 Distribution system operator's imbalance settlement data .....................................

3.5.8 Imbalance settlement calculations outside the balance window ............................

3.6 DH-600 Management of balance deviation ...................................................................

3.6.1 Balance deviation calculation and handling process ..............................................

3.6.2 Balance deviations caused by metering data corrections ......................................

3.6.3 Balance deviation of metering grid area losses ......................................................

3.6.4 Performance of balance deviation calculations ......................................................

3.6.5 Balance deviation data ...........................................................................................

3.7 DH-710 and DH-720 Maintenance and retrieval of product data ..................................

3.7.1 Product data ...........................................................................................................

3.7.2 Create a product .....................................................................................................

3.7.3 Update product structural data ...............................................................................

3.7.4 Update prices or price time series data ..................................................................

3.7.5 Product data request ..............................................................................................Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



11 (203)

3.8 DH-730 and DH-740 Maintenance and retrieval of invoice row data ............................

3.8.1 Invoice row data .....................................................................................................

3.8.2 Invoice row request ................................................................................................

3.9 DH-800 Authorisations and delegations ........................................................................

3.9.1 Authorisations granted by the customer .................................................................

3.9.2 Delegations and party authorisations granted by the parties .................................

3.9.2.1 Party authorisations ............................................................................................

3.9.2.2 Delegations between parties ..............................................................................

3.10 DH-900 Maintaining party information ...........................................................................

3.11 Structural changes to metering grid area ......................................................................

3.11.1 Transferring control of a metering grid area ...........................................................

3.11.1.1 The transfer of rights to the new DSO .............................................................

3.11.1.2 Rights to accounting point data .......................................................................

3.11.1.3 Imbalance settlement ......................................................................................

3.11.1.4 Calculating balance deviations ........................................................................

3.11.1.5 Process diagram for transferring control of a metering grid area ....................

3.11.2 Division and merging of metering grid areas ..........................................................

3.11.2.1 Accounting points ............................................................................................

3.11.2.2 Exchange points ..............................................................................................

3.11.2.3 Production units ..............................................................................................

3.11.2.4 Imbalance settlement ......................................................................................

3.11.2.5 Calculating balance deviations ........................................................................

3.11.2.6 Division and merging of MGAs under one DSOs administration ....................

3.11.2.7 Division and merging of MGAs with different DSOs ........................................

3.11.3 Complex changes and reporting ............................................................................

3.12 Customer access to own information ............................................................................

3.13 Report required by the Finnish Energy Efficiency Act ...................................................

3.14 System availability .........................................................................................................




12 (203)

3.14.1 Users associated with system administration .........................................................

3.14.2 System support service model ...............................................................................

3.14.2.1 Reporting disturbances ...................................................................................

3.14.2.2 On-call support ................................................................................................

3.14.3 Scheduled service interruptions .............................................................................

4 Source list ...........................................................................................................................

Appendix A Descriptions of imbalance settlement calculations .......................................

A.1 Supplier's metered sum delivery ....................................................................................

A.2 Supplier's profiled sum delivery .....................................................................................

A.3 Supplier's small-scale production ..................................................................................

A.4 Supplier's metered own consumption sum ....................................................................

A.5 Supplier's profiled own consumption sum .....................................................................

A.6 Exchange point sum (MGA Exchange) .........................................................................

A.7 Metering grid area losses ..............................................................................................

A.8 Supplier's total small-scale production sum ...................................................................

A.9 Metering grid area's metered sum delivery ....................................................................

A.10 Metering grid area's profiled sum delivery .....................................................................

A.11 Metering grid area's small-scale production ..................................................................

A.12 Metering grid area's metered own consumption sum ....................................................

A.13 Metering grid area's profiled own consumption sum .....................................................

A.14 Metering grid area's production unit sum .......................................................................

A.15 Metering grid area's total exchange point sum ..............................................................

A.16 Metering grid area's total small-scale production sum ..................................................

A.17 Metering grid area's total production unit sum ...............................................................




13 (203)




14 (203)

Change log

Date Version Changes

20.12.2019 1.11

In chapter 1.4.2 process role metering point administrator removed from the DSO. In chapter 1.4.3 clarified that for consumer customers only the customer themself can

create or update an authorization. In chapter 1.4.4 clarified that a third party can also operate based on a delegation. In chapter 2.2 added potential supplier to the table of party’s rights to information. In chapter 2.5 clarifications to use and functionality of data interface. In chapter 3.1.1 time division added to accounting point data. In chapter 3.1.2 company estate added to customer sub-types. In chapter 3.2.1 clarifications related to postal invoicing address and invoicing method. Added chapter 3.2.4.5 about notifications of accounting points without supplier. In chapter 3.2.5.2 clarifications to handling of retrospective agreement ending. Updated in chapter 3.3.2.1 time limits for reporting metering data related to imbalance

settlement Updated in chapter 3.5 Imbalance settlement process in datahub class diagram Added in chapter 3.5 and 3.5.3 MGA exchange confirmation calculated by eSett Specified in chapter 3.5 MGA imbalance calculated by eSett to intermediate and final

calculations Updated in chapter 3.5.4 new imbalance settlement events to process map Updated in chapter 3.6.5 collection of balance deviation data class diagram Product and invoice row data divided into separate chapters 3.7 and 3.8. Description of

product data processes significantly supplemented with new subchapters 3.7.2-3.7.5. Data model of product data updated.

In chapter 3.9.1 clarifications to which time period the authorization gives access to. Description of party information maintenance added in chapter 3.10. Invoicing address type

added to party’s postal invoicing address. Party’s contact person types updated. Limited party’s invoicing channels to paper and electronic invoices.

In chapter 3.11 several updates in MGA structural changes. Several other smaller clarifications.

31.10.2019 1.10 Clarified handling of consumption and production accounting points datahub in chapter 3.1.1.

Removed association ID from customer identification types. All associations get a business ID with PRH register of associations renewal.

Corrected that it is not mandatory to report either a telephone number or an email address for a customer. Postal address is sufficient.

Clarified use of supplementary company name in datahub, in chapter 3.1.2. Added instruction to chapter 3.2.2 what to do if a supplier makes an agreement with

a customer more than 90 days ahead of time. Clarified handling of fixed-term agreements in chapters 3.2.2.3 and 3.2.2.5. Added to chapter 3.2.2.3 that agreements that get an end date right away when they

are created to datahub will automatically get termination as the reason for agreement end.

Corrected in chapter 3.2.3 that customer information is not updated with agreement information update.

Added meter removal as a reason for agreement end in chapter 3.2.4. Clarified oin chapter 3.2.4.3 that it is the responsibility of the DSO to end the grid




15 (203)

Date Version Changesagreement based on the supplier’s move-out notification if necessary.

Updated chapter 3.2.5.1 related to sales agreement cancellations. Clarified description of refusing sales agreement restoration. Added new reason for agreement cancellation that is used when customer cancels the agreement but not the move-in. Described the situations when datahub cannot automatically restore previous supplier’s agreement. Described how datahub works if there already is a future agreement following the agreement being cancelled in datahub. Described how datahub works if the previous agreement or the agreement being cancelled has an end date.

Clarified in chapter 3.2.6 that background agreements are not handled in datahub. In chapter 3.3.2 and 3.3.2.3 clarified status processing for metering data In chapter 3.3.5 clarified forwarding of reactive energy data to metering grid area

specific In chapter 3.3.6 added description about connection statuses for exchange points

and production units Added production unit class to diagram 43 in chapter 3.5.1 Clarified the description of authorisations in chapter 3.8. Party authorisations have

been added. Two new authorization types have been added to customer authorisations and clarified for which time period each authorization type grants access to accounting point metering data. Market party can only report an authorization for a company customer.

Additionally other small clarifications.

11.7.2019 1.9 Clarified the description of the data interface in chapter 2.5 In chapter 3.1.2 clarified handling of customer identification when personal

identification is added to a consumer In chapter 3.1.2 clarified that information about customer changing to information

restricted is forwarded normally to customer’s other suppliers and DSOs. In chapter 3.2.1 clarified that in Datahub, agreement identification, accounting point

identification and party identification together individually identify an agreement. In chapter 3.2.1 changes to agreement attributes: Fixed-term start date has been

added to sales agreement, postal invoicing address is always mandatory. Clarified handling of fixed-term agreements in chapter 3.2.2. Clarified in chapter 3.2.2.1 that a validation for checking under aged customers Is in

Datahub Clarified agreement update rules in chapter 3.2.3. Clarifications to agreement endings in chapter 3.2.4. Clarified in chapter 3.2.5.2 that in case when reporting a retrospective new sales

agreement, the supplier can get the related metering data with metering data request – event.

Clarified that the informations to obligatory supplier is delivered by report in chapter 3.2.6.2

Clarifications to chapter 3.3.1: production unis own consumption as accounting point subtype, updated the class diagram for metering data, time series for connection points, functionality of metering data request, if no time step is specified

Changed to chapters 3.3.1 and 3.3.2.5 that storage time is registered for metering data

Added to chapters 3.3.2.2 and 3.3.5 status processing for reactive energy, changed reactive power to reactive energy

Changed status processing to chapter 3.3.2.3 Changed role of the DSO to metering data responsible in chapter 3.3.2.4 In chapter 3.4.1 added instructions on updating accounting point characterstics

before connecting an accounting point and clarified handling of time limits for




16 (203)

Date Version Changesconnection/disconnection reports and delay notifications.

In chapter 3.7.2 invoice row data class diagram updated. Clarified the description of reporting invoice rows in chapter 3.7.2

21.5.2019 1.8

Chapter 3.5 and Appendix A Changed “15-minutes” to “in accordance with the official imbalance settlement period” due to delay of fifteen minutes imbalance settlement

Added the DH-xxx identification to process chapter headers The ebIX roles have been fixed Clarified the parties’ rights to data in chapter 2.2. New picture of the accounting points status diagram added Added new status Removed from the system to chapter 3.1.1 table 4 Added the way to correct the personal identification to chapter 3.1.2 A new section has been added to chapter 3.1.2 that describes the principle of

customer data update Clarified search criteria’s in chapter 3.1.3 and the definition of the “Leaving supplier” Clarified the use of electronic contact method in chapter 3.2.1 Clarified to chapter 3.4.1 that the delay notification can be reported multiple times Corrected picture 46 in chapter 3.8 Added the authorization types to table 18 in chapter 3.8.1 and clarified the validity

periods Clarified the updating of existing authorization in chapter 3.8.1

12.2.2019 1.7 Event descriptions moved to document Datahub-Events version 1.7

Clarified the roles in chapter 1.4

Added new chapter 1.2. about the Datahub legislation

Added new class diagrams according to other descriptions and message changes

Cahpter 2.2 Specified the rights to customer data to previous and future supplier

Chapter 3.1.1 specified the maxim amount of addresses in accounting point, the

validity of accounting point notifications, added that the accounting point can locate

outside Finnish borders, specified that the status change to connected,

dosconnected and deleted are not done with accounting point update event,

specified the description of deleting accounting point, specified the rights to

requesst the update of an accounting point, specified that the DSO must inform the

reason why the update has not been done according to request of update, removed

the reminder to DSO of update accounting point dueto request, specified the linking

between smallscale production accounting point and consumption accounting point

Chapter 3.1.2 Specified forwarding the suppliers own customer identification to DSO,

specified forwarding the customer information to other parties when changed,

specified the validity of authorisation ofinformation restricted customers and

specified thet in case of information restricted customers the customer can only

remove the marking in customer user interface

Chapter 3.2.1 Added a description of validity times of agreements

Chapter 3.2.2.1 Specified the description on forwarding the information of sales

agreement to DSO when no new grid agreement is needed, specified the handling of




17 (203)


DSO's agreement identification, specified the description on connecting the

accounting point in case of new agreement

Chapter 3.2.2.3 specfied the rule nr 7 that all customers need to change

Chapter 3.3 Changed the descriptions of processing of metering data so that

Datahub enables processing of 15 minutes metering data

Chapter 3.3.2 Specified that Datahub forwards the received metering data

Chapter 3.3.2.2 Secified the validationrule with fuze size and electric power

Chapter 3.3.2.4 Specified the roles to whom the reminder is sent

Chapter 3.3.2.5 Specified that Datahubforwards all received metering data

Chapter 3.4.1 Specified the description of delay notification of connection and the

disconnection together with dismantling the accounting point

Chapter 3.5 and Appendix A Described changes that 15 minutes imbalance

settlement will cause

Chapter 3.7.2 Specified the use of valid Act in functionalities

Chapter 3.8.1 Specified the description of saving the authorisation always to

customer and accounting point level, added the description to ending the

authorisation in cases of move-out and information restricted customers

Chapter 3.11. Specified notifying of authorisations to market parties and added the

description of deleting the information restricted marking

1.6 Added information about the transfer direction of active energy to exchange points

and the possibility to report reactive energy also to exchange points and production

units. Changes related to this in chapters 3.3.1, 3.3.2.4, 3.5.1, 4.3.1, 4.3.3.

3.3.2.2 Specified that production capacity is used for production accounting points

and production units for recognizing overtly large values.

3.3.6 and 4.3.1 Metering data correction procedure for exchange points and

production units has been changed.

A contact person has been added to supply connection request. Changes related to

this in chapters 3.4.1 and 4.5.1.1.

3.5.1 Changed so that only the metered data responsible DSO can give a delegation

to exchange point information.

3.6.3 Added that balance deviations of the losses are not reported to the supplier

who no longer is a loss supplier in the metering grid area.

Price unit identification has been added to both product component and invoice row

data, additionally quantity unit identification has been added to invoice row data.

Description of invoice rows in datahub in chapter 3.7.2 has been rewritten.

Added to chapter 3.8.2 that datahub sends an email to the party who has been given

a delegation.

Process diagrams for metering grid area structural changes have been added to

chapter 3.10.




18 (203)


Information concerning the report required by the energy efficiency act has been

updated and moved to a separate chapter 3.12.

Specified in chapter 4.8.3 that report of invoice row data is rejected per accounting

point.

19.3.2018 1.5

Added chapter 3.5.8 Imbalance settlement calculations outside the balance window,

added possibility to request this data to events in chapter 4.6.2

Added chapter 3.10 Structural changes to metering grid area

In chapter 3.11, elaborated the statutory reporting of customer's consumption data

Corrected sequence diagrams in chapter 4.6.2 to follow asynchronous pattern

Corrected the cardinality of postal address attributes in class diagrams21.12.2017 1.4 Removed definitions for input and output area.

Updated definitions for metering time series and authorisation.

Added definitions metered data responsible MGA, parallel MGA, data interface and

delegation.

Added removing information related to agreement and customer to chapter 2.3

Added clarification to party user interface functionality in chapter 2.4 regarding

metering data, imbalance settlement data and delegations.

Added chapter 2.5 data interface for market parties.

Added to chapter 3.1.1 how "heating depending on electricity" information is

handled.

Updated process description diagrams for accounting point and customer

information.

Added mobile invoicing address to agreement data in class diagrams.

Added rule 3 to chapter 3.2.2.3.

Added description of metered data responsible MGA to chapter 3.3.1.

Added to chapter 3.3.2.5 how metering data is forwarded when there's a delegation

between parties. Corrected to the same chapter that datahub relays metering data to

only one system for each party.

Specified in chapter 3.5.1 that either of the exchange point's DSOs can authorise a

party to exchange point data.

Added product description to product data in class diagrams.

Removed product and product component name from invoice row data in class

diagrams.

Started using word delegation to refer to authorisations between market parties.

Described delegation functionality in more detail in chapter 3.8. Added what cannot

be delegated.

Edited party information in class diagrams so that a party can have multiple

invoicing addresses.

Made additions to chapters 4.2.1 and 4.2.2 on how the events function related to

customer information and accounting point data update requests.




19 (203)


Added to validation conditions in chapter 4.2.1.2 that a DSO must have a valid or

future agreement with the customer.

Added to chapters 4.2.1.2 and 4.2.1.3 that the relayed customer information update

request may not reveal where it originated from.

Added metering grid area to class diagrams of messages DH-121 and DH-122.

Removed product names from class diagrams for DH-130 and DH-300 events.

Added limitations to the content of a single message for events DH-211, DH-220, DH-

514, DH-515, DH-521, DH-522 and DH-523.

Added updating reactive energy time series available -information based on

metering data report in chapter 4.3.1.

Updated new asynchronous data request sequence diagrams to events DH-220 and

DH-740.

In chapter 4.4.1.1: Added determining reason for agreement start. Updated rules for

determining reason for ending current agreement. Added that the end date of a fixed-

term agreement is returned with rejection if the end date is less than 90 days away.

Added class diagrams to messages DH-311-5 - DH-311-9.

Added information about rejecting grid agreement and determining reason for

agreement start to chapter 4.4.1.2.

Elaborated in chapter 4.4.2.3 that DSO ends their own agreement on an accounting

point without supplier and may disconnect the accounting point.

Added to processing in chapter 4.4.3.1 the cancellation of future agreements.

Added to event descriptions DH-412 and DH-422 that connection/disconnection date

cannot be in the future.

Added to chapters 4.8.3 and 4.8.4 conditions for forwarding/requesting invoice row

data.18.8.2017 1.2 Elaborated definitions for customer, distribution system operator, metering grid

area, metering data, party, exchange point, hourly data, production unit and

authorisation. Added definitions for price time series, calendar time series, market

balance area, metering time series, remote controlled load, balance settlement

connection, balance deviation, production device, product component and storage

unit.

Chapter 2.2: Updated the definition of basic accounting point data.

Chapter 2.3: Information storage times further elaborated.

Chapter 2.4: Added that a party can perform market processes only using either ther

messaging interface or the party user interface.

Chapter 3.1.1: Changed the instructions on handling agreement start date reported

by supplier for an accounting point with status "under construction".

Chapter 3.1.1: Biopower added to production types in accounting point data

diagram.

Chapters 3.1.1 and 3.1.2: Added that also third party can request customer or




20 (203)


accounting point information update.

Chapter 3.1.2: Elaborated handling of customer information of customers with

information restriction and estate of a deceased person customers. Elaborated the

identification of private traders.

Chapter 3.2.1: Changes in agreement class diagrams. Contact information type

mobile phone added to both of them, in addition added the missing invoicing

channels to sales agreement class diagram.

Chapter 3.2.1: Contact method moved from customer information to agreement

information.

Chapter 3.2.2: Added that an agreement can be reported for the present day if it is a

change of agreement.

Chapter 3.2.2.3: Rule 3: Removed an agreement reported by current supplier as an

exception to the rule. Rules 6 and 7: Elaborated that all customers must change at

the accounting point in order to revoke all the agreements of the current customer

(move in situation).

Chapter 3.2.5: Additions have been made for handling cancellations and retroactive

corrections to cover all possible cases. A process diagram for cancellations has

been added.

Chapter 3.2.6.2: Added that only the supplier with the delivery obligation in the

metering grid area can report a delivery agreement.

Chapter 3.3.1: Information about time of reception and editor added to metering data.

Chapter 3.3.1: Added that two metering time series are reported for an exchange

point.

Chapter 3.3: Removed the exception with exchange points regarding handling only

positive values.

Chapter 3.3.2.1: Elaborated the timelines for metering data delivery based on the new

messaging decree.

Chapter 3.3.2.4: Defined that reminder to send metering data covers only valid

metering points for the duration of grid agreement.

Chapter 3.3.2.4: Added that reminders will not be sent for uncertain statuses in

reading metered sites.

Chapter 3.3.2.5: Added that a DSO may forward information from their metering data

management system to their other systems through datahub.

Chapter 3.3.4: Elaborated information about metering data corrections.

Chapter 3.3.6: Added that also production unit metering data cannot be corrected

outside the balance window.

Chapter 3.4.1: Elaborated handling of supply connection request and a DSO's

notification of supply connection related to the request.

Chapter 3.4.1: Added a procedure in case the supply disconnection request needs to

be cancelled on the planned disconnection day. Added a procedure in case the




21 (203)


supplier needs to communicate to the DSO that supply may not be connected for a

disconnected accounting point.

Chapters 3.5 and 3.6: Clarified the processes for handling imbalance settlement and

balance deviations.

Chapter 3.5.1: Specified that datahub operator will manage the metering grid area

information in datahub.

Chapter 3.5.1: Figure of data used in imbalance settlement calculation is updated.

Added possible metering grid area types, NBS production types and attributes for

exchange point. Term price area replaced with market balance area. Information

maintained by datahub marked.

Chapter 3.5.1: Added that the DSO will be able to get a report of structural data

through the user interface.

Chapter 3.5.1: Added that datahub will include information about the electric station

and its field that are connected to exchange point.

Chapters 3.5.1 and 4.3.1: Added that exchange point metering data is automatically

forwarded to the other DSO of the exchange point. Metering data is also

automatically forwarded to parties the DSO has authorised to the data. Sequence

diagram in chapter 4.3.1 updated accordingly.

Chapter 3.5.5.2: Added that negative losses are reported to eSett as production of

the loss supplier.

Chapter 3.6: Added information about for whom and on what conditions balance

deviations are corrected and information about how DSO reports corrected metering

data. Subchapters have been re-organized.

Chapter 3.7.1:Added that products and product components can have multiple

names in different languages. Added that grid product prices are public, sales

product prices are only available to authorised parties.

Chapter 3.7.1: Elaborated handling of products' VAT free prices.

Chapter 3.8.2: Added that authorisations between parties cannot be transferred

forward.

Chapter 3.10: Customer access to own information revised completely using

suomi.fi service. Added information about energy consumption report offered to

customer.

Request rejection added to return of information in many requests in chapter 4.

Updated "free form" to "c/o" in address information.Chapter 4.2.1.2: Elaborated the

handling of customer information update request by DSO in datahub.

Chapter 4.2.1.3: New chapter added: Customer information update request by third

party.

Chapters 4.2.1.2 and 4.2.2.4: Cardinality of data has changed in class diagrams.

Chapters 4.2.2.1 and 4.2.2.2: Calculation of connection capacity added to

processing.




22 (203)


Chapter 4.2.2.2 and 4.2.2.4: Elaborated that changed information is relayed.

Chapter 4.2.2.3: Corrected processing of accounting point deletion.

Chapter 4.2.2.3: Added relaying accounting point deletion information.

Chapter 4.2.2.4: Added that also a third party can request accounting point data

update.

Chapter 4.2.3.1: Elaborated the data reported and returned in accounting point

identification request.

Chapter 4.2.3.3: Elaborated the return of sales agreement customer information.

Chapters 4.2.3.3 and 4.2.3.5: Tax category attribute added to the grid agreement in

class diagrams.

Chapter 4.3.1: Added that if the metering responsible party has not been able to

collect the data to their own system, they will report to datahub that the data is

missing. Added to validation that exchange point and production unit metering data

cannot be corrected outside the balance window. Added that metering data is

forwarded using the unit it was reported to datahub with.

Chapter 4.3.3: Added that a unit must be given to active and/or reactive power, data

return based on given unit. Accounting point type added to search criteria. Updated

sequence diagram to present asynchronous request.

Chapter 4.4.1.1: Updated validation rules when current supplier changes the

customers of the agreement so that at least one customer remains the same. Added

reporting an in between agreements sales agreement to rules. Added to rules that

maximum length for a fixed-term agreement for a consumer is 2 years. Added to

rules that only the supplier with delivery obligation may report a delivery agreement.

Added that the reason for agreement end will be same as the reason of the new

agreement start. Elaborated the moving in situation description in time limits. Added

section agreement cancellation. Removed section terminating a reported agreement.

Added that in case of moving in, notification of sales agreement cancellation is sent

to the supplier who has an upcoming agreement with a customer that is not the

customer who is moving in. Added that if a supplier is retrospectively added to an

accounting point which was previously without a supplier, zero time series

according to message DH-523-2 is forwarded to the DSO to replace the consumption

registered in losses, which has been earlier registered to the DSO's system.

Chapter 4.4.1.1: Added the possible customer information update based on the new

agreement and zeroing of consumption registered in losses to the sequence

diagram.

Chapter 4.4.1.2: Product name added to class diagram.

Chapter 4.4.2.1: Agreement identification added to class diagram.

Chapter 4.4.2.3: End time added to class diagram.

Chapter 4.4.3.1: Added information relay to the supplier of the possible related

production accounting point in case of moving out.




23 (203)


Chapter 4.4.3.1: Added that based on moving out, accounting point supplier is also

notified of cancellation of upcoming sales agreement if the upcoming agreement is

not a move in. Added forwarding of sales agreement end to the 3rd parties

authorised to the accounting point data. Sequence diagram updated accordingly.

Chapters 4.4.3.1 and 4.4.3.3: Reason for agreement end and Agreement end date

moved to different level in class diagrams and changed into obligatory attributes.

Chapter 4.5.1.1: Added to starting events that a supplier cancels a disconnection

request on the disconnection date. Accounting point status corrected to

"connected" in information to be reported.

Chapter 4.5.1.2: Added to starting events a supplier's supply request, and a move in

to an accounting point that is disconnected or without a supplier. Elaborated

validation and processing of notification of supply connection.

Chapter 4.5.2.1: Added that on the planned disconnection date the process can be

cancelled with a supply connection request.

Chapter 4.5.2.2: Added to starting events a supplier's supply disconnection request.

Added that if the DSO will not be execute the disconnection requested by the

supplier due to a supply request by the supplier on the same day, the reported

connection mode is "connected".

Chapters 4.5.1.3 and 4.5.2.3: Added that the relayed request must have a reference to

the original request.

Chapter 4.6: Further specified balance settlement time series of suppliers and

metering grid area.

Chapters 4.6.2.1, 4.6.2.2 and 4.6.2.3: Changed imbalance settelement data request

sequence diagrams to present asynchronous requests.

Chapter 4.7: Specified data reported to parties about balance deviations.

Chapter 4.7.1: Added that balance deviation data of the accounting points, whose

balance deviations have caused the balance deviation of the losses, are not reported

to the loss supplier of the metering grid area.

Chapter 4.7.1 and 4.7.2: Added accepting the balance deviation starting conditions.

Chapter 4.8.2: Added that if a party ID is not reported in the request, all product data

that the retriever is authorised to is returned. Elaborated that only accessing

supplier product data required authorisation. Elaborated that product data request

returns product data at the moment of request and the ones coming into force in the

future.

Chapter 4.8.3: Added total invoicing period to DH-730 class diagram.

Chapter 4.8.4: Added information about asynchronous invoice row request to

"Processing" section and sequence diagram updated accordingly.

Chapter 4.9.2: New chapter and event: datahub notifies the party when a customer

gives the party an authorisation in customer portal.

Chapter 4.10.2: Added that if no individual party IDs are given in the party




24 (203)


information request, datahub will return the information of all parties.

Updated the date of source 2.

Figures and diagrams are updated to line with the abovementioned changes.

Added Appendix A: Descriptions of imbalance settlement calculations.

29.4.2016 1.0 First official version




25 (203)

Definitions and abbreviations

Accounting point. A concept related to a physical location, for example, a dwelling, which connects a customer to a DSO and electricity supplier through a grid and sales agreement, and in which the consumption or production of electricity can be measured. In Datahub accounting point is a logical point of delivery.

Authorisation. Permission given by a customer to a party to obtain data about itself from datahub. The party concerned should have proof (for example, a power of attorney) about the authorisation given by the customer.

(Electricity) balance. Hourly (or based on another time step used in imbalance settlement) data specified in an imbalance settlement about the difference in a market parties’ electricity production and acquisition and in its consumption and supply.

Balance deviation. An error that occurs due to a retrospective change of information outside the balance window. The change may be due to inaccurate metering data or supplier information on an accounting point.

Balance information. Information about a metering point that tells which electricity supplier has valid balance responsibility for which time period. With regard to the correction of balance errors, balance data also includes hourly metering data for the above-mentioned time period.

Balance settlement connection. Conceptual data, which connects balance settlement time series to structural data (like metering grid area), to which the balance settlement time series in question is related.

Balancing calculation. A calculation currently in use concerning accounting points that are not hourly read, in which the difference in energy entered in the electricity balance using the type loading curve method set in the Metering Decree and the difference in energy noted in measuring are established. Before starting to use the Datahub, the DSO is responsible for carrying out the calculation. The DSO invoices or refunds the supplier based on the calculation.

Business process. A group of tasks linked to each other, which are done in order to achieve a set target, for example, the switching of a customer's supplier.

Calendar time series. Defines the moments in time when a certain product component (such as day-rate or night-rate electricity) is in effect.

CET. Central European Time.




26 (203)

Closed distribution network. A geographically delimited industrial or trade area or an area with shared services in a distribution network or high-voltage distribution grid that does not primarily supply electricity to consumers. An electricity distribution grid license for a closed distribution grid is granted to an applicant who fulfils the necessary conditions. If a closed distribution grid is treated as a metering grid area in Datahub, then it must have a closed distribution grid license granted by the Energy Authority.

Consumer. Consumer referred to Chapter 1, Section 4 of the Consumer Protection Act (38/1978.) Consumer is a natural person and acquires or produces electricity mainly for a purpose that is not connected to a business enterprise.

Agreement information. Information about a metering point that tells which electricity supplier has a valid sales agreement for which time period.

Agreement process. A market process related to the conclusion and notification of a sales agreement, the maintenance of agreement information, and the termination or cancellation of an agreement .

Corporate customer or company. A customer that is not a consumer. In general, a corporate customer is a customer that acquires or produces electricity as part of business operations. ’Corporate customer’ may also mean, however, some other juridical person, such as an registered association or public body.

Cost pass-through. A measure, in which a supplier or a distribution system operator invoices another party for its services, which the latter then invoices the customer for.

Current supplier. An electricity supplier with which a customer has a valid electricity sales agreement at a metering point connected to a agreement process when the process begins.

Customer. A physical person, company, association or other community e.g. municipality with a agreement for electricity sales, electricity supply and/or electricity purchasing with a supplier and/or a grid agreement with a DSO and which acquires or produces electricity mainly for its own use.

Datahub (system) is a centralised information exchange system for the electricity retail market described in this document.

Datahub event. An event, in which Datahub receives and processes a message from a party and forwards messages to other parties.

Data interface. Machine interface, through which parties can retrieve the information they are authorised to.

Data standard. Separately published Excel spreadsheet, which includes accurate attribute and relation specific definitions for Datahub.




27 (203)

Delegation. Permission given by a supplier or DSO to a another party to obtain data about itself from datahub or act on behalf of it in datahub.

Delivery agreement. An electricity supply agreement is a agreement between a supplier and a customer, in which the supplier also assumes responsibility for the grid service. If necessary, the seller agrees with the DSO on the grid service.

Dissolving a agreement . The immediate unilateral dissolving of an agreement as a result of breach of agreement by one party or some other occurrence entitling the party to dissolve it.

Distribution Network. Electricity grid, which nominal voltage is lower than 110 kV.

Distribution system operator (DSO). A distribution grid owner, who is responsible for the distribution grid or the high-voltage grid and who has licenced electricity market activity in the respective grid. DSO’s within the balance settlement of the centralised information exchange are the ones who have electricity market activity in the distribution network stated in the Energy Market Act and whom have granted the grid license for the distribution network or closed distributed network. A Distribution Grid is the electricity grid, which nominal voltage is lower than 110 kV (nominal voltage is defined in the grid license)..

Distribution system operator of a closed distribution network. The DSO of a closed distribution network is a party that has received license from the Energy Agency for a closed distribution network for the area. If the area is treated as a Metering grid area in Datahub, then that party is the metering responsible party for this metering grid area. The same rules apply to the DSO of a closed distribution network in supplying information to Datahub than for the DSO.

ebIX is short for the European forum for energy Business Data eXchange. A European organisation, which develops information exchange for the energy sector.

Electricity Market Act. The most significant legislation regulating the electricity market (588/2013).

eSett. Balance settlement unit. A service company owned together by Fingrid, Statnett and Svenska Kraftnät which is in charge of the operative action in Nordic imbalance settlement.

Exchange point. A point on the border between two meteringy grid areas at which the transmission of electricity between these grids is metered or otherwise specified.

Exchange point metering. Metering that meters the the transmission of electricity between two metering grid areas.

Fingrid Datahub Oy. Fingrid Datahub Oy is a fully owned subsidiary of Fingrid Oyj, established to take care of the operational tasks of the centralised information exchange




28 (203)

system, datahub.

Finnish Energy (ET) is an organisation for the industrial and labour market policy of the energy and district heating sector.

GLN (Global Location Number). A GS1 system code that specifies a party in Datahub. A GLN code is a 13-character code, which comprises a GS1 company ID, freely selectable numbers (3-5 of them) and a control number.

(Electricity) grid agreement. An agreement between the DSO and customer regarding the grid service the customer requires.

Grid service product. An electricity product used by the DSO in the grid service.

GS1. An international organisation that distributes individual organisation-specific codes. Finland’s country code is 64. The country code and company-specific ID linked to it granted by GS1 Finland Oy’s customer service is called the GS1 Company Prefix. With the company ID, it is possible to form other codes, such as GLN and GSRN codes.

GSRN (Global Service Relation Number). A GS1 system code, which specifies a metering point in Datahub. A GSRN code comprises of a GS1 company code, a serial number and a control number.

High voltage network. Local or areal metering grid or power line with nominal voltage of 110 kV and is not a service line and does not exceed national borders.

Hourly data. Metering data where the time interval is an hour.

Hourly metering. Refers to the hourly metering (by hourly time steps) of electrical energy and registering the measured data in the memory of metering equipment.

Imbalance settlement window. A period during which changes can be made to hourly data before the closing of the electricity balances.

(Metering grid area) imbalance. The difference between the consumption (including losses) and production and the energy transferred in exchange point to/from metering grid area. If the information reported to imbalance settlement is correct then the imbalance is zero (0). Imbalance has to have a supplier and the imbalance is handled in the suppliers balance responsible parties consumption imbalance.

Imbalance settlement. Refers to settling the electricity transactions made during each imbalance settlement period. As a result of this settlement, the electricity balance and imbalance of each electricity market party can be determined.

(Distribution grid's) imbalance settlement. An imbalance settlement concerning a metering grid area or areas, as specified in the Electricity Market Act and Metering




29 (203)

Decree.

Market balance area. A geographical area, for which the electricity market defines a common price for each moment in time (i.e. a price time series). Market balance area consists of metering grid areas.

Market Party. A company acting in one ore more roles in the electricity retail market. Market parties are distribution system operators, suppliers, balance responsible parties, balance settlement unit and third parties. Market Party needs a service agreement with Datahub.

Messaging decree. A decree concerning the information exchange regarding settlement of electricity deliveries. The decree was given by the Council of State based on Electricity Market Act.

Meter. A device or combination of devices, which registers the consumption or production of electricity. A meter might also include an integrated or separate control device, which can control electrical devices at a metering point or, for example, other indicators in an apartment block.

Metered data responsible MGA. Metering grid area, which exchange point is connected to and which is the grid area of the metered data responsible for the exchange point in question.

Metering data. Data produced by a meter or estimated/calculated by a DSO that is connected to a single specific time period in a metering time series, and on which imbalance settlement or customer invoicing is based.

Metering decree. A government decree prescribed under the Electricity Market Act, concerning the clarification and metering of the supply of electricity.

Metering grid area. The Metering grid area refers to the main grid, the high-voltage grid, the distribution network, the closed distribution network or a part of these, or the internal electricity network of the property or similar property group, which forms its own balancing area in the imbalance settlement. The metering grid area is delimited from other metering grid areas with exchange measurement.

Metering point. A point at which the consumption, production or transmission of electricity can be specified. This specification may take place by metering, based on assessment or based on calculation. A metering point may also be an accounting point, exchange point or production unit. A metering point has two translations in Finnish terminology. For this reason the term accounting point is used to separate the entity defined in e.g. in agreements from the entities where energy products are measured or computed.

Metering register. A logical or physical entity contained in a meter, which registers a certain measurement parameter, such as the output of active power, or the input of




30 (203)

reactive power from the grid. The register may include hourly data or cumulative readings from reading measurements.

Metering responsible party. A party, which is responsible for the collection of metering data from a certain metering point and for reporting it to Datahub. For accounting points, this party is always the distribution system operator (DSO). Metering grid area has to always have a metering responsible party that is responsible of the imbalance settlement of the metering grid area.

Metering (time series). A concept, that refers to metering data and related metadata, such as time series identification, connected to certain metering point (accounting point, exchange point or production unit). Metering time series are time series and their metering data is based businesswise on data registered by electricity meters, usually electricity consumption or production. Metering time series are sometimes called meterings, for shorter reference.

Metering time stamp. Information related to metering data that tells the time for which the metered energy is registered.

Move-in location. A metering point to which a customer is moving in.

Move-out location. A metering point from which a customer is moving out.

NBS (Nordic imBalance Settlement). Nordic harmonized imbalance settlement model which is operated by imbalance organisation eSett Oy. The rules of the imbalance settlement model are described in NBS handbook, which is maintained by eSett.

New supplier. An electricity supplier, which initiates an agreement process for a certain metering point. A new supplier may also be the current supplier of the metering point.

Open supplier. A market party that supplies its customers with all the electricity they need, or balances the customer’s production and acquisition of electricity and the difference between its use and supply, by supplying the amount of electricity that is lacking or by receiving the surplus during each hour (in connection with this, contrary to the above ‘customer’ may also mean ‘operator’).

Parallel MGA. Metering grid area, which exchange point is connected to and which is not the grid area of the metered data responsible for the exchange point in question.

Preceding supplier. A supplier of electricity whose sales agreement has ended at the metering point as a result of a new sales agreement reported by the new supplier.

Price time series. Defines the price of a certain product component for each regular time interval (for example each hour).

Processing of balance deviations. A process in which a monetary supplier- and metering grid area-specific correction is carried out after the closing of the balance settlement




31 (203)

window, as a result of corrected metering errors and balance information.

(Electricity) product. A sales or grid service product.

Product component. A part of an electricity product that is used to invoice a certain part of the total service.

(Accounting point's) Production device. Information about a device installed at the accounting point that can be used for producing electricity, and the device's properties.

Production unit. A concept used in the Nordic Balance Settlement, which relates to production information dealt with on the production imbalance side.

(Market) process. A business process between market parties which concerns the exchange of information between the market parties. The processes include agreement processes, such as moving or supplier changes, the delivery of metering data and imbalance settlements.

Profile. An (hourly) time series based on metering data used in imbalance settlement or an annual usage estimate, which comprises those measuring points at which electrical consumption, production or transmission are not registered hourly (or through another time step used in imbalance settlement).

(Electricity) purchase agreement. An agreement by which the customer sells and the supplier buys the customer’s small-scale production of electrical energy.

Reading (or meter reading). A cumulative reading registered by metering equipment.

Reading metering. Metering that registers cumulative readings.

Regional network operator. DSOs who are responsible for the high-voltage grid (above or equal than 110 kV) and has a high voltage grid in its possession and who has licensed electricity market activity in the respective grid.

(Accounting point's) Remote controlled load. Information about a remote controlled load (electric device) installed at the accounting point and its properties.

(Electricity) sales agreement. An agreement by which the customer buys and the supplier sells electrical energy. Electricity retail sales are regarded as the sale of electricity through the distribution grid directly to users of electricity or indirectly to users through the internal grid of a property or a corresponding group of properties.

Sales product. An electricity product used by an electricity supplier in its own service.

Service provider (third party). Service provider that needs the information from the datahub with the customer authorisation. Alternatively, the service provider operates in




32 (203)

Datahub with a delegation by another market party.

Small-scale production grid service agreement. A separately made agreement between the DSO and customer concerning the supply of electricity to the distribution system operator’s grid.

Small-scale production. An entity formed by a small-scale production unit or several production units, which is dealt with on the consumption balance side in the imbalance settlement. At present, on the consumption balance side, production units are dealt with that have a nominal capacity of up to 1 MVA.

Status of metering data. Refers to the status registered for hourly data that illustrates to the recipient how reliable the collected data is. Metering data statuses used include "missing", "uncertain", "estimated", "OK" and "corrected OK".

(Accounting point's) Storage unit. Information about an electric device installed at the accounting point that can be used for storing electricity, i.e. charging and discharging, and the device's properties.

(Electricity) supplier. Any person, organisation or company that sells electricity or buys it (in this context, small-scale or production unit’s customer production).

(Electricity) supply. Refers to the delivery of electricity to be used or resold.

System operator. A trader who is in control of the power grid and is engaged in licensed electricity grid operations on this network.

Terminating an agreement . The termination of an agreement by one of the parties in accordance with the terms and conditions specified in the agreement .

Time step. Data that indicates to what level of time accuracy a meter registers metering data. The current time step used in imbalance settlements is one hour. At the time of writing, studies are underway to move to 15 minute time steps in imbalance settlements.

Transmission product. see Grid service product.

Transmission system operator (TSO). Responsible party of the main Grid, Fingrid Oyj.

Unit of centralised information exchange in electricity retail market. Transmission system operator Fingrid Oyj’s subsidiary Fingrid Datahub Oy, that operates the centralised information exhnage in electricity retail market. Company can use also abbreviation Datahub.

(Metering data) validation. Refers to verifying the quality of metering data collected from remotely read metering instruments. It usually takes place in the metering data management or reading system. Typical validations include verifying that data is missing, verifying negative values, verifying an unusually high hourly output and verifying long




33 (203)

series of zero values.




34 (203)

1 Introduction

1.1 To readerDuring 2014 Fingrid carried out a study concerning a future solution for the exchange of information on the electricity retail market. The study recommended the establishment of Datahub in Finland. The Ministry of Employment and the Economy examined the study during the spring, and in a letter dated 8.4.2015 the ministry requested Fingrid to initiate the implementation of the centralised information exchange solution described in the study.

The market processes in Datahub and its technical interface descriptions have been defined in close co-operation with the industry in the autumn of 2015. The processes have been supported by working groups from industry representatives appointed by the Finnish Energy Industry.The entire Electricity retail market business processes in Datahub document was sent to the industry for comments and after examining the comments the final documentation was completed and published 21.3.2016, after which the document was translated into English.

Close cooperation with the industry has been a fundamental prerequisite for the success of the specification work and for cost-effective operations. Work group members have also formed an important link between the process work and the industry, bringing the industry's wide range of both perspectives and skills to the task at hand.

As the Datahub project progresses there is a Process Group to support the project team consisting of representatives of suppliers and DSO’s. The main task of the Process Group is to support datahub project in handling changes suggestions to datahub business processes and data exchange specification documents effectively, equally and taken into account the multiplicative effects of the possible changes into industry. The work of the Process group can be followed in more detail in the Fingrid's EDIELfi portal, which describes all the project teams.

1.2 Legislation supporting DatahubIn accordance with the Electricity Market Act in force, the System Operator's TSO, ie Fingrid Oyj, is responsible for developing the information exchange required for electricity market and balancing in its area of responsibility in cooperation with electricity companies.

In addition to the aforementioned, Fingrid Oyj is responsible in its area of responsibilities for the centralized organization of the information exchange required by the market processes and the balance settlement in distribution networks. These services of the centralized information exchange unit (Datahub services that are described in chapter 1.2.2) are clearly listed and limited by the Electricity Market Act. Fingrid Datahub Oy, a wholly




35 (203)

owned subsidiary of Fingrid Oyj, will manage the operational operations of centralized information exchange services.

In order to make the interpretation of the law and its connection with the defined business processes clearer, the Datahub services, responsibilities and responsibilities for the different market parties, as well as who are bound by the Datahub services, are also described in the following chapters of this document.

1.2.1 Datahub services

The electricity market act defines the services that Datahub has to provide for the market. Those services are the business processes defined in this document.

The services defined by law for Datahub are:

1. Maintenance of customer and accounting point information from the retailer and the Distribution system operator later DSO.

2. Arranging the information exchange between the retailer and the DSO in agreement processes.

3. Arranging the information exchange of metering data used in balance calculations and invoicing

4. Arranging the information exchange of connection and disconnection processes of electricity transmission and delivery

5. Arranging the maintenance of product and invoice line information of the DSO and arranging the maintenance of product and invoice line information of the retailer

6. Forwarding the market party information of the retailer and the DSO7. Arranging the access to retailers and DSO’s customers to his own data placed in the unit

for centralized information exchange on electricity retail market8. Imbalance settlement calculation of the distribution network and arranging the

information exchange related to imbalance settlement9. Storing the data needed in covering services 1-8

1.2.2 The data stored in the Datahub and assigning of it

As mentioned in the previous chapter, storing data in the Ddatahub is one of the Datahub services. The business process definitions take into account the legal requirements related to data protection and therefore only the data needed for business processes is stored in the Datahub. Chapter 2.3 of this document describes in more detail how long the data will be retained and how the data will be deleted after this retention period.

The data from Datahub is assigned to market parties only according to rights based on valid agreements or based on authorization granted by the customer. Authorizations are described in more detailed in chapter 3.8.3.9.

Data protection principles in the Datahub are described in more detailed in chapter 1.5.




36 (203)

1.2.3 Market parties that are using Datahub services

The Electricity Market Act unambiguously defines which electricity market parties are obliged to use datahub services for the exchange of information on the electricity retail market.

A Retailer and a Distribution System Operator (DSO), who have electricity market activity in the distribution network, are obliged to use the Datahub services for the exchange of information on the electricity retail market. A distribution network is the electricity grid, which nominal voltage is lower than 110 kV (nominal voltage is defined in the grid licence). A DSO is the distribution grid owner, who is responsible for the distribution grid or the high-voltage grid (above or equal than 110 kV) and who has licenced electricity market activity in the respective grid. The DSOs, to whom have granted the grid license for the distribution network or closed distributed network (nominal voltage is lower than 110 kV), are obliged to use the Datahub services. Similarity for these networks is that they need to have the metering/accounting points, which electricity market processes needs to be organised in uniform and equal way.

The DSOs who are responsible for the high-voltage grid (above or equal than 110 kV) are not within the Datahub services. The metering responsible parties for the metering grid areas without the grid licence (e.g. industrial and production MGAs) are also not within the Datahub services.

1.2.4 Duties and responsibilities of parties

The Electricity Market Act describes the duties and responsibilities of Datahub and marketparties using datahub services.

As explained in the previous chapter, a Retailer and a DSO who have electricity market activity in the distribution network must use Datahub services for the exchange of information on the electricity retail market. An essential aspect of the Datahub's business processes is that the marketparties are also responsible for the accuracy of the information they provide to the Datahub and for the rapid correction of any errors. Datahub does not check on the accuracy of the provided information, but verifies that the information provided includes all the information required for the process and that the information provided is in the correct format.

Market parties have to also take care of that the information systems and the information systems used to information exchange they use work compatibly against Datahub.

Datahub is responsible for arranging the aforementioned services and storing the information provided by the Retailers and DSO’s involved, as well as providing the information exchange for the Datahub services ie. the business processes described in this document. Some of the responsibilities from the DSO will be transferred to Datahub's responsibilities, such as making the DSO’s imbalance settlement calculations.




37 (203)

One of the responsibilities of the DSO for datahub is the reporting of electricity consumption data to the end customer. Datahub will provide customers the opportunity to view their own information on a customer portal for this purpose. For more details see chapter 3.11.3.12.

1.2.5 Degrees supporting the Electricity Market Act

The new Electricity Market Act will supported by the electricity market degrees of ‘Valtioneuvoston asetus (VNA) sähköntoimitusten selvityksestä ja mittauksesta' which more specifically describes the roles and responsibilities of the parties in terms of electricity supply and balance settlement and ‘Työ- ja elinkeinoministeriön asetus (TEMa) sähkökaupassa ja -toimitusten selvityksessä noudatettavasta tiedonvaihdosta’ which describes in more detail the notification procedure for electricity supply.

The content of these degrees are scheduled to be updated under 2019.

1.3 Development in retail market information exchangeThe most important improvements and changes Datahub will bring compared with existing information exchange are set out below.

Centralised synchronous information exchange

Datahub will result in a transition to centralised information exchange from current information exchange, which involves the exchange of information from market party to market party based on telecommunications operators. In the future, all data will be reported to Datahub, where it will be processed and forwarded on to other market parties entitled to the data. The most significant difference to the current practice is that all information exchange will take place via a single point, enabling all of the improvements to the existing practice that are set out in this section.

One of the most significant developments offered by Datahub is the transition from the existing asynchronous information exchange, which is based primarily on batch processing runs, to synchronous information exchange. In practice, this means that Datahub will respond immediately to an market parties notifications. For example, in the future a supplier will not have to wait for confirmation from a DSO after reporting a sales agreement; instead the information about the agreement's approval or rejection will be returned to the supplier in real-time directly from Datahub. Together with carefully compiled processes, this feature will reduce the need for clarification between parties. Possible problems with new agreements can be handled immediately with the customer during the same customer contact.

Consistent customers in grid and sales agreements




38 (203)

Customers often differ from one another in current grid and sales agreements. A couple can take out a sales agreement together while a grid agreement is only in the husband's name. There is a strong view in the industry that these agreements should be consistent with regard to customers in order to avoid various problematic situations.

In practice, the achievement of this target requires uniform agreement practices. In the future, DSOs will receive notification of a sales agreement made for an accounting point and the customers linked to it. The DSO will draw up its own grid agreement for the accounting point with the customers involved in the sales agreement and confirm the grid agreement in Datahub. This operating method ensures that future grid and sales agreements will pertain to the same customers.

This method is in line with Finnish Energy's current valid procedural guidelines, meaning that the customer should always be directed to contact the supplier first. This method also requires that new agreements are always drawn up for customers of full legal capacity. DSOs cannot be required to act in a manner which conflicts with this principle. Corporate customers' business ID numbers and consumer customers' personal identification numbers must always be given in new agreements. Exceptions are only permitted in those cases wherein an individual does not hold a Finnish personal identification number.

Transfer of distribution system operators' imbalance settlement to Datahub

With the introduction of Datahub, DSOs' losses and supplier-specific total deliveries, which are currently calculated and announced in imbalance settlement by the DSO, will be calculated in Datahub. Datahub also calculates supplier-specific corrections to balance errors and notifies the DSO of supplier-specific balance errors for supplier invoicing. Thanks to Datahub, there is no need for the DSO to carry out the aforementioned calculations in its own system, nor does it have to maintain data on accounting point suppliers for imbalance settlement calculations. Datahub will submit the necessary imbalance settlement data to eSett and with regard to the retail market, market parties will contact Datahub rather than the eSett system in matters concerning DSO’s imbalance settlement.

Suppliers and DSOs can monitor their own imbalance settlement data, including total delivery data and balance error data via the Datahub interface. Datahub also reports accounting points without suppliers to DSOs so that the DSO can disconnect electricity to these accounting points.

Increasing the effectiveness of supervision

In current information exchange, situations arise wherein market parties do not always act in accordance with agreed rules. Supervisory tools will be created in Datahub to help supervise operators' actions. The aim of supervision is to collect material with which to indicate any possible misuse and breaches of agreed rules and thereby to intervene in such behaviour.




39 (203)

Exchange of product and invoicing information

Current messaging is not used to exchange accounting point specific product and invoicing information. Datahub allows for the maintenance and information exchange of sales and transmission products. This means that market parties can take into account a product selected for an accounting point by another party, such as a supplier or DSO, in its own product selection and therefore offer uniform products to customers with regard to both the transmission and sale of electricity.

Datahub also allows for invoicing rows to be relayed. Market parties can, if they wish, report invoicing rows to Datahub, where they can be retrieved by the accounting point's supplier, DSO, or any third party authorised to invoice rows. This will facilitate the utilisation of various invoicing service providers in business operations and offer customers a single invoice containing the grid service and energy sales.

Utilisation of service providers

Datahub will facilitate the utilisation of various service providers in market parties’ business operations. Standardised interfaces and a centralised information exchange solution reduce information exchange costs as service providers, or third parties, do not need to arrange data communications connections separately with each market party.

Comprehensive and high-quality data content

In connection with the specification of Datahub processes, all data required by market parties’ business operations that should be exchanged between suppliers, DSOs and third parties was mapped. This signifies a broadening in the data content to be exchanged in comparison with current information exchange. In the future, data concerning e.g. the remote connection possibilities for a given accounting point will be available in the accounting point data.

The quality of the data will also be higher in Datahub than it is currently. Validation and supervision will be built into Datahub to prevent insufficient data and data which is not in the correct technical format from being stored and transmitted. The most significant improvements will apply to the maintenance of codes which uniquely identify customers (personal identification numbers and business ID numbers), to metering data and to address information.

Metering data based on continuous metering

Finland has made the transition to comprehensive hourly metering and the number of remaining traditional reading metering is continuously decreasing. Datahub's functionalities are specified such that the special processing of reading metering is only taken into account where absolutely unavoidable.

As a result of Datahub, information exchange will not support the transmission of cumulative readings. DSOs must form accounting point specific hourly time series Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



40 (203)

concerning reading metering and unmetered locations for imbalance settlement and data transfer. One should notice that after datahub deployment a separate balancing calculation for reading metered sites will not be executed.

Datahub will also support imbalance settlement period for 15-minute.

Support for statutory reporting

Comprehensive data pertaining to accounting points, customers and agreements will be imported into Datahub. This data content can be utilised in the generation of operators' statutory reporting.

Services for third parties

Datahub facilitates business operations for various service providers. It will be possible for a third party authorised by a customer, supplier or DSO to obtain accounting point-specific and customer-specific data, including metering data, from one and the same place. For this reason 3rd parties must make an agreement with Datahub which obligates the party to comply with agreed rules.

A more customer-oriented service

All of the aforementioned developments aim at a more efficient and more customer-oriented service. Datahub's agreement processes reduce errors and problems and the customer experiences the result as better service. The aforementioned services for third parties will also increase the range of various customer services. The principle is that Datahub acts as a shared background system for the industry which allows companies in the field the opportunity to offer their customers better customer service.

Development of business operations

Datahub will also play a significant role in the development of various business operations. Public discussion increasingly highlights different visions for the future of the electricity retail market. Key themes in this discussion include consumers' demand response, electric car recharging, and various energy efficiency and management services. Datahub will allow for and aid the development of various new services and their required information exchange.

1.4 Business operations in the Datahub environmentMarket parties have different roles in the Datahub. The roles are divided at the top level to match the role model used in EDIEL-based information exchange. With the introduction of Datahub, these roles used in the current information exchange will be divided in the system Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



41 (203)

to a more precise process level, according to the information exchange processes, based on the ebIX role model. ebIX is a European forum for energy Business Information eXchange. This role model aims to create a common terminology and this way to also facilitate system development. This role model has also been used in other Nordic datahub projects, so bringing it to the Finnish retail market also supports Nordic electricity market harmonization.

The ebIX role model recognizes all the roles that can be used in the electricity market in Europe. The model includes both the wholesale market and the retail market. It is not appropriate to use all the roles of ebIX in Datahub, but only to the extent appropriate to support the defined market processes. The ebIX roles are logical in nature, such as the Balance Responsible Party. More detailed descriptions of the ebIX role model can be found on the ebIX website at https://www.ebix.org/artikel/role_model.

For example, a more detailed breakdown of the roles in the Datahub enables the allocation of access rights according to a particular purpose. The role model can be used to link privileges to a specific piece of information or to perform certain processes or events.

Current developments seem to change the behaviour of market parties in a way where the market parties use widely their company networks and service providers to implement their own operations. Datahub will support this trend by enabling the use of more specific roles and thereby facilitating the provision of market parties’ assignments to service providers for a specific predefined task. For example, a Distribution System Operator may delegate a party providing metering services to deliver the metering data into Datahub on its behalf. In this case, the delegation is done by given the service provider a certain role, according to which the access rights, the rights to send the event and the rights to Datahub for that specific event are defined. The following chapters summarize by their roles how datahub will change operators' daily business.

[1.4.1] The following chapters summarize by their roles how datahub will change operators' daily business. Suppliers

Suppliers' primary tasks in Datahub are the initiation of agreement processes and the maintenance of customer information. Agreement processes include reporting new agreements as customers move home and switch suppliers, changes to agreements during delivery and the ending of agreements .

Datahub enables suppliers to provide increasingly customer-oriented and customer-friendly service. For example, a supplier authorised by a customer canA supplier gets a sufficient amount of information when requesting the basic information of the accounting point in order to make the sales agreement with the customer. Furthermore with the authorisation given by the customer the supplier can check valid accounting point, grid service product1 and metering data before drawing up an agreement . In this way, the supplier can tailor the sales agreement to the customer.if deemed necessary. Before reporting an agreement, the supplier can also check

1 including detailed information on the allocation of time at a product component-levelFingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code


https://www.ebix.org/artikel/role_model


42 (203)

with authorisation form the customer, whether the customer has for the accounting point a valid fixed-term sales agreement or a sales agreement containing exceptional termination conditions which could prevent the creation of a new agreement. The supplier cannot, however, be authorised to obtain detailed information for an accounting point for which its customer does not yet have an agreement. This refers to e.g. an accounting point to which the customer is moving. The supplier can also check the accounting point's connection status and notify the customer of any possible connection fees in the event of a quick move-in. More real-time information exchange will reduce various problems and related investigative work, which will improve the customer's service experience.

Nowadays suppliers also face the challenge of deciding whether they are dealing with a change of supplier or a customer moving in. Reports sent using the wrong code always require manual processing. In the future, the supplier will not have to make such decisions, as Datahub will always contain information on the customer situation at the accounting point and Datahub returns the reason for agreement start to the Supplier in the acknowledgement of the sales agreement notification.

In the ebIX role model, the supplier has no other role than the Balance Supplier, who is responsible for the electricity agreement with the customer and, within the framework of the agreement, for the sale of electricity, or for a small production site, for the purchase of electricity.

1.4.1[1.4.2] Distribution system operators

Distribution system operators' (DSO) primary tasks in Datahub include the maintenance of accounting point, grid agreement and grid agreement product data, as well as the maintenance of structural data required for imbalance settlement, such as exchange points and production units. In addition to the aforementioned, a DSO must also report metering data to Datahub on a daily basis, whereupon the data will be transmitted to the entitled parties. Although the status of metering data and its use are also validated in Datahub, the DSO will continue to be responsible for the accuracy of metering data. As such, DSOs must continue to carry out their own metering data validation in the future.

As a result of the change brought by Datahub, a DSO can, if desired, move away from carrying out its own imbalance settlement, balance error/balancing and loss calculations. Invoicing for balance errors will still be carried out by DSOs even though the calculations take place in Datahub. As a result of the implementation of Datahub, the significance of accounting point-specific supplier data to the DSO will decrease but not disappear entirely. There will continue to be situations in the future wherein the DSO should directly contact the accounting point's supplier, though this should occur less than is currently the case. The DSO will continue to receive information about completed new sales agreements and the accounting point's supplier for drawing upmaintaining its own grid agreement and for information, e.g. concerning the connection situations. As a result of improved information exchange, the need for clarification of various problematic situations with customers and suppliers will also decrease for DSOs.




43 (203)

The transmission of metering data takes place via Datahub, meaning that the DSO does not need to agree separately on the transmission of data with all parties. This especially concerns metering data transmitted to third parties and the management of authorisation from their customers. Datahub's customer portal, described in chapter 3.11, will cover the DSO's current statutory obligation to report metering data to customers.

In its role, the Distribution System Operator is responsible for more information and therefore has n several ebIX roles. In the role of Grid Operator, the DSO is responsible for the Metering Grid Area data, the Metering Point Administrator is responsible for the accounting point information.. In the role of Metered Data Responsible, the DSO is responsible of the metering data and in this role the metering data is delivered to Datahub. Other roles for the DSO areis Grid Access Provider, in which takes care of the Grid agreements with the customer and is responsible for the information of the accounting point.

If needed, the DSO may use a service provider to handle different processes, for example, the role of the Metered Data Responsible. In this case, the service provider may provide the metering data to Datahub on behalf of the DSO. However, the DSO maintains responsibility for the information provided.

1.4.2[1.4.3] Customers

From the customers' perspective, Datahub will primarily be a background system used by electricity retail market parties and its use will not be visible to the customer while transacting with the supplier or DSO. The customer will experience the implementation of Datahub and renewed market processes as improved customer service and quicker processing times for agreement events. Datahub allows for the customer to take on a more active role as an electricity consumer and producer. In particular the increased availability of information to third parties with customer authorisation will increase the number of different services offered to customers. Datahub allows for more comprehensive services relating to a customer's own electricity use and the overall perspective offered to customers, even in situations wherein a customer's multiple accounting points are covered by different suppliers or are located in metering grid areas managed by different DSOs.

The customer will have the opportunity to check its own information stored in Datahub using the customer portal. Customer log in to the service will be implemented through national Suomi.fi service maintained by Väestörekisterikeskus. The service provided by Datahub will cover DSOs' current statutory obligation to report to its own customers. The customer can add and remove third-party authorisations for its own information using the service, and can also check individual data retrievals carried out by the authorised parties in Datahub. . According to the Electricity Market Act and the current data protection regulation consumer customers the authorisations are only maintained by the customer himself/herself in the portal.The authorisation issued by the customer will be accounting point-specific and time-restricted. In order to safeguard the customer's interests, open-ended authorisations will not be permitted and an authorisation will only be valid for a maximum of two years at once.




44 (203)

In the ebIX role model, the customer has its own role as Party Connected to Grid.

1.4.3[1.4.4] Third parties

As set out above, Datahub will facilitate third parties' business operations as a result of the increased availability of information. Datahub will require third parties to sign a service agreement. The service agreement will specify the service for which the party may use the information and the terms of use of the service. A third party acts always with customer authorisation. or with suppliers or DSO’s delegation. Authorisations are described in more details in chapter 3.8. In general, a third party can be any party registered with Datahub, which holds an agreement with a Datahub operator. As such, a supplier or DSO that otherwise would not be entitled to access a customer's information may act in a role as a third party.

As mentioned earlier, the DSO may assign the delivery of the metering data to Datahub for a service provider, whereby the service provider acts as a Metering Data Collector. The Third party can also provide the service directly to the customers, thus acting as an Energy Service Company. In such a role, the Third party must have the customer’s authorization given to the customer's information. The Third party may also act in the role of a Billing Agent acting either on behalf of the Supplier or on behalf of the DSO. In this case, the supplier or the DSO can, for example, forward the invoicing row information to the Third party who handles the customer invoicing on its behalf. In this role the Third party can also make other service to the parties than the invoicing service.

1.4.4[1.4.5] Datahub operator

Datahub will result in the creation of a new market party on the electricity retail market. The primary task of the Datahub operator is to maintain the Datahub system and to provide technical support to operators' main users. Other tasks include the provision of general Datahub guidance to the industry, the supervision of compliance with the terms of Datahub's service agreements and agreed rules, investigative work required by various market parties concerning errors and problems, and the development of Datahub and information exchange in close cooperation with the industry.

In the ebIX model, the Datahub operator does not have a direct role in the information exchange. When Datahub does the distribution grid’s imbalance settlement, will the ebIX role Metered Data Aggregator become the role of the Datahub as well.

1.5 Data protectionAn essential part of managing customer and accounting point information is the protection of information belonging to individuals registered with Datahub. This refers to the protection of people's private lives. The design of Datahub and market processes was carried out on the premise that all information that can be linked to a customer is personal




45 (203)

information. This information is personal information regardless of whether the information can be linked to an individual person in Datahub. For example, the address of an accounting point is personal information regardless of whether the name of the person or a person's identification number is stored in Datahub. What makes the accounting point address personal information is the fact that the customer's address is relatively easy to find out. This also applies to situations in which the customer does not live at the accounting point address.

Market processes are designed in such a way that only information necessary for market processes is stored in Datahub, and parties may only search Datahub for information or receive relayed information in accordance with their predefined permissions. These permissions depend on the party's role, agreement status and existing authorisations.

1.6 Process mapThe following picture shows an upper-level process map of the processes specified during process work. A more detailed level process map is attached to this document.




46 (203)




47 (203)

FIGURE 1 PROCESS MAP

1.7 The content of this documentChapter 2 depicts the requirements that market processes place on Datahub's internal data model and provides descriptions of master data sets. It also outlines each Datahub party's rights to information.

Chapter 3 outlines the electricity retail market's business processes and operating models supported by Datahub. This description contains principles and rules as to how parties search for information in Datahub and report information to Datahub, and how data is relayed to other parties as part of market processes. The outline contains descriptions of entire processes from the parties' business perspective. The more detailed enevt descriptions are described in document Datahub Events, which has also been published in EDIELfi portal.




48 (203)

1.8 How to read UML descriptionsThis document uses activity diagrams to describe business processes. The flow of market processes is depicted using sequence diagrams and the data content of reports and other descriptions of data models are depicted using class diagrams.

When interpreting this document, please remember that although UML notation is largely standardised, this does not mean that UML models are completely closed to interpretation. Large entities can always be modelled from various perspectives and UML is often used for a wide range of applications (e.g. software development vs. business processes) which require different kinds of interpretation. Some individual diagrams in particular may only present part of the background entity. There are always a number of alternative methods to present matters and there is always room for interpretation. This document does not aim at the highest level of orthodoxy from a UML-technical specification viewpoint, but instead aims to present matters in the most illustrative and understandable manner as possible.

MagicDraw software (No Magic Inc.), which is the same as the software used in Nordic Energy Regulators' harmonisation project and in ebIX, was used to create diagrams and models of the electricity retail market in this document. Below is a short introduction to interpreting UML diagrams. More information about UML can be found online, especially in English. Wikipedia2 and the http://www.uml-diagrams.org website, to name just two examples, were used in the making of this document. More information and a link to official UML documentation can also be found on the UML website run by Object Management Group, which manages UML development.3

1.8.1 Common notation

Text written inside <<>> marks is known as a stereotype, the purpose of which is to further define the type of object to be modelled (e.g. an entity or relationship). This document strives to use stereotypes in a manner that is as illustrative as possible in order for them to be self-explanatory.

Any type of line between two objects to be modelled denotes a relationship of some sort. The relationships used in this document are set out in the table below.

2 http://en.wikipedia.org/wiki/Unified_Modeling_Language

3 http://www.uml.orgFingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



49 (203)

TABLE 1 UML RELATIONSHIP TYPES USED IN THIS DOCUMENT

Type of connection Definition

Generalisation: The object to which the arrow is pointing is a generalisation of the source at the tail of the arrow.

Association: a relationship between two objects that has an equivalent in reality. If there is an arrow at the end of a line, in this document it denotes the direction in which the relationship is read, (e.g. "includes").

Composite aggregation: the entity on the end without a diamond is an essential part of the entity with a diamond. For example, customer details are an inseparable part of an agreement.

Dependency: The source is somehow dependent on the object. In this document, this type of relationship is always used with a specifying text or stereotype.

1.8.2 Class diagrams

Class diagrams consist of "entities", the relationships between the entities, and the data contained within the entities. An entity represents a certain physical or logical (data) entity. Examples of entities include accounting point and sales agreement. Examples of entities occurring in messaging are shown in the picture below.

The names of the entities are written in bold at the top of the box describing the entity.

The entity's attributes, or data fields, are listed below the line underneath the name. The square brackets following the attributes define the attribute's multiplicity, or information as to how many values a data field can or will contain. For example, [0..1] means that the field is optional (or only compulsory in certain situations) and [1] means that the value is compulsory. If there can be an unspecified number of values, the * sign is used. The same kind of notation is also used to denote relationships between entities. For example, in the picture below there is not necessarily a sales agreement for an accounting point. This is marked by writing 0..1 at the sales agreement end of the relationship between these two entities. If no multiplicity value is given separately at the end of a connection, the multiplicity will by default be 1.




50 (203)

FIGURE 1 EXAMPLE OF A CLASS DIAGRAM

1.8.3 Sequence diagrams

Sequence diagrams depict the progress of a process and, in particular, the exchange of information between market parties. The various roles of a process are marked along the horizontal axis while the vertical axis shows time. In this document, every exchange of information between roles is numbered. In principle, messages occur chronologically according to the numbered order. Exceptions to this are possible using sub-sequences. The "alt", "par", "opt" and "loop" sub-sequences used in this document are explained below.

In the diagrams, time limits inside {} parentheses are periods of 24 hours unless otherwise separately mentioned in the diagram;

The notation {earliest..latest} is used inside the {} parentheses. N.B.! It is also possible that only one of the limits is specified. If the earliest or latest limit is not given, there is no corresponding binding time limit;

Negative time limit numbers refer to time before delivery begins and before a change of agreement or other change comes into effect, while positive numbers correspondingly refer to time after these events.




51 (203)

Alternative flows

FIGURE 1 EXAMPLE DIAGRAM OF ALTERNATIVE FLOW IN A SEQUENCE DIAGRAM

In a sequence diagram, a process' alternative flow is depicted using an alt subsequence. The flow that will be realised is dependent on pre-determined terms. In the above example, party 1 will send message 1 to party 2 when the term written inside the square brackets is met. Otherwise party 2 will send message 2 to party 1. It is worth noting that there can be more than one message on both sides of the dashed line.




52 (203)

Optional flow

FIGURE 1 EXAMPLE DIAGRAM OF OPTIONAL FLOW IN A SEQUENCE DIAGRAM

A process' optional flow is denoted using an opt sub-sequence. In the example above, party 1 always sends message 1 to party 2, but party 2 only sends message 2 if [term] is met.

Parallel flow

FIGURE 1 EXAMPLE OF PARALLEL FLOW IN A SEQUENCE DIAGRAM




53 (203)

Par sub-sequences are used to depict flows completed in parallel. In the example, messages 1 and 2 can be sent in parallel or in any order. This does not, however, mean that either of the messages can be left unsent.

Loop

A loop sub-sequence is repeated for as long as a given term written inside square brackets is valid. An example of a loop is set out in the picture below.

FIGURE 1 EXAMPLE OF A LOOP IN A SEQUENCE DIAGRAM




54 (203)

2 Datahub's data model and parties' rights to data

2.1 Description of conceptual model This section describes Datahub's internal data model on a conceptual level, i.e. the structure onto which data supplied by parties to Datahub and data generated by Datahub is stored. The data model does not describe Datahub's physical database, nor is it a complete description of the upcoming Datahub data model, but instead we aim here to outline the most important data sets with regard to market processes and their relationships. Master data set attributes are listed in data model figures attached to section 3 of this document. A more specified definition of each attribute can be found in a separately published Excel spreadsheet ("data standard"). When reading the figures, special attention should be paid to the fact that data marked as optional in the figure may be compulsory depending on other data. For example, fuse size at an accounting point is compulsory if the electric power is not given.

The content of data sent by parties to Datahub and vice versa in processes is depicted in document Datahub events sections 4-12 using event-specific class diagrams.




55 (203)

FIGURE 1 CONCEPTUAL MODEL4

Master data sets (entities) and the relationships between them are set out below. Not all master data sets in the table are in the above-mentioned conceptual model, but they occur in more detailed data model diagrams in chapter 3.

TABLE 1 DESCRIPTIONS OF ENTITIES IN DATAHUB'S DATA MODEL

4 An accounting point may only have one valid grid and sales agreement at once, but it may have several consecutive agreements over time.Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



56 (203)

Entity Definition Synonyms Relationships

Party

A company or organisation that operates in one or more roles on the electricity retail market. The Party must have an agreement with Datahub.

Electricity Market Party

A Party can have one or more roles (supplier, DSO, third party).

Supplier

A Party which acts as a supplier on the electricity retail markets. The Supplier has an electricity sales and/or purchase agreement with a Customer. The Supplier may be an open supplier or deliver a fixed amount of electricity ("fixed delivery").

Electricity Supplier

Distribution System Operator

A party which manages one or several distribution grids or high voltage distribution grids and practices licensed electricity grid operation in the grid.

DSOGrid Company

A DSO manages one or more Metering Grid Areas in the grids it controls and therefore manages all Accounting Points as well as other Metering Points in the Metering Grid Area.

Third party

A Party that is not a Supplier or DSO that has an agreement with Datahub and who acts in a certain role on the electricity retail market with the authorisation of a Supplier, DSO or Customer.

Metering Grid Area

An area defined in the grid managed by a DSO to which Accounting Points and other Metering Points are connected.

MGAGrid (Area)

A Metering Grid Area is always managed by one DSO, but over time the DSO for the Metering Grid Area may change due to e.g. mergers.

Customer

A natural person, company or organisation with an agreement for electricity sales, electricity supply and/or electricity purchasing with a Supplier and/or a Grid Agreement with a DSO and which acquires or produces electricity mainly for its own use.

Electricity UserEnd User

A Customer may have one or more Sales and/or Grid Agreements.




57 (203)


Metering Point

A general term for points on the grid where metering are carried out. Accounting Points are one kind of Metering Point, others are Exchange Points and Production Points, which are required

Accounting Point

A data set related to a physical location, for example, a dwelling, which connects a customer to a DSO and electricity supplier through a Grid and Sales Agreement, and in which the consumption or production of electricity can be measured.

There can only be one valid Sales Agreement and one valid Grid Agreement for an Accounting Point at any given time.The Accounting Point belongs to only one Metering Grid Area and therefore is only managed by one DSO.The Accounting Point can be connected to another Accounting Point whereupon it is possible to tell if the physical address contains both consumption and production Accounting Points.

Sales Agreement

A contract by which the Customer buys and the Supplier sells electrical energy. Electricity retail sales are regarded as the sale of electricity through the distribution grid directly to users of electricity or indirectly to users through the internal grid of a property or a corresponding group of properties.In the data model and information exchange, purchase agreements are processed as Sales Agreements which are linked to a production Accounting Point.

A Sales Agreement can only be linked to a single Accounting Point.One or more Customers can be connected to a Sales Agreement.




58 (203)


Grid Agreement

A contract between the DSO and Customer regarding the grid service the Customer requires.In the data model and information exchange, small-scale production Grid Agreements are processed as Grid Agreements connected to a production Accounting Point.

Transmission Agreement

A Grid Agreement can only be connected to a single Accounting Point.One or more Customers can be connected to a Grid Agreement.

Address

Addresses stored in Datahub relate either to an Accounting Point, Customer or Sales and Grid Agreements. The official address for an Accounting Point and Customer takes the format of a postal address. Agreement-specific invoicing addresses can either be postal addresses or electronic addresses.

An Accounting Point can have one or more addresses (corner buildings, language versions). Customers have a single, official address.Sales and Grid Agreements can each have one invoicing address, which also may be an electronic address.

Contact PersonAgreement-specific contact person details which must be exchanged between parties.

A Sales or Grid Agreement can have one or more Contact Persons.

2.2 Parties' rights to dataThe following table contains a summary of the rights of Datahub parties to each of Datahub's master data sets. Rights depend on the party's role, the accounting point's agreement status and authorisations held by the party.

TABLE 1 PARTIES' RIGHTS TO DATA IN DATAHUB

Party Customer information

Accounting point data

Agreement information Metering data

Current supplier (valid agreement with the customer)

Rights during its own sales agreement

Rights to all accounting point data during its own sales agreement

Data concerning its own sales agreementRights to grid agreement information during its own sales agreement

Accounting point consumption, production and reactive power metering: rights during its own sales agreementProduction unit metering data: rights if production unit supplier




59 (203)




New supplier (an agreement with the customer is reported to the future)

Has rights only when authorised by customer or after informed a new sales agreement

Rights to basic data(*) for the accounting point or, with customer authorisation, to all data if the customer has a valid agreement to the accounting point.

Rights to agreement status with customer authorisation (**)

Accounting point consumption, production and reactive power metering: rights during its own sales agreement or with customer authorisation

Potential supplier (no reported agreement with the customer)

Has rights only when authorised by customer

Rights to basic data(*) for the accounting point or, with customer authorisation, to all data if the customer has a valid agreement to the accounting point.


Accounting point consumption, production and reactive power metering: rights with customer authorisation

Leaving supplier (agreement with the customer has ended within 6 weeks from the request)

Rights to customer data 6 weeks after the agreement has ended

Rights to data during its own sales agreement


Accounting point consumption, production and reactive power metering: rights during its own sales agreementProduction unit metering data: rights during its own agreement if supplier of the production unit.

Old supplier (agreement with the customer has ended over 6 weeks ago from the request)

Rights during its own sales agreement

Rights to data during its own sales agreement


Accounting point consumption, production and reactive power metering: rights during its own sales agreementProduction unit metering data: rights during its own agreement if supplier of the production unit.




60 (203)




DSORights during own grid agreement

Rights to accounting point data for its own metering grid area

Grid agreement informationRights to supplier data in a sales agreement

Rights to all metering point metering data in its own metering grid area.

Third party – authorised by customer

During authorisation

During authorisation and agreement period


During authorisation and agreement period

Third party – DSO's service provider

According to role According to role According to role According to role

Third party – supplier's service provider

According to role According to role According to role According to role

* Basic accounting point data refers to the accounting point identification, accounting point address, accounting point status, accounting point type, meter identification, information whether the accounting point is a building accounting point, related accounting point identification and information concerning remote connectability.

** The right to agreement status is set out in more detail in section 3.2.2.

2.3 Data storage periodData is stored in Datahub as necessary to meet the needs of parties' processes. However, data cannot be stored in Datahub indefinitely. The storage period for metering data in Datahub's operative database is six years, and this time also steers the storage of data that has become obsolete with regard to other processes. When a customer's agreement ends, the customer and agreement information are removed from Datahub's operative database after the same six-year period when the last metering data relating to the customer is deleted. In agreement information, not only actual agreement information is included but also invoice row data concerning the agreement to be deleted and, in customer information, all information directly concerning the customer, such as customer authorization information. Also accounting points with status "removed from use" will be removed, if they have no related agreements. The figure below presents the process which will be used for removing historical data from datahub, as described above.

Anonymised and aggregated statistical data concerning metering data is nevertheless stored even after this period of time ends.




61 (203)

FIGURE 1 ACCOUNTING POINT STATUS DIAGRAM

2.4 Party user interfaceDatahub will provide a web based user interface, where parties can maintain their party data, delegations between parties and settings related to datahub messaging interface. Parties can also use user interface to browse market process data in datahub based on their rights to data, as described in chapter 2.2.

If a messaging interface process has been defined for handling market process data, said data cannot be changed using party user interface. Updating aforementioned market process data must always happen through messaging interface, to assure consistency between market parties' systems and datahub. Concerning market process data, user interface will be used mainly to maintain imbalance settlement structural information, for which it was deemed not necessary to define market messages. User interface can also be used to handle some of the more rare market processes, such as current supplier's approval for a retrospective change of supplier. These special market processes are described separately in chapter 3.

However, the user interface will provide a possibility to perform manually all the data processing described in chapter 4 for those small-scale market parties, who do not have the necessary systems to implement the actual messaging interface. Market processes, which are executed using the user interface, must adhere to the same rules and data validity requirements as the market processes executed using the messaging processes. This approach is not suitable for handling large amounts of data. For this reason, reporting of metering or invoice row data is never possible through party user interface. Metering, invoice row and imbalance settlement data reported to the System are also not forwarded to the party user interface as messages. A party who uses party user interface for performing market processes can, if they want, order the forwarding of this data from the System through message interface.

One party can perform the market processes described in chapter 4 only using either the messaging interface or the party user interface. The same party cannot perform the processes using both the messaging interface and the party user interface. Information about whether a party performs market processes using messaging interface or party user




62 (203)

interface is stored in datahub. As an exception, data request events through message interface are also available to parties who use party user interface for performing market processes.

User management for parties is based on a model, where each party has one or more main users, who can give user rights to other users of their organisation. It is possible to define that a user has both read and write access to data, or only read access to data. Datahub enables defining user rights so that only certain users in an organisation have access to personal information.

2.5 Data interface for market partiesInformation exchange through datahub happens using messages described in document "Datahub events". The messages are based on ebIX message definitions. The parties will also have access to a user interface intended for them that is describe in chapter 2.4 of this document. In addition to these, the System will provide the market parties with a more flexible way to retrieve data belonging to them directly without the messages related to events. This interface is called a Data interface. and it is implemented as a REST / HTTP interface. This data interface makes it possible to retrieve data from datahub for example directly to an online services offered by the Market Party to it’s end customers. It is not possible to report data to datahub through data interface. Market parties can choose if they want to use the data interface for the retrieval of information or not. If the Market Parties need to retrieve a larger amount of data from Datahub, for example to compare the data in their own data systems to the data in the Datahub, will this be done by using so called control reports. These reports can be run as scheduled reports during night time, when they do not affect normal daily processes.

Data interface can also be utilised when an external registered party (third party or other market party) develops and creates new services, for which the customer can give an authorisation to their own information. A third party service can be, for example, a mobile application that allows the end user to see its information for all accounting points regardless of which grid area they are located in or who sells electricity to them.

The data interface can be queried for an individual record (customer / accounting point) at a time. In other words, the data interface does not support so-called mass queries that would return data of multiple accounting points at a time. The data interface provides the following data retrievals:

Retrieval of accounting point data

Retrieval of agreement information for an accounting point

Retrieval of metering data for an accounting point

Retrieval of authorization information for an accounting point

Retrieval of customer information




63 (203)

Retrieval of market party information

o For market party information, you can retrieve data for all parties at once.

Parties rights to data are taken into account according to same rules both for data interface and message interface. A party can only retrieve information they are authorised to based on an agreement or an authorisation through data interface. To ensure data privacy, retrieving party must always enter the customer ID with which it has an agreement. One customer ID is sufficient even if the contract has more than one customer.

More specific descriptions of the data interface, control reports and response times and possible limitations will be published later in the project in a separate document.




64 (203)

3 Description of market processes

3.1 DH-100 Management of customer and accounting point dataCustomer and accounting point data is the most essential basic data exchanged between parties and stored in Datahub's database. This section outlines the principles for maintaining and retrieving this data in Datahub.

3.1.1 DH-120 Maintenance of accounting point data

Accounting point data to be stored in Datahub is outlined in the diagram below.




65 (203)

FIGURE 1 CLASS DIAGRAM FOR ACCOUNTING POINT DATA

Data for accounting points and – more broadly – for all metering points, is data owned by the DSO. As such, the maintenance of accounting point data in Datahub is the responsibility of the DSO. It is the responsibility of the DSO to create new accounting points, update data and report accounting points as removed from use.

The life cycle of an accounting point and its possible statuses throughout its lifetime are set out in the diagram below.




66 (203)

FIGURE 1 ACCOUNTING POINT STATUS DIAGRAM

Accounting points should be created in Datahub as soon as they are established in the DSO's system. Because the agreement information is valid for complete days, accounting point data will also be updated for complete days. Datahub's unique, GS1 system-based GSRN code should be reported for the accounting point.

Accounting point can be located near Finnish borders but not in Finland and still belong to a DSO registered in Datahub. This is why the Country-information is needed in Datahub.

An accounting point can be created in Datahub while still in the construction phase, whereupon its status will be "under construction". This data is meant to inform the supplier that an agreement can be made and reported to Datahub, but for the time being delivery to the site cannot begin. Delivery cannot begin, for example, if the accounting point is new and no meter has been installed yet.

When the accounting point is "metered" – that is, delivery can begin, the DSO activates the accounting point by updating its status to "connected" or "disconnected" depending on whether or not delivery is initiated. Statuses "connected" or "disconnected" can be updated only by using connection and disconnection events. “Deleted” – status is updated by using Accounting point deletion – event. Other statuses will be updated by using the accounting point update event.




67 (203)

The DSO can temporarily make the accounting point passive by changing its status to "under construction". This takes place at e.g. renovated sites, when it is temporarily not possible for delivery to begin to an accounting point. A valid sales agreement is not automatically terminated when an accounting point's status is changed to "under construction"; instead, the supplier must come to an agreement with the customer on the matter as necessary.

When it is possible to begin delivery to an accounting point as normal, its status in Datahub is "connected" or "disconnected". For accounting points with these statuses, agreements can be made and delivery can begin immediately ("connected") or as soon as the accounting point is connected ("disconnected").

The DSO sets the status of the accounting point as "removed from use" in Datahub when the accounting point is permanently taken out of use, such as when the DSO dismantles a connection. The DSO must ensure that termination of the accounting point's agreements has been reported to Datahub before reporting the removal of an accounting point. Once an accounting point is reported as removed from use, it is no longer possible to make agreements for that accounting point or return this back to status “Connected”.

Accounting points that are erroneously created in Datahub must be removed from Datahub. In Datahub this is done by using the Accounting point deletion event. The accounting point ID informed to the deleted accounting point can not be reused when creating a new accounting point. The deleted accounting point remains in the Datahub in status deleted. These accounting points are not visible to other market parties for example when requesting the accounting point ID. If events have been made for the accounting point before the error is noticed and these events are not valid yet, these events must first be cancelled, after which the accounting point should be set to "removed from use".

Agreements can be made for the accounting point as soon as its data appears in Datahub. If a new sales agreement is made for an accounting point while the point's status is still "under construction", but delivery cannot begin on the start date marked on the agreement, the start date in the sales agreement and the actual date of connection will differ from one another. In these cases the supplier must change the start date in accordance with the connection date announced by the DSO. To change the start date the supplier must first cancel the previously reported agreement and then report a new agreement with the correct date.

The basic accounting point information has information of the time division of the accounting point. This information will provide the supplier with the necessary information when selecting a sales agreement product for the customer. If the supplier wishes to have more detailed information on the accounting point before the sales agreement is notified, the information is available with authorisation from the customer. The handling of authorizations is described in more detail in section 3.9.1.

The table below sets out a summary of accounting point statuses during a accounting point's life cycle and their meanings.Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



68 (203)

TABLE 1 ACCOUNTING POINT STATUSES AND THEIR MEANINGS

Status Agreements Delivery start Status at accounting point

Under construction Can be made Cannot begin

UnmeteredConnection undergoing maintenance

Connected Can be made Can begin Default – electricity connected

Disconnected Can be made Can begin Default – electricity not connected

Removed from use Cannot be made May not begin Connection cancelled

Deleted Cannot be made May not beginErroneously reported accounting point deleted before any events reported to it.

In addition to the accounting point status, the DSO should also update other data for its accounting points in Datahub. The exception is the accounting point identification, which may never be updated. Data should be updated as soon as it changes in the DSO's own system. Datahub saves accounting point history data - this means that the accounting point data's time of creation or modification is always saved in Datahub and these times are taken into account in data retrievals in accordance with parties' rights.

The accounting point attribute "heating depending on electricity" is a factor in determining whether a party has a right to disconnect an accounting during winter (Verkkopalveluehdot VPE 20149 part 89.1.4). The DSO is responsible for maintaining the attribute in datahub. However, datahub does not validate supply disconnection requests or notifications based on the attribute.

The current supplier, future supplier and third party also have the opportunity to report changes to accounting point data. Accounting point data reported to Datahub by the supplier or third party is not automatically updated in Datahub however, instead is forwarded to the DSO which then carries out the update. The DSO is to respond to an update request by sending to Datahub the accounting point data update, which includes either data reported by the supplier/third party (the DSO approves the update request), or accounting point data in the grid owner's own system (the DSO rejects the update request). If the DSO rejects the update then the DSO must also send the reason for the rejection.

The diagram below outlines the process description for an accounting point data update.




69 (203)

FIGURE 1 PROCESS DESCRIPTION FOR AN ACCOUNTING POINT DATA UPDATE

Consumption and production accounting points can be located in the same physical location, but they are processed in Datahub as separate accounting points. Consumption and production accounting points are separated in datahub with accounting point type information. So the production accounting points don’t need a word “Production” in accounting point address as an identification. With regard to the functionality of agreement processes, there is need to maintain a more secure manner of linking these accounting points together in addition to address. Linking takes place by reporting the identification code for the production/consumption accounting point with which the consumption/production accounting point is physically located in the same place when the consumption/production accounting point in question is created or updated. Linking between accounting points is two-way, i.e. both accounting points include the information about the other linked accounting point.

How a worksite, event or other temporary accounting point is processed within the DSO's internal processes has no bearing on Datahub's functionality. DSOs employ various operating methods for processing temporary accounting points. If a DSO always establishes a new accounting point in its own system for a temporary accounting point, the new accounting point will be reported to Datahub in accordance with the normal creation process. If, on the other hand, the DSO uses a single accounting point identification and only updates the accounting point address in accordance with where the temporary Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



70 (203)

accounting point is located at a given time, corresponding changes in address must be reported to Datahub using the accounting point update event. In such cases the DSO must ensure that the accounting point is not reported to Datahub as removed from use for as long as it will be re-used.

3.1.2 DH-110 Maintenance of customer information

Customer information to be stored in Datahub is outlined in the diagram below.




71 (203)

FIGURE 1 CUSTOMER INFORMATION CLASS DIAGRAM

Customer information maintenance in Datahub operates on the premise that a customer is only created once and then the customer's basic information is distributed amongst all the market parties with whom the customer has an agreemen. The customer's basic information only encompasses the information which, from a market perspective, needs to be updated in a centralised manner and other information is maintained as part of agreement information on an market party-specific basis. At a high level, the division is such that name, identification, contact and address information are considered to be customer information. Agreement-specific information, on the other hand, consists of invoicing and contact person information. A customer note can also be given for an agreement and can be informed to identify a company or municipal department on the agreement. The same customer note can be used if you want to identify the supplementary company name for the agreement for a company customer. The supplementary company name is not its own unique customer in datahub because it uses the same business ID as the actual company customer to which the supplementary company name belongs.

TABLE 1 DISTRIBUTION OF INFORMATION BY CUSTOMER AND AGREEMENT

Customer information Agreement information

Name Invoicing address

Code Contact person




72 (203)

Official address Contact person's contact details (telephone number, e-mail address)

Contact details (telephone number, e-mail address)

There are two types of customer in Datahub: consumer and corporate customers. All legal persons (companies, organisations, public operators) are processed as corporate customers and all natural persons are processed as consumer customers. Customers are uniquely identified in Datahub using a code which, depending on the type of customer, is either a personal identification number or a business ID number (or VAT code for foreign companies). As such, agreements may only be reported to Datahub if the customer information includes such a code. If an agreement is made in the names of several customers, the information of all customers and related codes will be reported, whereupon the agreement will be linked to multiple customers in Datahub.

If the matter concerns a foreign customer who does not yet possess a Finnish personal identification, the agreement can under special circumstances be reported without an ID, but the customer's date of birth is nevertheless required. In addition, the party's own identification ("other" identification), which is formed of a supplier party identification (GLN-identification) and supplier's customer identification, is also reported to Datahub as the customer identification. When a new agreement to the customer is reported the customer’s party’s own identification created by the supplier is forwarded also to the DSO. Based on this, the supplier and the DSO can later identify the customer in Datahub. If a customer has a foreign personal identification or equivalent, it can be reported to Datahub using the customer's additional information field.

A party that reports such an agreement is under obligation to update the customer's information in Datahub as soon as a personal identification is available. After the update all customer’s previous agreements can be found with the new personal identification number. Foreign customers are the only exception which allows for an agreement to be reported to Datahub without a customer ID. The creation of customers without identification in Datahub will be monitored.

Private traders are corporate customers who are personally responsible for their agreements. All private traders get a business ID when they register with the authorities. For private traders it must also be possible to enter a personal identification for a corporate customer. In datahub, private traders are identified with their business ID and personal identification is provided in the customer's additional identification field. Thus it is possible to tell the private trader apart from the corresponding consumer customer based on customer identification.

Customer has an attribute "Customer sub-type" reserved for handling an estate of a deceased person, because the market parties often handle these customers in a different




73 (203)

way as the other customers. The attribute can be used to improve the processes the parties have for handling estates of the deceased persons.

If a company goes bankrupt, it is normal in these situations that the agreement is made with the bankrupted company estate when it does not yet have a new company identification. A new agreement can be reported to a company estate without a company identification by giving a customer sub-type company estate and forming a party’s own identification for this customer.

Parties are responsible for the accuracy of the customer information that they report to Datahub. Datahub does not carry out internal data validation, such as checking whether a customer's name and business ID correspond to one another. Instructions related to data migration have been added to EDILfi portal on e.g. how parties are to ensure that a corporate customer's name is saved in its official format as it is on the official register (YTJ).

A customer is only created in Datahub as part of agreement processes. If a customer in an agreement notifications submitted by a party cannot be found in Datahub using an identification, it should be created in Datahub as a new Customer record. If the customer can be found in Datahub using an identification, the agreement to be reported is attached to the existing Customer record. In addition, the customer's information is updated to correspond to the customer information provided. If an agreement with several customers is reported, meaning that the party's agreement notification contains several agreement partners, several Customer records will be linked to the agreement in Datahub.

It is generally the supplier's responsibility to update customer data in Datahub. Customer information can be updated by those suppliers who have a valid agreement with the customer. Customer information can be updated as part of agreement processes or using a separate notification. In addition, the DSO or third party can send a customer information update request to Datahub which is then sent to the supplier with the latest agreement with the customer. This supplier then updates the customer information because it is assumed to have the most recent customer information. The supplier can refuse to update the information if it considers the update request to be unfounded or erroneous. The supplier is to respond to the update request by sending a customer information update to Datahub containing either information reported by the DSO/third party (the supplier approves the update request) or customer information found in the supplier's own system (the supplier rejects the update request). If the supplier does not respond to the update request within 2 working days, Datahub will send a daily reminder to the supplier until it responds to the request. A personal identification can be added to a customer in an update, but this identification may never be updated. If for some reason the identification would need to be corrected, this is then done by notifying the datahub-operator, who will then do the update.

Customer information that has been changed is forwarded to all parties that hold valid or not yet valid but informed agreements or valid authorisations with the customer. The changed information is sent out when it is stored to Datahub. Datahub checks then to whom the notification is sent to according to the rights on start of occurrence of the




74 (203)

change. If an agreement has ended less than 6 weeks ago, updated customer information is also forwarded to the previous supplier of that agreement. In the event that sales and grid agreements are in different customers' names (the situation for agreements made before the implementation of Datahub and whose data was imported to Datahub via migration), the grid's customer information can be directly updated based on DSO's request if the customer has no sales agreement at all.

The process diagram below outlines a customer information update.

FIGURE 1 PROCESS DIAGRAM FOR A CUSTOMER INFORMATION UPDATE

It is possible that there are multiple updates to the same customer information during the same time period, because the customer may have agreements with multiple market parties. In case of interfering updates to customer information, Datahub retains the information that was reported latest, because it is expected to contain the latest information. In a situation described in the figure below, if both events update the same piece of customer information, for example the telephone number, the information reported to Datahub on 5.6. that takes effect on 10.6. would still be valid after 15.6., because it was reported later. If interfering customer information updates concern the same customer, but different pieces of information, for example one updates the postal address and the other one the email address, both updates will take effect in Datahub according to their start of occurrences. The aforementioned mode of operation is also applied when different business processes update the information of the same customer. In addition to DH-110 processes, customer’s information may be updated by DH-311 new sales agreement process in Datahub.




75 (203)

FIGURE 1 INTERFERING UPDATES

Datahub allows for the completion of “private” customers' processes. Private customer means that the customer has a non-disclosure order for personal safety or that the customer has forbidden the disclosure of their information and thus their information may not be disclosed. One can apply for a non-disclosure for personal safety from the local register offices if a person has reason to fear for their own or their family's safety. Private customer does not refer to a customer who has reported a non-disclosure for direct marketing to a party. If a customer's information contains a non-disclosure marking, information is forwarded to the DSO as normal during agreement processes. Information about non-disclosure is also sent to the DSO for information along with the customer information linked to this notification. Private customers cannot grant authorisations to 3rd parties. And if a customer who has granted authorisations to third parties is marked as “private” then the authorisations are ended immediately when the notification is received to Datahub. Information about customer changing to private is forwarded to customer’s other suppliers and DSOs normally. However, DSOs and suppliers may relay the information of these customers through datahub when these market parties authorise third parties to act on their behalf. In these cases, 3rd parties may not use the customer information of these customers for any other purpose than what has been agreed with the market party. If the customer want’s to remove this “private”-marking from his information, it can only been done by the customer himself through the customer user interface.

Datahub's migration work resulted in instructions as to how customers who do not currently have IDs in market parties' systems can be uniquely identified during the migration phase. The unique identification of customers of new agreements made after the implementation of Datahub should be carried out as described above.

3.1.3 DH-130 Retrieval of customer and accounting point data

Parties' needs regarding the retrieval of customer and accounting point data primarily relate to agreement processes. As such, a search function will be constructed for Datahub which will always return accounting point data, data on customers linked to the accounting point




76 (203)

via agreements and data concerning the accounting point's agreement status. according to the rights of the retrieving party. The search will return the data in accordance with the rights set out in section 2.2. The search is outlined in more detail in agreement processes in section 3.2.2.

The market party must provide the accounting point identification and depending on the search event the customer identification and also/or the time for the retrieval when searching for customer and accounting point data. There is a separate search for the supplier and the third party to find an accounting point identification that makes it possible to retrieve the accounting point identification and its basic data using the accounting point's address.

The supplier has the right to customer and accounting point data for the duration of the validity period of its own agreement. The supplier has the right to maintain customer data in Datahub from the time that the agreement is reported, throughout its validity period and also for another 6 weeks after the agreement has come to an end. A search carried out during the 6 week period after the agreement's validity period agreement has ended concerning the same 6 week time period will , however, only return current customer information but only the basic data fromof the agreement's validity periodaccounting point. The period of 6 weeks is determined based on the supplier's obligation to correct the customer's invoicing and the Electricity Market Act's requirements on sending final invoices in accordance with the existing operating method. During this 6 weeks period the supplier is called the “Leaving supplier” in Datahub processes.

Contrary to what is written above, a supplier is also able to retrieve customer and accounting point data without a valid agreement as long as the supplier is authorised to do so by the customer. Authorisation principles are set out in further detail in section 3.9.

Distribution system operators have the rights to accounting point data in their own metering grid areas and therefore they also have the rights to customer information linked to the accounting points via grid agreements. An accounting point data search carried out by a DSO will always return accounting point data and, if the accounting point has a customer, also customer and grid agreement information in addition to accounting point datafrom the requested date.




77 (203)

3.2 DH-300 Agreement processesThis section will outline the processes relating to accounting point sales and grid agreements. As a rule, whenever a supplier makes a new agreement in its own system, the agreement will be reported to Datahub. The DSO confirms its own agreement in Datahub when necessary, but whenever it does this, it will always be based on the supplier's notification. If the supplier or DSO make changes to the agreement information stored in Datahub, the changes shall be reported to Datahub and Datahub will relay them on to the other party. When the agreement ends, each party terminates its own agreements and the completed agreement termination is sent via Datahub to the other party. It is not possible for an accounting point to have more than a single sales agreement and a single grid agreement valid at any one time, so whenever a new agreement is reported for an accounting point Datahub will automatically terminate the previous agreement and send the information concerning the terminated agreement to the party whose agreement was terminated.

3.2.1 Agreement information

Sales and grid agreement information stored in Datahub include information such as agreement dates, invoicing address information and contact details for contact persons. When parties report agreements that they have made to Datahub, the customer information submitted in the notification is stored in Datahub's Customer entity (or in several if there is more than one customer in the agreement), and the agreement is linked to a customer (or customers) and the specified accounting point in Datahub's internal data structure. An agreement is identified in Datahub with the combination of agreement identification, accounting point identification and party identification of the related market party.

Agreements entered into the Datahub are valid for entire days. The agreement start date is the first day when the agreement is in effect. The agreement end date is the first day when the agreement is no longer in effect. That is to say, the agreement begins at 00.00 on the start of occurrence of the notification of a new sales agreement. The agreement ends on the agreement end date at 00.00 or in other words, the day before the agreement end date is the last day when the agreement is in effect.

Invoicing channel information is stored in agreement information, and as such the appropriate invoicing address details (including invoicing (postal) address, e-mail invoicing address or e-invoicing address) must be linked to the agreement information. The invoicing address a customer provides when making a new agreement with a supplier is sent from the supplier to the DSO via Datahub. This data does not, however, bind the DSO to the use of the invoicing channel in question if the DSO is unable to provide said channel. The DSO reports the invoicing channel it uses in the agreement to Datahub as part of the grid agreement information. A customer may also wish for the DSO to send invoices to a different address to the one stated on the sales invoice. In such cases, the customer should contact the DSO in order to change the invoicing address. The DSO will report changes to Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



78 (203)

invoicing addresses to Datahub. Datahub's data model allows for separate invoicing addresses to be used in sales and grid agreements at the same accounting point; that is, invoicing address data is stored on an agreement-specific basis. It is worth noting that current rules prohibit consumer e-invoicing data from being sent from one party to another. Nevertheless, it is possible to add a note in the invoicing channel field explaining that the customer wishes to use this particular invoicing channel. Even in cases when the invoicing channel is other than the postal invoicing, a postal invoicing address needs to be reported to the agreements to Datahub for debiting purposes.

The agreement information includes the invoicing method, which specifies whether both the supplier and DSO invoice the customer separately, or is there a combined invoicing done by the supplier or the DSO. Corresponding sales and grid agreement must have the same invoicing method. If a new grid agreement is not created along with a new sales agreement, the DSO updates the grid agreement invoicing method to match the invoicing method of the sales agreement if needed, or contacts the supplier to ask the supplier to update their sales agreement invoicing method.

It is possible to add contact persons to agreements in addition to the actual customer. The customer is the agreement partner that is legally responsible for the agreement. Contact persons are persons linked to the agreement whose contact details are required by the parties in customer service situations. For example, the recipient of an invoice may be reported as the contact person for an agreement if the recipient differs from the actual customer.

Similarly, contact persons for agreements may vary between sales and grid agreements. The contact person information provided to a supplier by a customer when making a new agreement with the supplier is stored in sales agreement information and sent to the DSO. The DSO may use this information as the contact person for its own agreement. It is worth noting that parties may have many different kinds of contact persons in their own customer and agreement information, but the contact persons whose information must be exchanged between parties are reported to Datahub. At least one contact person must always be reported for corporate customers. Separate contact persons are only reported for private customers when necessary, such as if the customer's contact details are insufficient.

Contact method agreed with the customer must be reported to an agreement. Contact method "electronic" means primarily that no letters will be mailed to the customer. Contact method is agreement specific and the contact method the customer has agreed on with the supplier is forwarded as information also to the DSO. However, the DSO must always agree on the contact method with the customer separately even though the supplier has reported that they are using electronic contact method. If the contact method in the agreement is Electronic then at least one of the customers reported in this agreement need to have email address reported.

The sales and grid agreement information stored in Datahub is set out below in separate diagrams. An accounting point can have several consecutive agreements over time, but




79 (203)

only one sales and one grid agreement can be valid at any one time. Agreement information sent in processes is set out in more detail in agreement events Datahub-Events documentation.




80 (203)

FIGURE 1 CLASS DIAGRAM FOR SALES AGREEMENT INFORMATION




81 (203)




82 (203)

FIGURE 1 CLASS DIAGRAM FOR GRID AGREEMENT INFORMATION




83 (203)

3.2.2 DH-310 Reporting new agreements

Information concerning agreements made with a customer must be reported to Datahub. The supplier always initiates the report of a new agreement to Datahub. This does not, however, prevent the DSO from agreeing on the grid agreement with the customer before the customer has made a sales agreement with a supplier. If the DSO makes a grid agreement before the new sales agreement is reported to Datahub, the DSO must wait for the new sales agreement to be reported to Datahub and only then confirm the grid agreement in Datahub in accordance with the normal process.

As Datahub provides an overview of the agreement and customer status for an accounting point, the supplier does not need to inform Datahub as to whether the matter concerns a customer's change in address, a change of supplier or the renewal of an agreement with the current supplier. Based on the accounting point's customer and agreement information, Datahub will decide which of the above applies and then register the new agreement accordingly. The differences between current messaging codes indicating the reason for changes in address and supplier and the new codes registered by Datahub are set out below.

TABLE 1 DIFFERENCES IN AGREEMENT REPORTING IN DATAHUB AND IN CURRENT STATE

Customer changes (current code "Move")

Customer does not change (current code "Change of supplier")

New sales agreement for the customer's new accounting point ("Moving in")

The customer makes an agreement for an accounting point at which it is not yet a customer, for example in connection with moving into a new home.

(Not possible)

New sales agreement for the customer's existing accounting point with a new supplier ("Change of supplier")

One of the existing grid and/or sales agreement customers is also involved in the new sales agreement, which is not with the current supplier

The customer switches supplier at the accounting point

New sales agreement for the customer's existing accounting point with the current supplier ("Change of agreement")

One of the grid and/or sales agreement customers is also involved in the new sales agreement, which is with the current supplier

The customer makes a new agreement with the current supplier

The aim is for the codes to better illustrate the real reasons behind new sales agreements. The new term "Change of agreement" will be taken into use in Datahub. This means that a




84 (203)

new sales agreement is made for the customer's existing accounting point with the current supplier.

Datahub will register the reason for making a new agreement depending on whether the customers stated in the new agreement differ from the customers stated in the valid agreements for the accounting point stored in Datahub; that is, whether the customer or customers in the new agreement have sales or grid agreements for the accounting point at the time the agreement is made. If the customers at an accounting point change entirely with regard to both sales and grid agreements, the situation usually concerns a move in or out. In these cases, it is permitted to report the agreement as quickly as on the day in question. An agreement can also be reported for the same day if the accounting point has no supplier or if the current supplier makes a change of agreement according to the table above. In all other cases, a period of 14 days shall be followed, taking the agreements' fixed terms into account. If the supplier reports a new sales agreement for today then the DSO is allowed to send in the confirmation of the grid agreement retrospectively to correspond the start date of the sales agreement.

The agreement may be notified to the Datahub at the earliest 90 days after notification. If the Supplier has agreed on a new agreement with the customer to begin later than 90 days, but notifies the agreement to the Datahub within the correct time limits, the Supplier must observe that the reason for the agreement start is the same agreed with the customer. If the Supplier has agreed with the customer of the ‘Change of Supplier’ and the reason is returned from Datahub as a ‘Move In', the Supplier must contact the customer and confirm the situation with the customer.

The following table contains a summary of how Datahub decides the reason for which new agreements are registered. Datahub's assignment of the aforementioned reasons is primarily used for statistical purposes.

TABLE 1 DATAHUB'S DECISION-MAKING CONCERNING THE REASONS FOR REPORTED NEW AGREEMENTS

Situation Changes at MP Remains the same at MP Reason

1 Customer moves to the accounting point

All customersSales and grid agreement

DSO Moving in

2The customer makes a new agreement with the current supplier for the existing accounting point.

Sales agreement(Grid agreement)

DSO SupplierAll customers

Change of agreement

3The customer wishes to change (add/remove/change) parties to an agreement in the event of e.g. divorce.

At least one customerSales agreement(Grid agreement)

DSO SupplierAt least one customer

Change of agreement




85 (203)

Situation Changes at MP Remains the same at MP Reason

4The customer puts its electricity agreement out to tender and makes an agreement with a new supplier.

SupplierSales agreement(Grid agreement)

DSOAll customers

Change of supplier

5

The customer puts its electricity agreement out to tender and the parties to the new agreement are different from the parties to the existing agreement for the accounting point (added/removed/changed)

SupplierAt least one customerSales agreement(Grid agreement)

DSO At least one customer

Change of supplier

Special cases, such as reporting changes in the estate of a deceased person, depend on how estates are dealt with in the supplier's own processes. If an estate receives a business ID or if an agreement is transferred in the name of beneficiaries (personal identification) the new agreement for the estate is reported to Datahub where it is registered as a move in. If the supplier or DSO only changes the customer's information and the agreement continues under the personal identification of the deceased, the change can be reported as a change of agreement (please see chapter 3.2.3). If in this situation a new agreement is nevertheless made, the new sales agreement will be reported to Datahub where it will be registered as a change of agreement. Customers which are estates of deceased persons will be separated from other customers with a customer sub-type attribute.

Before a new agreement is reported, the supplier may retrieve the accounting point data from Datahub with the authorisation given by the customer. Rights to data are set out in chapter 2.2 of this document. The purpose of requesting preliminary data is to help the supplier to gain an idea of the kind of accounting point agreement it is possible to make for the customer in question. The accounting point identification and customer(s) identification are entered when requesting preliminary data. In addition to the customer and accounting point data, the supplier will also receive information on the accounting point's agreement status as follows:

Does the customer have a valid sales agreement for the accounting point or not

If the customer has a sales agreement on the accounting point, information will be returned as to whether the customer or customers are exactly the same as the customers which will be party to the new agreement.

Whether an existing sales agreement for an accounting point (if there is one) prevents a customer from making a new agreement for the accounting point when the customer remains the same and:

a) The sales agreement is fixed-term. In addition, the end date for the fixed term if it is within 90 days from the moment of data retrieval




86 (203)

b) The sales agreement has an exceptional termination condition.

If the upcoming ending of an agreement has already been reported for an accounting point, this date will be returned so that the supplier can agree on the start date of a new agreement without breaks in the delivery of electricity.

If a new agreement has already been reported as due to start at an accounting point, this date will be returned so that the supplier can make an agreement only for the time before the previously reported agreement (see example 3 in section 3.2.2.4)

Does the customer have a valid grid agreement for the accounting point or not

If the customer has a grid agreement on the accounting point, information will be returned as to whether the customer or customers are exactly the same as the customers which will be party to the new agreement.

Of customer information, the search will only return information for the customer or customers for whom an identification was given. If an agreement has other customers, a search will only return information indicating that the agreement contains other customers, but the information for these customers will not be returned.

Corresponding validation will also be carried out when a supplier reports a new agreement to Datahub.

Henceforth the term "customer" will also refer to all customers of an agreement whenever there is more than one customer. It is also worth noting that customers and changes in customers at an accounting point are identified in Datahub based on customer identification (personal identification, business ID, party's own identification), not purely by name.

3.2.2.1 Making a grid agreement

Datahub will decide whether a new grid agreement is necessary based on data reported by the supplier and on the accounting point's customer and agreement status at the given time. If the matter concerns a move in, a new grid agreement is always made. If the matter concerns a change in supplier or agreement, a new grid agreement is required in those situations wherein the valid grid agreement for an accounting point is held by a customer that differs from the customer in the upcoming sales agreement. This practice ensures that, in the future, accounting point sales and grid agreements are made for the same customers. Even if the customers of the agreements would match, a new grid agreement is needed if the “delivery agreement” attributes of the agreements do not match or if the grid agreement is ending during the new sales agreement. If new grid agreement is not needed, Datahub will notify the DSO about the new sales agreement. In these situations the new supplier will get the information about the accounting point and accounting points grid product by using the accounting point and customer information request event.




87 (203)

If a new grid agreement is required, Datahub will create new grid agreement information based on the supplier's notification with the status "unconfirmed". Datahub will inform the DSO of the new grid agreement, which the DSO will confirm with its own notification to Datahub. The unconfirmed grid agreement gets an agreement ID created by Datahub. This agreement ID will be replaced by the DSO with the agreement ID at their own system. The distribution grid owner may already have made an agreement with the customer, whereupon the agreement information is sent at this stage as confirmation to Datahub. Information from the DSO's confirmation is also sent to the supplier, whereupon the supplier is made aware of the necessary grid agreement information, such as product data. The DSO will connect electricity to the accounting point as necessary on the delivery start date. The supplier does not need to send a separate connection request. Instead, the DSO connects the electricity based on the new agreement notification. The connection is notified via connection processes describer in chapter 3.4. If the DSO cannot connect the accounting point when the agreement begins, they report the issue to datahub using connection delay notification.

It is market parties' responsibility to always check that the customer is of full legal capacity before making an agreement and reporting it to Datahub. Responsibility for checking always lies with the party which makes the agreement with the customer. A validation which prevents the reporting of a new agreement for an underage customer has been built into Datahub. The DSO has the right to refuse to make a grid agreement with a customer based on a notification from the supplier. In such cases, the DSO notifies Datahub that it will not confirm the grid agreement and provide a reason as to why confirmation could not be given. This information will be sent to the supplier.

3.2.2.2 Process description

The creation of new accounting point agreements is depicted in the following process diagram. The process diagrams are also attached to this document for better readability.




88 (203)

FIGURE 1 PROCESS DIAGRAM FOR REPORTING A NEW AGREEMENT

3.2.2.3 Rules

In Datahub, an agreement's start date refers to the date from which the supplier has the right to metering data and from which the supplier is responsible for accounting point consumption or production in its own balance sheet. In practice, this date also corresponds to the date from which the supplier has the right to invoice the customer.

Reports of new sales agreements made for the same accounting point on the same or very close dates currently cause a great deal of investigative work. In Datahub, there will be clear rules concerning the terms and time periods for reporting new sales agreements for an accounting point. The rule of thumb is that there cannot simultaneously be two or more valid sales agreements for a single accounting point on the same date. The agreements are always valid for full periods of twenty-four hours, so an agreement comes into effect at 00:00 on its start date and ends at the end of the 24-hour period.

The rules for submitting notifications for the same accounting point are as follows:

1. The start of a new sales agreement can always be reported for the current day if the accounting point has no supplier.

2. Move-in reports should always be submitted no later than on the moving day and no earlier than 90 days before the agreement starts.




89 (203)

3. In change of agreement situations (see table 7) a new sales agreement can be reported for the current day.

4. In all other cases besides the three aforementioned the new sales agreement must be reported at least 14 days in advance and no earlier than 90 days before the agreement start date.

5. A sales agreement which is successfully reported to Datahub will automatically terminate any sales agreement that is valid on the date on which the new sales agreement comes into effect such that the existing sales agreement terminates one day prior to the entrance into force of the new agreement (this also applies to situations in which the previous customer has reported that it is moving out at a later date, whereupon the end date is modified to an earlier date).

6. A sales agreement containing a fixed term or exceptional termination condition for an accounting point will, for as long as it is valid, block the new sales agreements reported by a new supplier in which the customer or even one of the customers is the same as for the sales agreement valid for the accounting point.

a. Exception: Consumer customer’s fixed-term sales agreement does not block a new sales agreement from a new supplier, if the fixed-term period has lasted at least 2 years.

7. A change of all customers at the accounting point (moving in) automatically cancels all new sales agreements at the same accounting point for existing customers due to begin on the same date as the change of customer or at a later date (chapter 3.2.2.4 example 4).

8. It is not possible to report two new agreements as starting on the same day, and the agreement that is reported later will be rejected (chapter 3.2.2.4 example 2). One exception is the rule 7 whereby the first new agreement made for a given day for the existing customer will be cancelled if an agreement for the accounting point is reported in which all customers change.

9. Before a previously reported new sales agreement for an accounting point comes into effect, a new sales agreement can be reported for the "inbetween" period, but in such cases the end date of the agreement must be reported and cannot be later than the start date of the previously reported agreement (chapter 3.2.2.4 example 3). The rule 7 is the exception. Datahub stores the agreement end reason for these as ‘Termination’.

10. Agreements may only be reported retrospectively in cases of error correction.

All notifications of sales agreements starting, ending or being updated which lead to overlapping sales agreements and which are not separately mentioned above shall be rejected.




90 (203)

3.2.2.4 Examples

The following examples aim to describe how reports of close-proximity or overlapping sales agreements are processed in Datahub to prevent the creation of overlapping agreements.

Example 1: accounting point agreements reported with different start dates come into effect consecutively regardless of whether the supplier reports them on the same day or on different days.

Example 2: An accounting point agreement previously reported with the same start date as a new agreement prevents the new agreement from coming into effect on the same day; Datahub rejects the latter notification (B) from the supplier.




91 (203)

Example 3: An upcoming agreement reported for the accounting point prevents the creation of an agreement that would be valid until further notice and would begin before the upcoming agreement. This kind of situation may occur when e.g. a lessor wishes to renovate an apartment before a new tenant moves in and the tenant has already made an upcoming agreement for the accounting point. In this case, it is only possible to make agreement (B) for the "in-between" period in Datahub, and the agreement will end before the start date of the earlier agreement (A). The notification for the new agreement (B) must include the agreement end date. The supplier is made aware of agreement A's start date when it requests preliminary accounting point data before reporting a new agreement. The notification informs the supplier of the date on which agreement B must end.




92 (203)

Example 4: A report of moving in to an accounting point cancels all previously reported upcoming changes of supplier or agreement.

Situation before agreement B is reported:

Situation after agreement B is reported:




93 (203)

3.2.2.5 Fixed-term sales agreements

The fixed term of a sales agreement is reported to Datahub by submitting the start and end date of the agreement's fixed term. It is worth noting that in Datahub's data model, these are different from the agreement's actual start and end dates.Agreement start date is always the actual start date of the agreement. Agreement end date is only stored once the agreement end is reported to datahub or datahub ends the agreement automatically.

Sales agreements' fixed terms will be accounted for in Datahub in accordance with the same principles that are currently in use in the existing model. The general rule is that a fixed-term agreement can be terminated prematurely if a customer moves away from the accounting point. In Datahub, agreements are always checked by accounting point, so even if the supplier and customer have agreed on the continuation of a fixed-term agreement at the customer's new accounting point, from Datahub's perspective these are two separate agreements for different accounting points and the first agreement can be terminated in Datahub.

In Datahub, a fixed-term agreement prevents a supplier from making a new sales agreement in situations in which even one customer of the sales agreement valid for an accounting point is the same as the parties to the new sales agreement (section 3.2.2 table 7 cases 4 and 5). The customer may agree with the current supplier on agreement changes and new terms of agreement in a flexible manner. As such, a customer can agree on the addition and removal of its agreement's parties with the existing seller in the event of e.g. divorce, even if the customer's existing agreement is a fixed-term agreement. The fixed-term nature of the valid agreement nevertheless prevents a new supplier's agreement from being reported to Datahub. Fixed-term of the sales agreement does not prevent the supplier from ending their sales agreement with a separate agreement end notification.




94 (203)

The following table lists the time limits valid in different situations for reporting agreements to Datahub, the effect of their fixed-term nature and the reason registered by Datahub for reporting a new agreement.

TABLE 1 VARIOUS SITUATIONS WHEN REPORTING NEW AGREEMENTS

Situation Fixed-term nature of agreement Report to Datahub Reason

1 Customer moves to an accounting point

No effect on changes to agreement

No earlier than 90 days before the agreement comes into force and no later than on the day

Moving in

2The customer makes a new agreement with the current supplier for the existing accounting point.

No effectNo earlier than 90 days before the agreement comes into force and no later than on the day

Change of agreement

3The customer wishes to change (add/remove/change) parties to an agreement in the event of e.g. divorce.

No effectNo earlier than 90 days before the agreement comes into force and no later than on the day

Change of agreement

4The customer puts its electricity agreement out to tender and makes an agreement with a new supplier.

Prevents a new agreement from being reported

No earlier than 90 days and no later than 14 days before the agreement comes into effect

Change of supplier

5

The customer puts its electricity agreement out to tender and the parties to the new agreement are different from the parties to the existing agreement for the accounting point (added/removed/changed)

Prevents a new agreement from being reported

No earlier than 90 days and no later than 14 days before the agreement comes into effect

Change of supplier

Rules for processing fixed-term agreements in Datahub:

1. A fixed-term agreement is deemed by default to continue as valid until further notice if the end date or renewal of a fixed term are not separately reported to Datahub.

2. A new agreement can be reported for a consumer customer who has a fixed-term agreement, if the fixed term has continued at least 2 years..

3. If the current supplier wishes to terminate a valid fixed-term agreement and continue the agreement with a new one with at least some of the same customers, they can report the new sales agreement directly to datahub.




95 (203)

4. The renewal of a fixed-term agreement is carried out with an agreement update event (chapter 3.2.3), for which the supplier reports a new fixed term start and end dates which will come into effect at the reported start of occurrence of the update.

3.2.2.6 Exceptional termination clauses

A supplier may agree on exceptional termination clauses for an agreement that is not for a consumer customer. In accordance with the data model described above, the sales agreement contains information on whether the agreement features exceptional termination clause. In agreements wherein the customer's notice period differs from the usual (14 days), the supplier must report this exceptional termination clause. In exceptional termination clause details, either the notice period in days or the interval during which a new sales agreement can begin must be reported. If necessary, the supplier must update this data every day.

If the supplier has, for example, an agreement which can be terminated on the 5th of every month, the supplier must continually update the data to correspond to the next possible date that a new sales agreement can begin in accordance with the notice period. The date (or interval) provided must correspond to precisely the date or interval on which a new sales agreement can begin, not the date on which the customer has the right to terminate the agreement. When the supplier notifies the interval then the first day is the first day the agreement can start and the last notified day is the first day when the agreement cannot start. In the example case, a single date can be given as an interval in which the end date is the following day of the start day.

In accordance with its own terms, an exceptional termination condition in an agreement prevents a new sales agreement from being made for the customer's existing accounting point in the same way that the accounting point's existing fixed-term sales agreement does. For exceptional termination conditions, the new supplier is made aware of the first possible start date for an agreement even when it is more than 90 days away. However, it is not possible to report an agreement earlier than 90 days in advance, even in this case.

3.2.3 DH-320 Reporting changes to agreements

Whenever a party makes changes in its own system to data that will be stored in Datahub, the changes must be reported to Datahub. The agreement to be updated is identified with the combination of agreement identification, market party and accounting point identification. Changes made to agreements are reported to Datahub in accordance with the following rules:

1. It is not possible to add or remove customers from agreements using an update event; instead a new sales agreement must be reported. It is also not possible to update the agreement customer’s information with an agreement update. Updating customer information is described in chapter 3.1.2.




96 (203)

2. It is not possible to change the start and end dates of an agreement with an agreement update. The start or end dates of a sales agreement can be changed before these dates (that is, not retrospectively) in Datahub only by first reporting the cancellation of the original notification to Datahub and then making a new notification with a new date.

3. Changing the start and end dates of a sales agreement once delivery has already begun or ended is set out in section 3.2.5.

4. Both agreements that are valid at the time of sending the update to Datahub and agreements that will become valid in the future can be updated. A sales agreement that has already ended can only be updated if it has ended less than 6 weeks ago. An ended grid agreement can be updated without similar time restriction.

5. Changes to an agreement's content wherein a party updates information in an existing agreement is carried out with an agreement update event. Changes to the content of an agreement include e.g. product changes, changes which affect invoicing details, changes to special termination clause or a changes to the fixed-term of a sales agreement.

6. A sales agreement can be updated from non-fixed-term to fixed-term agreement and vice versa. Fixed-term start and end dates of a fixed-term agreement can be updated.

7. An agreement cannot be updated from regular to delivery agreement or vice versa. In this case a new sales agreement needs to be reported to datahub.

Parties may also update customer information such as the customer's name or contact details while delivery is ongoing. This information can be reported to Datahub as a separate customer information update. Agreement cancellation and correction processes are set out in more detail in section 3.2.5.

3.2.4 DH-330 Reporting the ending of an agreement

As set out above, the report of a new sales agreement terminatesends the previous agreement at an accounting point automatically on the day preceding the start of the new agreement. In addition to this it is also possible to report the end of an agreement to Datahub separately. In these cases, the rule of thumb is that a notification which terminatesends an agreement in Datahub – that is, records the end date of an agreement – is made by the party whose agreement is ending. Datahub will send a notification of the terminationend of the agreement to the other party who will then (in accordance with its own processes) terminateend the agreement in its own system and then report this to Datahub using its own terminationagreement end report. It is, however, also possible for the supplier of the customer's new accounting point to report the ending of a customer's agreement via Datahub, whereupon the report of terminationending is sent to the accounting point's DSO which will then terminateend the agreement in Datahub as if the customer had notified the DSO itself that it is moving out.Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



97 (203)

The ending of an agreement is always reported to Datahub using the same terminationending report and the reason for terminationending is given using the reasons set out in the table below.

When a supplier receives a notification of grid agreement end, they must end their own corresponding sales agreement on the same accounting point. When a supplier reports an agreement end of their own sales agreement to Datahub with reason moving out, the DSO must end their corresponding grid agreement. In the kind of agreement endings where the counterpart is expected to end his agreement as well the notifications of agreement endings can be reported retrospectively. This way the endings can be reported for the same date. For example if the supplier ends the sales agreement today with the reason Move-out then the DSO can send his own notification with the same move-out date retrospectively so that the dates for the endings match.

TABLE 1 REASONS FOR ENDING AN AGREEMENT

Situation Reason

Customer moves out from an accounting point Moving out

The customer or supplier terminates the sales agreement, also in situations wherein a fixed-term agreement is terminated and there is no desire for it to continue as valid until further notice.

Terminating an agreement

The supplier or DSO dissolves its agreement due to breach of agreement by the customer. Dissolving an agreement

The DSO ends the grid agreement retrospectively due to meter removal. Meter removal

Rules for terminating agreements at an accounting point:

[1.] In situations concerning a move out or the dissolving of an agreement, agreements may be terminatedended on the day or at a later date.

[2.] The terminationend of an agreement must be reported no later than 14 days before the date on which the agreement ends.

1.[3.] Meter removal can be reported for the current day or at most one month retrospectively.

2.[4.] The ending of an agreement in any situation may not be reported earlier than 90 days before the date on which the agreement ends.

[5.] A sales agreement may not be terminatedendedd on a date on which the upcoming new sales agreement is already in effect.

3.[6.] The act of moving out by a customer will automatically cancel all of the customer's upcoming new sales agreements on the same accounting point, if the customers




98 (203)

who are moving out are exactly the same as the customers of the upcoming agreement (as in example 4 in section 3.2.2.4).

[7.] Agreements may only be ended or cancelled retrospectively in cases of error correction. It is not possible to report separate retrospective agreement endings, except in case of meter remocval, but an agreement can end retrospectively as a result of a retrospectively reported new agreement.

4.[8.] Meter removal can be reported for an accounting point only at the instigation of the DSO.

3.2.4.1 Process descriptions

The following diagrams show the agreement termination processes taken by the supplier and DSO.

FIGURE 1 PROCESS DIAGRAM FOR TERMINATING A SALES AGREEMENT




99 (203)

FIGURE 1 PROCESS DIAGRAM FOR TERMINATING A GRID AGREEMENT

3.2.4.2 Separate move-in and move-out reports

A move in reported for an accounting point will terminate any possible existing sales agreement for the accounting point. After this, the current supplier may, however, report a separate move out no later than the day preceding the move in. If the move out is reported for an earlier date than the earlier reported move in, the agreement's end date will be updated to correspond to the moving out notification. In this case, a period of time not covered by an agreement will remain between the move in reported earlier and the move out reported later. Datahub will notify the DSO of this period. If a separate move out has been reported, the customer that is moving out will not be returned to the current supplier if the new agreement is cancelled.

Situation before move-out notification:




100 (203)

Situation after move-out notification:

3.2.4.3 Separate move-out notification as part of the customer's move-in

When a customer moves, it must be possible to serve the customer so that the customer can terminate the agreement of the move-out location by reporting it only to the supplier of the move-in location. To allow this, Datahub features its own event through which the supplier of the move-in location can report the customer's move-out from the move-out location to Datahub. This notification is sent from Datahub to the move-out location's DSO. It is the responsibility of the move-out location’s DSO to terminate the grid agreement if needed and reports this to Datahub in the same way as if the customer would have notified the DSO about the move-out directly. As a result of this process, the notification on agreement termination is then sent from Datahub to the supplier of the move-out location. In its notification, the supplier of the move-in location must provide identification information of at least one customer, who has an agreement on the move-out accounting point. To be able to report the customer’s move-out to datahub, the supplier first needs to report the customer’s new agreement to datahub. The DSO can contact the customer if the supplier of the move-in location has not reported all of the agreement's customers. New supplier’s moving out notification cannot be cancelled in Datahub. If a supplier notices that they have erroneously sent the notification, they must directly contact the DSO in question.




101 (203)

FIGURE 1 NEW SUPPLIER REPORTS CUSTOMER MOVING OUT

3.2.4.4 The customer disputes a sales agreement

The customer's right to dispute the validity of an electricity sales agreement will be made possible in Datahub in accordance with an upcoming decree to be issued by the Ministry of Employment and the Economy.

For situations wherein a customer disputes a new sales agreement and the supplier does not agree to cancel or terminate the agreement, the cancellation or termination of the sales agreement must be made possible via a notification from the DSO for the accounting point. During the first phase, however, no functionality to send notifications of a dispute and




102 (203)

terminate agreements will be built in Datahub. During the first phase, situations will be dealt with manually such that the DSO will provide a written notification of a dispute to the Datahub operator who will then cancel the disputed agreement and send this information on to the supplier. The field will be monitored as to how much customers dispute agreements and based on this, a decision will be made as to whether a Datahub functionality for handling disputes is required.

3.2.4.5 DH-323 Accounting points without supplier

Datahub sends a notifications about accounting points without supplier to the distribution system operators, so that the DSO can end their own grid agreement or disconnect the accounting point if they want. The notifications about accounting point without supplier are sent daily. The notification specifies when the accounting point has been left or will be left without a supplier, and when the period without supplier will end, if there is later sales agreement for the accounting point in datahub. Datahub sends notifications even for short periods without supplier.

3.2.5 DH-340 Cancelling an agreement and correcting errors

Agreements are cancelled for the purpose of correcting erroneous agreements and when the customer exercises its statutory cancellation right in home and distance sales. In addition to the cancellation of agreements, it is possible to correct erroneous data arising solely from parties' mistakes by reporting the start or end of agreements retrospectively. Retrospectively means that the start date of a reported agreement or the date on which a terminated agreement ended falls on any day preceding the date on which the notification was made. In general, retrospective change refers to a change which changes any validity of a sales agreement in the past.

With regard to retrospective changes it is essential that both the validity of imbalance settlement (balance information) and the validity of the sales agreement (agreement information) are separately maintained by accounting point in Datahub. Balance information indicates the supplier on whose balance sheet the accounting point's consumption or production is calculated in Datahub's imbalance settlement calculations. Changes outside of the balance window that are included in balance information will be accounted for in balance error correction. Agreement information indicates which supplier has the right to accounting point data in Datahub (including metering data). Agreement information corresponds to the time during which the supplier has the right to invoice the customer. In normal situations, balance information corresponds to agreement information. Discrepancies between the balance information and agreement information may occur when corrections are made retrospectively.

3.2.5.1[3.2.4.6] Cancelling a sales agreement

Sales agreements are cancelled when a customer cancels an agreement using its statutory cancellation right or in error situations wherein a sales agreement or possibly grid




103 (203)

agreement are made for an incorrect accounting point or otherwise erroneously. Cancellation may be carried out before the agreement starts or retrospectively after the agreement starts. The cancellation process for these two events are processed in Datahub in different ways.

The supplier must report the cancellation of the agreement to Datahub. In most situations, when the sales agreement to be cancelled was originally reported, it terminated the preceding supplier's sales agreement at the accounting point. There is agreement in the field that the previous supplier should take the customer back unless the matter concerns a customer's fixed-term agreement that has already ended. If the previous supplier does not want to take the customer back, they can refuse the sales agreement restoration (event DH-343). Refusal of sales agreement restoration corresponds with agreement ending and it is always reported with termination as the reason for agreement end. If the supplier of the previous agreement wants to end their agreement after a cancellation with some other reason code, ending is reported with the regular agreement end event DH-331. There is not always a preceding supplier at move-in sites and naturally therefore, the agreement cannot be returned in these situations.

In its cancellation notification, the supplier must provide information as to whether the agreement was cancelled by the customer or the supplier. Cancellation by the customer may, for example, involve a cancellation based on the customer's cancellation rights or a cancellation based on erroneous information provided by the customer. If a customer’s cancellation concerns an agreement that was reported as a move-in, the supplier may report that the agreement is question is cancelled, but the move-in is not cancelled. If only the agreement but not the move-in is cancelled, the possible previous sales agreement is not restored on the accounting point.

In retrospective customer cancellations – that is, cancellations made after the agreement has started – the supplier retains the invoicing right/agreement information from the beginning of the agreement until the balance window has closed. In these cases it is not possible to automatically restore the previous supplier’s sales agreement, because despite the cancellation there will remain a period during which the agreement being cancelled is still valid. In this case datahub will forward a restoration date in it’s notification to the previous supplier so that the supplier can report a new sales agreement retrospectively to datahub using the date as start date, if they want to take the customer back. The diagrams below depict a customer cancellation before the agreement begins (1), customer cancellation of agreement but not the move-in before the agreement begins (2) and a retrospective cancellation (3).




104 (203)

FIGURE 1 SALES AGREEMENT CANCELLED BY THE CUSTOMER BEFORE THE AGREEMENT BEGINS (1), SALES AGREEMENT BUT NOT THE MOVE-IN CANCELLED BY CUSTOMER BEFORE AGREEMENT

BEGINS (2) AND CUSTOMER’S CANCELLATION AFTER AGREEMENT START DATE (3).

If there is no preceding supplier at the accounting point in connection with the customer's cancellation, the supplier will retain invoicing rights until the date of cancellation as shown in diagram 4. The supplier receives information as to whether the situation is as for diagram 3 or 4 by checking the confirmation of the sales agreement notification to find out whether Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



105 (203)

the sales agreement to be cancelled is registered as a move in or as a change of supplier. The situation in diagram 4 will apply for supplier B also if the accounting has a preceding supplier who will not take back the customer.

FIGURE 1 THE SITUATION AFTER A REPORTED CANCELLATION BY THE CUSTOMER WHEN THERE IS NO PRECEDING SUPPLIER

Supplier cancellations arise from various erroneous situations caused by the supplier. In these cases, Datahub sends the data concerning the cancellation of a sales agreement to the (possible) previous supplier of the accounting point and the previous sales agreement will automatically be restored. If there is no preceding supplier and a retrospective cancellation occurs, the accounting point will remain without a supplier from the date following the date of cancellation. Based on a relayed cancellation notification, the preceding supplier can report the termination of its own sales agreement to Datahub without the 14-day time limit if cancellation is made during the business day following the cancellation notification. If cancellation occurs before an agreement begins, the date of termination may not be earlier than the start date of the cancelled agreement. If cancellation occurs after the agreement's start date, the date of termination may not be earlier than the date on which cancellation is reported.

The diagrams below show how sales agreements cancelled by the supplier before the start date are processed in Datahub. Diagram 5 depicts a situation wherein supplier B cancels its agreement before the agreement begins and supplier A's agreement is restored by default. Diagram 6 depicts a situation wherein supplier A reports the cancellation of its own agreement to Datahub based on a report by supplier B. The process in diagram 6 is used also when the event is registered as customer cancellation.




106 (203)

FIGURE 1 CANCELLATION BY SUPPLIER BEFORE AGREEMENT STARTS. THE SITUATION AFTER CANCELLATION HAS BEEN REPORTED (5) AND THE SITUATION AFTER THE POSSIBLE REFUSAL OF

THE PRECEDING SUPPLIER TO RESTORE AN AGREEMENT (6).

In Datahub, cancellations made after an agreement has begun are processed such that supplier B's agreement is cancelled on the same day the cancellation is reported. Supplier A receives a report on the cancellation of the agreement and without further action, supplier A's ended agreement is restored in Datahub. Once it has received the report, supplier A can, as set out above, terminate its own sales agreement without time limit validation (such as that for a move out) no later than on the following business day. Supplier A may not, however, terminate its agreement retrospectively; it can only do so by the end of the day or on a later date. After the following business day has passed, normal time limits for termination will apply to supplier A's agreement.

Diagram 7 below shows a situation in which supplier B cancels its agreement in Datahub after the agreement has begun and supplier A does not terminate its own agreement. Balance information is only corrected for supplier A within the balance window. Diagram 8 outlines the corresponding situation in which supplier A terminates its own agreement. The accounting point is left without a supplier in accordance with supplier A's termination notification. Datahub notifies the DSO of the accounting point without a supplier.




107 (203)

FIGURE 1 SUPPLIER CANCELLATION AFTER AN AGREEMENT HAS BEGUN. THE SITUATION AFTER CANCELLATION (7) AND THE SITUATION AFTER THE POSSIBLE REFUSAL OF THE PRECEDING

SUPPLIER TO RESTORE AN AGREEMENT (8).

If, regarding retrospective cancellation by a supplier, there is no previous sales agreement for an accounting point, the accounting point will remain without a supplier for the entire period after cancellation. Supplier B is, nevertheless, responsible for balances until the date of cancellation in accordance with diagram 9. If supplier B becomes aware of a customer that has used electricity at the accounting point during this time, supplier B can retrospectively report the start of a sales agreement after reaching agreement with the customer.

FIGURE 1 CANCELLATION BY THE SUPPLIER WHEN THERE IS NO PRECEDING SUPPLIER




108 (203)

In addition to the previously described situations, it is possible that the customer or the supplier cancels the agreement before delivery starts to an accounting point, which has no preceding supplier. In this case, the agreement and balance information return to "without supplier" starting from the first day of the cancelled agreement, as depicted in diagram 10.

FIGURE 1 CANCELLATION BEFORE AGREEMENT START WITHOUT A PREVIOUS SUPPLIER

If there already is a future sales agreement on the same accounting point in datahub that starts after the agreement being cancelled, the previous agreement is restored only until the start date of the future agreement, as depicted in diagrams 11 and 12.

FIGURE 1 CANCELLATION BEFORE AGREEMENT START WHEN THERE IS A FUTURE AGREEMENT

Diagram 13 depicts the handling of agreement and balance information when a customer cancels an agreement after the agreement start date and there already is a future agreement on the accounting point starting after the agreement being cancelled. Because agreement B remains valid for the period outside the balance window, supplier A’s agreement cannot be automatically restored in datahub. As in the case of diagram 3, a restoration date is forwarded to supplier A so that they can report a new agreement to datahub with that start date, if they want the customer back.




109 (203)

FIGURE 1 CANCELLATION AFTER AGREEMENT START WHEN THERE IS A FUTURE AGREEMENT ON THE ACCOUNTING POINT AS SUPPLIER’S CANCELLATION (12) AND CUSTOMER’S CANCELLATION (13)

If the agreement that is being restored because of the cancellation already had an end date before the agreement that is now being cancelled caused the agreement to end earlier, the previous agreement is restored with the end date it had before the agreement being cancelled was reported. Diagram 14 depicts a cancellation before the agreement start when the previous agreement has had an end date.




110 (203)

FIGURE 1 CANCELLATION BEFORE AGREEMENT START WHEN PREVIOUS AGREEMENT HAS AN END DATE

If agreement cancellation is reported after the agreement start and the previous agreement has had an end date, the previous agreement is restored with the original end date in case of supplier’s cancellation (diagram 16). In case of retrospective customer’s cancellation, the cancelling supplier retains the invoicing right/agreement information from agreement start date until the date of reporting the cancellation (diagram 15). In both cases the balance responsibility remains with the cancelling supplier until the date the cancellation is reported.




111 (203)

FIGURE 1 CANCELLATION BY CUSTOMER (15) AND SUPPLIER (16) AFTER THE AGREEMENT START WHEN THE PREVIOUS AGREEMENT HAS AN END DATE

If the agreement being cancelled has an end date in datahub, that does not affect the restoration of the previous agreement. If the previous agreement has not originally had an end date, the previous agreement is restored as valid until further notice (diagram 17), or in case the accounting point already has a future agreement, the previous agreement is restored as valid until the start date of future agreement (diagrams 18 and 19).




112 (203)

FIGURE 1 THE AGREEMENT BEING CANCELLED HAS AN END DATE, CANCELLATION BEFORE AGREEMENT START WITH NO FUTURE AGREEMENT (17) AND WITH FUTURE AGREEMENT (18), AND

SUPPLIER’S CANCELLATION AFTER AGREEMENT START (19)

The cancellation of sales agreements may also lead to the cancellation of the grid agreement. The DSO must cancel confirmation of a grid agreement in Datahub if the grid agreement was originally confirmed based on a cancelled sales agreement. The old grid agreement will be automatically restored in Datahub based on a cancellation if this grid agreement was created in Datahub in connection with the creation of the sales agreement that is to be cancelled. If the previous supplier does not take the customer back and reports this as termination of an agreement in Datahub, the DSO must terminate the grid agreement in Datahub via its own notification.

The diagram below presents the cancellation process in its entirety.

FIGURE 1 SALES AGREEMENT CANCELLATION PROCESS

3.2.5.2[3.2.4.7] Retrospective error correction

Retrospective changes to agreement start and end dates may only be made in clear cases of error. The rule of thumb for retrospective corrections is that the balance information is determined according the supplier that made the error, and agreement information is determined based on who will have the right to invoice the customer. The principle is that the supplier which made the error is responsible for the balance sheet even if it does not have the right to invoice the customer.

The supplier reports the retrospective start of a sales agreement using the same notification used to report an upcoming sales agreement. The report of a new retrospective Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



113 (203)

sales agreement progresses like a normal process if there are no other suppliers' agreements valid for the accounting point after the date on which the reported sales agreement begins. In other cases, a sales agreement that begins retrospectively will not progress as a normal process and instead Datahub locks the process and responds with negative confirmation to the notification of a sales agreement which is to begin retrospectively. In order for the processing of the sales agreement to continue, the reporting supplier must manually process the data in Datahub's interface.

The supplier must provide an explanation in the interface as to why the agreement should begin retrospectively and submit the processor's contact details for clarification. After this, Datahub will notify the current supplier of the new supplier's explanation and contact details by e-mail and create a retrospective start approval request for the current supplier in Datahub's interface. The current supplier must approve the retrospective start in the interface in order for processing of the retrospective sales agreement to continue.

If the current supplier approves the retrospective start, the agreement process continues as normal. Upon rejection by the current supplier, negative confirmation will be sent to the new supplier that reported the retrospective agreement. If the current supplier neither approves nor rejects the retrospective start, Datahub will send a reminder to the current supplier after 2 business days and, if necessary, the Datahub operator will contact the current supplier directly. After a retrospective sales agreement has been approved, the agreement and balance data for an accounting point are determined based on the new supplier's notification as shown in the figure below.

FIGURE 1 CURRENT SUPPLIER APPROVES THE RETROSPECTIVE NEW AGREEMENT

If between the start date of an agreement that begins retrospectively and the time of reporting there are valid sales agreements from more than one different supplier, the aforementioned procedure cannot be applied. In this case, the Datahub operator will investigate the details of all parties and guide them in resolving the matter amongst themselves. After the parties have come to a decision on a solution, the Datahub operator will make the necessary changes in Datahub.

The retrospective terminations of agreements mustare primarily be carried out usingdone as a part of retrospective new agreement start date, whichnotifications, when the reported new Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



114 (203)

agreement automatically terminatesends the previous sales agreement. This procedure should be followed if, for example a bankrupt company's agreement is retrospectively transferred to the bankrupt's estate. If in the given situation this is not a rational option, the salesMarket parties cannot separately report retrospective agreement can be terminated retrospectively via a separate notification. In these cases, however, the use or production of electricity at the accounting point is recorded in the reporting supplier's balance sheet until the end endings (DH-330 events) except in case of the day on which the report was submitted and the balance information for the accounting point is recorded accordingly as shown in the diagram below.

Figure 1 Retrospectively ending an meter removal. If a retrospective agreement ending is needed because of an error situation, the market party must contact the datahub operator who can end an agreement retrospectively. In addition to the aforementioned cases, there may be situations in which there is a need to retrospectively change the start or end dates of a previously reported agreement. The principles mentioned above shall be followed in these situations. The start and end dates of agreements cannot be changed using a data update in Datahub. Instead, the earlier notification must first always be cancelled and then a new notification should be made with a corrected date.

The aforementioned correction procedures should only be used in cases of error. Retrospective changes are monitored and possible misuse will not be tolerated. If the situation requires an accounting point's balance data to be recorded in a manner other than that specified above, the market party or market parties must contact the Datahub operator, which will make the necessary changes based on a written request. If the new sales agreement is reported retrospectively to Datahub in error cases, Datahub will not automatically transmit the metering data for that retrospective period. The Supplier who has reported the sales agreement receives the metering data from Datahub with a metering data request event.

3.2.6[3.2.5] Other types of agreement

Datahub will not maintain any information of the so called background agreements that are used in current market by some market parties. Every time a background agreement is reported to Datahub it is reported with normal agreement processes and treated as normal agreements.




115 (203)

3.2.6.1[3.2.5.1] Small-scale production purchase agreements

In accordance with existing practices, small-scale production sites are assigned their own accounting points in Datahub and their own individual processes are initiated. Small-scale production agreements are processed in the same way as traditional consumption accounting point agreements, meaning that there are no differences between agreement processes for small-scale production accounting points and consumption accounting points. In Datahub, agreements linked to a production accounting point are considered to be purchase agreements or small-scale production grid service agreements.

If a production accounting point is connected to a consumption accounting point and the consumption accounting point's sales agreement is terminated with the reason "moving out", this information will be sent to the DSO and to the purchase agreement's supplier. The linking of consumption and production accounting points also makes it possible for a supplier making a new agreement to use a preliminary search to find out whether the accounting point is connected to a production accounting point.

3.2.6.2[3.2.5.2] Electricity delivery agreements

Electricity delivery agreements do not set any special requirements for Datahub. In Datahub, electricity delivery agreements are processed as a separate sales and grid agreement. However, only the supplier with the delivery obligation in the metering grid area can report an electricity delivery agreement. The supplier must inform Datahub if an agreement is an electricity delivery agreement so that the DSO knows not to send grid agreement confirmation to the customer when it receives information about the new agreement from Datahub. Correspondingly, if an electricity delivery agreement is converted into separate agreements, the DSO knows based on this information that it should send a separate grid agreement confirmation to the customer. Information concerning an electricity delivery agreement may also be used to investigate the quantity and relative proportion of such agreements.

The supplier with delivery obligation has the right to obtain information as to whether the customer comes under the scope of delivery obligation or not in accordance with the obligation to deliver set out in section 21 of the Electricity Market Act. In addition, the supplier with delivery obligation also has the right to receive information, in the form of total energy data, to indicate how much of the customer base covered by the scope of delivery obligation are supplied by other suppliers. Datahub will provide this data to the supplier with delivery obligation by report via Datahub's user interface.




116 (203)

3.3 DH-200 Processing metering data

3.3.1 Metering data

FIGURE 1 CLASS DIAGRAM FOR METERING DATA

The diagram above outlines the data structure of metering data. In Datahub, there are three kinds of metering points: accounting points, exchange points and production units (NBS' Production Unit/PU). Metering data relates to all metering points but a metering time series can only relate to a single metering point. It is possible to report reactive energy input and output measurements to all metering points. It is not possible for an accounting point to have two (active energy) metering time series that are used in invoicing and imbalance settlement. As an example, in sites where accounting point consumption consists of several metering time series, only one (sum) time series is reported to Datahub. An exchange point can have one to four metering time series depending on whether electricity




117 (203)

can be transmitted to both directions and whether reactive energy of the exchange point is also forwarded. Each exchange point must include data specifying either the direction of the electricity transmission at the exchange point or specifying that electricity can be transmitted to both directions. A production unit's own consumption is reported for a consumption accounting point which subtype is production unis own consumption, created specifically for that purpose. For each exchange point a so-called metered data responsible MGA is defined. Metered data responsible MGA refers to the metering grid area that is managed by the metering responsible DSO of the exchange point. The metering responsible DSO reports energy transmitted in different directions at an exchange point (from a metered data responsible MGA to parallel MGA and vice versa) separately using two active energy metering time series, and if needed with two reactive energy metering time series. Metering data does not deal with readings; instead all metering data must be converted into time step energy (=average hourly power for an hourly metering).

It is possible to report to Datahub and retrieve from Datahub metering values using the desired unit (Wh, kWh, MWh, GWh or varh, kvarh, Mvarh, Gvarh). For an accounting point at which the fuse size or corresponding electric power is max. 3x63 A, metering data must be reported to an accuracy of 10 watt-hours. Otherwise, metering data must be reported to an accuracy of at least one kilowatt-hour. When reporting metering data, attention must be paid to the number of decimal places concerning the aforementioned accuracies. For example, kilowatt-hours (kWh) must be reported to at least two decimal places for an accounting point of max. 3x63 A. When searching for metering data, please specify the units you would like the search to return.

DSO must report metering data using the time step that is specified in the law and that is used in the imbalance settlement. Currently this time step is one hour, but analysis of changing to 15 minute time step and transition period related to it is already in progress. Because of this, datahub will support different time steps for metering data (e.g. 15 minutes and 1 hour). Metering data can still always be retrieved from Datahub using the desired time step (e.g. 15 minutes, hour, month). If no time step has been submitted for the search, Datahub will return the metering data using the unit provided by the DSO.

Datahub supports the audit-trail function, meaning that all changes made to metering data are recorded in the history data.

The DSO must report metering data timestamp, metering value and metering data status in metering data report. In addition to these, datahub maintains information about the edit time, editor and the reception time for metering data. The time of update is determined based on the time at which Datahub stores the data in its database. The editor attribute keeps track of which process or user has edited the information at the edit time. In general, only the DSO can update metering data with metering data reports. Datahub operator will edit metering data only at the request of the market parties in special error situations and the edited data will be relayed to the parties with rights to it. Datahub also registers separately the storage time of the metering data, which can be used to accurately verify afterwards, at what time datahub received the metering data.




118 (203)

Only positive values are processed in Datahub, so e.g. consumption and production should always be separately reported. Metering data is processed in accordance with official Finnish time. When moving clocks forwards and backwards to account for daylight saving time, the length of day is either 23 or 25 hours accordingly.

3.3.2 DH-210 Reporting metering data

The rule of thumb is that only new and changed metering data should be reported to Datahub. There is no need to report metering data for entire 24-hour periods.Datahub will always send data from the same period, as it was sent to Datahub. Changes in status are also interpreted as a change to metering data, even if the metering data itself remains the same.

It is usually the obligation of the metering responsible party at the metering point to report data to Datahub. At accounting points, the metering responsible party is always the DSO. The metering responsible party is often different from the DSO, for example, at exchange points where the metering responsible party could be the main grid owner.

3.3.2.1 Time limits for reporting metering data

Time limits for reporting metering data to Datahub are determined in accordance with the messaging decree [1]. In this document, time limits are currently determined based on the metering decree, which will take effect with Nordic Balance Settlement.is still in preparation. The datahub deployment will require changes to national laws, and at the same time the balance settlement time limits will be checked and updated if necessary. Datahub's time limits do not distinguish weekday public holidays and weekends, which corresponds to the Nordic Balance Settlement practice.

Preliminary metering data for the previous day must be reported to Datahub by midnight on the following day. In accordance with the future imbalance settlement schedule, a DSO's final metering data for imbalance settlement data must be reported to eSettdatahub for a delivery date of 11 days ago no later thanby 00:00 Finnish time, after which time the balance window for the delivery date in question will close. In practice, Datahub requires a little time to carry out imbalance settlement calculations before data is submitted to eSett. As such, final metering data should be submitted to Datahub in sufficientwill have the next day time before the balance window closes. A rule of thumb is that Datahub requires four hours to carry out imbalance settlement calculations and report the calculation results to eSett. During this time, Datahub processes and validates metering data, carries out calculations and submits the data to eSett. Sufficient time should be reserved for these actions in order to comply with imbalance settlement time limits in all situations.




119 (203)




120 (203)

FIGURE 1 TIME LIMITS FOR REPORTING METERING DATA. THE RED TEXT SHOWS THE METERING RESPONSIBLE PARTY'S TIME LIMITS FOR SUBMISSION TO DATAHUB AND THE GREEN TEXT SHOWS

DATAHUB'S TIME LIMITS FOR SUBMISSION TO ESETT.

It is not permitted to report future metering data or very old metering data (more than 6 years).

3.3.2.2 Metering data validation

The responsibility for validating metering data and submitting accurate metering data to Datahub lies with the metering responsible party. Datahub carries out simple validation for metering data in cases where the DSO's validation is not at a sufficient level. The most significant validation carried out by Datahub is status validation, the rules for which are set out in section 3.3.2.3.

Datahub performs validation on negative and excessive values, depending on the type of metering point. A value is deemed to be excessive if it is more than ten times the electric power that was reported to the accounting point. Production capacity is used respectively as a benchmark for production units. If the electric power for an accounting point is not reported to Datahub, the fuse size should be reported, whereupon electric power will be calculated from the fuse size. Metering time series data rejected in validation will not be stored in the database and will return time series-specific rejection information. The table below lists validations carried out by Datahub by metering type.

TABLE 1 METERING DATA VALIDATION

Metering type Grounds for rejection

Accounting point consumption

Erroneous status, negative values, values which exceed electric power by a factor of 10.

Accounting point production

Erroneous status, negative values, values which exceed production capacity by a factor of 10.

Reactive energy output/input Erroneous status, negative values

Exchange point Erroneous status, negative values




121 (203)

metering

Production unit metering

Erroneous status, negative values, values which exceed production capacity by a factor of 10.

3.3.2.3 Status processing

The table below outlines the statuses used in Datahub from weakest to strongest and also the time limits according to which the status must be replaced with a stronger status.

TABLE 1 METERING STATUSES USED IN DATAHUB

Status ExplanationPermitted replacement statuses

MissingUsed if no data has been obtained from the meter and preliminary data is sent as zero use. The status of data denoted as "Missing" must always be replaced with a stronger status within 5 days.

Uncertain, Estimated or OK

Uncertain

Used when it is assumed that data may become more detailed or change later on. The "Uncertain" status is most typically used when it is necessary to estimate missing metered data, but it is assumed that the measured data will be obtained later on. Data assigned an "Uncertain" status must primarily be replaced with a stronger status before the balance window closes5.Also used for reading metering profiles when the profile is calculated based on an annual use estimate.

Uncertain, Estimated or OK

EstimatedUsed when it is necessary to estimate metered data and it is known that no measured or more detailed data will be obtained later on.

Estimated, (As necessary) Corrected OK

OK

Used for metered data obtained from the meter, if there is no reason to assume that the meter value is erroneous.Also used for reading metering profiles when time series values are calculated from the meter reading.

(As necessary) Corrected OK

Corrected OK

Used when metered data previously sent with an "OK" or "Estimated" status nevertheless has to be corrected.

Values may be changed, but it is not possible to replace the status with a weaker status.

5 In exceptional situations, the "Uncertain" status may remain even after the balance window has closed [2].Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



122 (203)

Datahub will not reject metering data if the status is not within the time limits set out above. Datahub will however reject metering data if attempts are made to replace metering datawith status that is against permitted replacement statuses. Monitoring will be constructed for Datahub with which to identify and take action to stop market parties who deviate from the abovementioned rules.

In sum calculations, such as when calculating a supplier's metered sum delivery, the status of the sum time series is determined in accordance with the time series that has the weakest status of all of the time series used in the calculations.

3.3.2.4 Monitoring of metering data reports

Datahub will send reminders to the DSO or metered data responsible, if DSO has delegated such role to third party, if parties fail to comply with the reporting time limits and status processing instructions set out above. Reminders will be sent when

Preliminary metering data for the day of delivery (the previous day) has not been reported at all by the end of the day

Data assigned a "Missing" status has remained unestimated for 5 days after delivery or

There is still metering data with an "Uncertain" status after the balance window has closed.

In the first two cases set out above, reminders will be sent once a day until metering data is corrected or submitted. In the last case, a reminder will be sent only once, because in some situations there is reason to retain an "Uncertain" status even after the balance window has closed. However, reminders of metering data with "Uncertain" status will not be sent for reading metered metering points.

Reminders will only be sent once the relevant time limit has been exceeded. The industry will largely trust the DSOs to comply with agreed rules and to implement the necessary processes for these purposes in their own system. The purpose of reminders is to draw attention to non-compliance with rules. If a DSO does not change its operating methods despite repeated reminders, action will be taken against such activity. Reminders will be sent only for valid metering points and only if the accounting point grid agreement is valid.

The distribution system operator users must determine in Datahub user interface whether electricity can be transmitted to only one direction or both directions at an exchange point. For exchange point measurements, metering data delivery is monitored separately for each direction. If metering data is reported “to the wrong direction” for an exchange point, it will be reported to the distribution system operator.




123 (203)

In addition to aforementioned reminders, DSOs will be notified if other than zero values are reported to disconnected accounting points. In these cases the DSO must find a reason for non-zero values and correct either the metering data or the accounting point status.

3.3.2.5 Transmitting metering data

All metering data, which is sent to Datahub, is automatically transmitted to all parties entitled to receive the data. If the DSO has delegated metering data reporting to a service provider, the metering data reported by the service provider can be forwarded to the DSO. Datahub forwards metering data to only one system for each party. If a party needs metering data in more than one of its own systems, the party is responsible for distributing the metering data between its own systems. If for some reason a party does not require automatic data transmission in its own operations, the party can opt out of data transmission in the Datahub user interface. In such cases the party can use the separate metering data retrieval event (DH-220).

The metering data relay message includes the time when time series data was stored in datahub. Based on this information, the recipient can determine whether the received metering data has been included in the balance when metering data is reported near the closing of the balance window.

3.3.3 Processing reading metering and unmetered sites

Datahub does not receive or process reading metering readings. The DSO must calculate or otherwise compile reading metering profiles by accounting point and report them to Datahub. In Datahub, profiles should be created according to the type user group 1 reference curve set out in the current metering decree. This procedure requires changes to the content of the metering decree. The profile will be created based on an annual use estimate for the accounting point. There will be a move away from the use of a so-called balancing energy forecast calculated for type user group 2 and the related temperature adjustments which are currently used.

Profiles calculated by DSOs based on an annual use estimate will be reported to Datahub with the status "Uncertain". The status "OK" will be reported for profiles when the DSO reads the readings from a meter and then, based on the reading, calculates an adjusted profile up to the previous reading time. As such, the same status rules apply to reading metering as for other metering. If a DSO adjusts the status of a profile reported as "OK", the adjusted metering data must be reported with the status "Corrected OK".

There are some accounting points at which there is no energy metering. These are usually referred to as unmetered accounting points and constant power sites. The DSO must also report metering data in time-series format for these sites. The DSO may compile a profile for an unmetered accounting point in the manner it sees fit, such as reporting the same energy for each time step or by using the aforementioned type user group 1 reference curve.




124 (203)

Metering data from an unmetered accounting point is assigned the "Estimated" status and adjustments are made using the status "Corrected OK".

The profiles for reading metering sites and constant power time series are reported in Datahub in the same manner and with the same time limits and validations as for other metering data.

3.3.4 Correction of metering data

The DSO must correct erroneous metering data in Datahub for the entire time during which the metering data is stored in Datahub (6 years). Corrected metering data is sent to all parties entitled to the data in accordance with their rights. As such, parties can receive corrected metering data for the entire time during which the metering data is stored in Datahub.

Corrections to metering data may relate to the correction of a customer's invoice if the customer has already been invoiced based on erroneous data. In these cases, Finnish Energy's guidelines [2] will be followed also in the future. The instructions are applied in datahub so that a metering data correction is reported to datahub when the customer has been notified or an agreement has been reached with the customer about the correction of metering data. Thus the customer's correction invoicing is done, on the part of metering data changes, by the suppliers who on the date of the metering error correction report have a valid agreement or an agreement that has ended at most six weeks ago from the date of metering data correction report on the accounting point for which the metering data is corrected. For a supplier change of agreement, i.e. new agreement by the current accounting point supplier where at least one customer remains the same, does not break the responsibility to make corrections. This is described in more detail in the figure below.

FIGURE 1 CHANGE OF AGREEMENT AND INVOICING CORRECTION RESPONSIBILITY IN METERING DATA CORRECTION SITUATION




125 (203)

The DSO is always responsible for invoicing corrections related to their own grid service and related to sales agreements that ended over 6 weeks before the metering data correction report (corrections to customers B and C in the above figure). Metering data corrections are taken into account in correction of balance deviations so that balance deviation is recorded always for the effective time of metering error when the invoicing correction of sales agreement is the responsibility of the supplier.

3.3.5 Processing reactive energy data

Datahub allows the reporting and retrieval of metering data on reactive energy input from the grid (inductive) and output to the grid (capacitive) to accounting points, production units and exchange points. With regard to reactive energy Datahub acts solely as a data transmitter. As such, Datahub does not carry out calculations for reactive energy metering data or monitor reports of this data. Only the validation of negative values and status transitions will be carried out for reactive energy metering data, since grid input and output must be reported in their own time series. Reactive energy data is not automatically transmitted to suppliers. A data field will be added to the accounting point that indicates that reactive energy metering data is available for the accounting point. Based on this information, the supplier may order the transmission of metering grid areas reactive energy metering data in the Datahub interface. Information concerning the availability of reactive energy metering data is updated by Datahub depending on whether the DSO has reported new reactive energy metering data in the last month.

3.3.6 Processing exchange point and production unit metering

Exchange point and production unit metering data is required in Datahub in order to calculate a DSO's imbalance settlement. This metering data is reported in the same way as other metering data and metering data can also be corrected outside the balance window. However, balance deviations are not registered based on metering data corrections for exchange points and production units. Instead, possible monetary corrections caused by these corrections will be handled privately between the metering responsible party and its counterpart (another grid owner).

Exchange points and production units have similar connection status information as accounting points have. Grid operator can temporary remove production unit or exchange point from use by changing the connection status to ‘under construction’. In this case, no metering data needs to be reported to these metering points.

It is the obligation of the metering responsible party of the metering point to report exchange point metering data to Datahub. As such, the transmission system operator and regional grid companies, for example, must report exchange point metering data if the imbalance settlement for the exchange point's other metering grid area is processed in Datahub. The validation and processing of exchange point and production unit metering correspond to the processing of other metering data where applicable.




126 (203)




127 (203)

3.4 DH-400 Connection and disconnection processes

3.4.1 General description

From Datahub's perspective, connections and disconnections are changes in accounting point status that are reported separately in conjunction with agreement processes and during delivery with regard to parties' debt collection processes or modification work carried out at the accounting point. Datahub forwards the supplier's requests for a change in accounting point status to the DSO and sends data on the completed status change from the DSO to the supplier.

Time limits for connection and disconnection requests are determined based on the part of the overall process for which the procedure is performed. When connection or disconnection occurs as part of a moving process, no separate connection or disconnection request is made, and instead the DSO connects or disconnects the accounting point's electricity as necessary at the end of the agreement process, whereupon the time limits for information exchange are determined in accordance with agreement processes. As such, in cases concerning a move in, it may be possible under certain conditions to achieve connection at an accounting point on the same day (a more detailed description can be found in agreement processes). The operating model for reconnection differs by grid company. Connection contact person and their telephone number are always reported in a supply connection request, so that the DSO can ensure a safe connection.

The supplier must make the disconnection requests relating to the debt collection process no later than one week before the desired date. Once the customer pays the outstanding invoice, good customer service dictates that reconnection should take place as quickly as possible. If the customer pays the bill before the requested disconnection date, cancellation of disconnection shall be reported with a cancellation notification. If the customer pays the bill on the date of the requested disconnection, the supplier must request supply connection for the accounting point. This is the procedure, because the DSO may not be able to cancel the disconnection on the same day the disconnection is meant to take place. Datahub forwards the supplier's supply connection request in real time to the DSO, who then handles the connection request for the disconnection date according to their own processes. If the DSO is able to cancel the disconnection based on the connection request sent on the date of disconnection, the DSO shall reply to the original supplier's disconnection request with a notification of supply disconnection, where the accounting point status is "connected". In addition the DSO must reply to the supplier's supply connection request respectively. Otherwise the DSO must report the executed supply disconnection according to normal processes. The procedure described previously ensures that the original supply disconnection request can be handled completely in all cases and datahub will not keep waiting for a supply disconnection notification from the DSO if the disconnection is not executed.




128 (203)

DSO may not reconnect an accounting point before the supplier requests the reconnection if the accounting point has been disconnected at the request of the supplier. If the supplier needs to inform the DSO that an already disconnected accounting point should not be connected, the supplier shall send a disconnection request for the accounting point. The DSO shall respond with a new notification of disconnection with the actual disconnection date even though the DSO would have already reported a disconnection for the accounting point on their own account.

When the DSO’s supply connection or disconnection event is used to change the status of an accounting point from under construction to connected or disconnected, the DSO needs to remember to update accounting point characteristics if they have been missing previously. Datahub will not allow connection or disconnection of an accounting point, if mandatory information from accounting point characteristics is missing.

By default, the DSO reports the completed connection or disconnection as soon as the information is available in the DSO's own system, as is the case for any other accounting point data update. If the matter concerns a site where connection or disconnection is carried out manually, there may be a delay in updating the data in the DSO's system and therefore to Datahub. The maximum permitted length of the delay is one week. Longer delays in answering the connection or disconnection requests will be monitored by the Datahub operator. Accounting point connection and disconnection requests are not validated based on status information in Datahub, since status information could be temporarily erroneous due to the delay. The supplier can always send connection or disconnection requests based on Datahub's status information. The DSO has the correct status information, so it is able to correctly handle the supplier's requests in its own processes. One example of the operating method is a situation in which a supplier has first requested disconnection due to debt collection and the DSO manually disconnects electricity from the accounting point in the morning of the day on which the request was made. The customer informs the supplier that it has paid the invoice as soon as the electricity is disconnected, but the supplier does not see the correct accounting point status in Datahub since the DSO does not yet have the information in its own system due to the manual disconnection. Even though the accounting point's status in Datahub is connected, the supplier may send a connection request to Datahub which the DSO can send on to an engineer.

If the DSO is unable or unwilling to carry out the connection requested by the supplier, the DSO communicates this by using notification of connection delay event on the following working day after the requested connection or disconnection date at the latest. Longer delays in answering the connection or disconnection requests will be monitored by the Datahub operator. The reason for not connecting the accounting point according to supplier’s request can be forwarded in the description of the event. If needed the delay can be reported multiple times. If the DSO is unable to carry out the requested disconnection on the date requested by the supplier, the electricity delivered to the accounting point must be included in the DSO's balance sheet. The DSO must report this delay to the supplier via Datahub. The electricity delivery of an accounting point is calculated to the balance of the




129 (203)

supplier starting from the moment the DSO connects the accounting point based on the supplier's request. However, if the connection is for some reason reported late outside the balance window, any possible electricity consumption on the accounting point outside the balance window is calculated into the losses of the metering grid area. DSO cannot in all situations estimate the right date for actual connection or disconnection. DSO can use the same delay notification several times if needed.

The DSO usually charges a fee for disconnections and connections carried out at short notice, outside of business hours or without remote connection. In these cases, the DSO invoices either the supplier or the customer, depending on which party has requested the connection or disconnection. DSOs' price lists are collected in a fixed form table in ediel.fi portal in order for the supplier to be able to easily provide the customer with additional information concerning the costs of connections and disconnections. These situations most often relate to moving processes in which the move in takes place quickly. Using the DSO's pricelist as an aid, it is easier to agree the start date of an agreement with the customer and to inform the customer of any costs arising due to the rapid schedule.

During delivery, the customer may also require connection or disconnection to the accounting point due to e.g. renovation. In these cases, the customer should contact the DSO. In those cases when the DSO is dismantling the accounting point they might have the need to notify about the disconnection before they notify that it is removed from use. In these cases the status disconnected is notified by using disconnection event and the status “removed from use” is notified by using the accounting point update event.

In situations wherein disconnection of an accounting point leads to the disconnection of a production accounting point in the same physical location, the DSO must report the completed disconnection to both accounting points.

3.4.2 Process descriptions

The following figures describe disconnections and connections requested by the supplier as well as the overall processes for disconnections and connections reported by the DSO.




130 (203)

FIGURE 1 DISCONNECTION PROCESS INITIATED AT THE SUPPLIER'S REQUEST

FIGURE 1 CONNECTION PROCESS INITIATED AT THE SUPPLIER'S REQUEST




131 (203)

FIGURE 1 DISCONNECTION PROCESS INITIATED AT THE DSO'S REQUEST




132 (203)

FIGURE 1 CONNECTION PROCESS INITIATED AT THE DSO'S REQUEST




133 (203)

3.5 DH-500 Distribution system operator's imbalance settlementThis section describes the DSO's imbalance settlement calculations performed in Datahub and imbalance settlement data notifications to eSett and market parties. After implementation, Datahub will handle imbalance settlement reporting to eSett on behalf of the DSO. This will apply to all data. For this purpose, user interface will be created in Datahub, also for maintenance of so-called structural information. The user interface will enable the parties to maintain information which has no defined messaging processes that could be used to maintain it. Datahub will also send the DSO data about metering grid area imbalance and MGA exchange confirmations calculated by eSett.

The DSO is responsible for reporting the settlement data required to calculate the imbalance settlement described in this section to Datahub in accordance with the agreed rules and deadlines. Datahub is responsible for performing the imbalance settlement calculations and sending these to eSett in compliance with the rules of the Nordic balance settlement model (NBS). The rules of the NBS model are described in a handbook released by eSett [3]. Imbalance settlement data can also be retrieved from Datahub by parties entitled to this data.

The diagram below describes the daily imbalance settlement process. The most important tasks in the process are executing the imbalance settlement calculations based on structural information and metering data, and information exchange of balance settlement data. Imbalance settlement calculations depend on DH-100, DH-200, DH-300 and DH-400 processes, and on structural information, which is maintained via user interface. The information, which is handled in balance settlement and exchanged between parties, is described in more detail later in this chapter.




134 (203)




135 (203)

FIGURE 1 IMBALANCE SETTLEMENT PROCESS IN DATAHUB

3.5.1 Initial data for balance settlement

Imbalance settlement data consists of structural information and metering/time series data. Structural information defines to which party's balance and to which metering grid area each metering point's metering data (metered consumption or production) is calculated in balance settlement calculations executed by datahub.

According to the new Nordic Balance Settlement model, an imbalance statement by a DSO is calculated by metering grid area. DSOs can divide their grids into one or more metering grid areas. However, DSOs usually have only one metering grid area. The figure below presents the data used as the basis for imbalance settlement calculations in Datahub. With the exception of electricity sales agreement information, the DSO is responsible for maintaining this data. Technically, however, the datahub operator will maintain metering




136 (203)

grid area data, because this data affects significantly and widely other processes and data in datahub, for example imbalance settelement calculations and accounting point data. The goal of this procedure is to ensure that all necessary changes, like ending and adding metering grid areas, are done in a controlled manner taking all viewpoints into consideration.

Relations marked with blue have a time when they are valid. This means that for example the loss supplier of a metering grid area may change with time and the system must be able to handle these changes so that the history data is maintained. When interpreting the figure, one must take into account that for some of these relations only one relation at a time can be valid, even though the relation is marked with "1..*". Accurate relation definitions can be found in data standard. Validity of the relations related to balance information is based on the validity of the balance information. Datahub handles also market balance area information, although Finland has only one market balance area. This ensures that datahub supports the structure of general electricity market for possible future demands.




137 (203)

FIGURE 1 DATA USED IN IMBALANCE SETTLEMENT CALCULATION

The foundation for imbalance settlement calculations is the metering data from the metering points: accounting points, exchange points and production units. Metering points always belong to one metering grid area at a time. However, the system must be able to handle situations where metering points move to another metering grid area at a defined time. These situations may occur when metering grid areas unite or divide into a larger number of metering grid areas. These situations and their management are described in more detail in section 3.11. Datahub must include the possibility to define to which market balance area each metering grid area belongs to at a given time so that it supports the general structure of the electricity market.

The DSO maintains accounting point data by means of the accounting point data maintenance events (DH-120). The exchange point and production unit information is maintained via the Datahub interface. This information must be created via the interface before the metering data for the metering points in question is reported. The DSO also maintains the information about the production unit supplier. The metering data of all metering points is reported in accordance with event DH-211 metering data report. The DSO must also use the interface to maintain information about which suppliers at a given time are responsible for the open supplier and loss supplier roles for the metering grid area (imbalance). There will be a report available for DSOs where the structural information, excluding the accounting point specific settlement data, depicted in the figure above are printed.

Using the user interface, the DSO may use delegation to authorise other parties to exchange point and production unit metering data. For exchange points, only the DSO of the metered data responsible MGA can do the delegation. In that case, the metering data of these metering points will automatically be forwarded to the authorised parties. By default, exchange point metering data will always be forwarded also to the DSO of the exchange point's other metering grid area when both metering grid areas of the exchange point do not belong to the same DSO. Information about the electric station and its field, to which an exchange point is connected, will be in the datahub to make information processing easier in the market parties' own processes and in datahub.

Accounting point metering data is linked to supplier in balance settlement calculations using so called balance information. If an accounting point does not have a valid balance information, the possible production and consumption of the accounting point are calculated into the losses of the metering grid area, in other words to the balance of the DSO. Most of the time the validity of the balance information is similar to the start and end dates of the accounting point's sales agreement reported by the supplier. However, balance information may change when sales agreements are cancelled or retrospectively corrected, or during connection and disconnection processes initiated by the supplier. Balance information changes related to cancelling sales agreements and error corrections are described in chapter 3.2.5. If a supplier requests disconnection of an accounting point within agreed time limits but the DSO for some reason cannot disconnect the accounting Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



138 (203)

point, the consumption/production of the accounting point is calculated into the losses of the metering grid area according to the practice agreed among the industry. Because of this, the balance responsibility is transferred to the DSO (supplier's balance information is updated) starting the day after the requested disconnection date in the supplier's disconnection request. Balance responsibility is transferred back to the supplier (new balance information is created) based on the connection time that the DSO has reported.

3.5.2 Virtual production units

Small-scale production per metering grid area and supplier, i.e. production related to an accounting point with a type production, is handled in NBS by creating a virtual production unit. The small-scale production total per metering grid are and supplier is calculated into the production of the virtual production unit. Because of this, there must be a virtual production unit per supplier, metering grid area and NBS production type in the system always, when a supplier has balance information to an accounting point with the accounting point type "production". Virtual production units are handled in datahub in such a manner that adding, removing or updating the validity of virtual production units does not require specific actions from the user.

Virtual production units are handled in NBS model like any other production units. Thus, virtual production units must have identification, name, NBS production type and capacity in the system. Maintaining capacity for example by adding together the powers of production devices is not worthwhile, because this might mean calculating new capacity at worst daily. Because of this, it must be possible to define the capacity with a pre-determined value. The name of the virtual production unit is generated automatically, for example based on identifications of metering grid area and supplier, and the production type. The system creates an identification for the virtual production unit based on the identification system which is in use at the time of creation. The system updates the validity of the relation between virtual production unit and supplier so that the relation is valid exactly when the supplier has at least one balance information to an accounting point at the metering grid area and the production type of the accounting point corresponds the NBS production type of the virtual production unit. The validity in question may consist of one or more time periods.

The production type of the virtual production unit depends on the production devices reported for the accounting point. NBS production types differ from the production types defined for datahub production devices. The relations between the production types are presented in the table below. If the production accounting point has no reported production devices or the production accounting point has several production devices with different production types, the production type of the virtual production unit is "other production". If the production accounting point has one or more production devices of the same type, the NBS production type of the production unit will be determined based on the production devices of the accounting point according to the table below.

TABLE 1 ACCOUNTING POINT PRODUCTION TYPES AND NBS PRODUCTION TYPES




139 (203)

Accounting point production type NBS production type

Hydropower Hydro

Nuclear power Nuclear

Bioenergy Other production

Diesel engine Other production

Other production Other production

Wave power Other production

Solar power Solar

Combined production Thermal

Gas turbine Thermal

Wind power Wind

The table below presents a condensed version of the rules according to which the system generates a new virtual production unit or updates its information.

TABLE 1 DETERMINING THE VIRTUAL PRODUCTION UNIT INFORMATION

Attribute/relation of the virtual production unit Basis for determination

Production unit - Metering time seriesMetering time series of the virtual production unit is the resulting time series "Supplier's small-scale production" in the balance settlement

Capacity Pre-determined value, which is used for all new virtual production units

Name Name generated by the system, such as <supplier_id>_ <metering grid area id>_<NBS production type>

(NBS) Production type Determined by the system based on production types of the accounting point's production devices.

Production unit identification System generates a new identification according to the requirements of data standard

Production unit - Metering grid areaMetering grid area, to which the virtual production unit belongs to. Validity is not updated, instead a new virtual production unit is created if necessary.

Production unit - Supplier

Validity is determined based on the validity of balance information so that the relation is always valid when the supplier has at least one balance information to an accounting point, which is related to a corresponding metering grid area and which has a production type that corresponds the production type of the production unit. The relation may have several time periods, if necessary.




140 (203)

3.5.3 Imbalance settlement calculations and calculated data

Datahub calculates the imbalance settlement time series (imbalance settlement resulting time series) based on structural information and metering data until the closing of the balance window. The figure below presents the general structure of imbalance settlement time series based on NBS model from the datahub point of view. The actual imbalance settlement time series are described later in this chapter (Table 14).

FIGURE 1 DATA RELATED TO BALANCE SETTLEMENT CONNECTION

The imbalance settlement time series are the basis of imbalance settlement performed by eSett. In datahub, the balance settlement type defines the purpose of the imbalance settlement time series in balance settlement. The imbalance settlement method indicates whether the time series data is based on data that is metered or specified in some other manner, in other words, profiled data. All metering data, that is related to an accounting point with a metering method of reading metering or unmetered, is profiled metering data in datahub. In practice, the metering method of an accounting point may change several times, and these changes and their validity must be taken into account in balance settlement calculations. For example, consumption is calculated into supplier's profiled sum delivery only from time periods when the metering method of the accounting point is "reading metering" or "unmetered".




141 (203)

Not all balance settlement method and type combinations are in use. For example the NBS model allows for both metered and profiled (grid) losses, although only metered losses are used in Finland. Profiled balance settlement data is used only for sum deliveries and production units' own consumption in Finland. The metering method of the accounting point defines the balance settlement method the consumption/production of the accounting point is calculated into.

Balance settlement connection is basically Datahub's equivalent to the MEC (Market Entity Connection) defined by eSett [3]. Datahub's balance settlement connection is a construct, that defines balance settlement method and type that are related to imbalance settlement time series, as well as connects time series to market parties and on behalf of production data to (virtual or actual) production units. Datahub will maintain balance settlement connections automatically based on initial data for balance settlement (see figure 3542). Although there can be more than one balance settlement connection in datahub with the same combination of balance settlement type, balance settlement method, supplier, metering grid area and production unit, only one of them can be valid at a time. The balance settlement structural information eSett reports to datahub is mostly based on balance settlement connections.

Imbalance settlement is done per metering grid area and per supplier i.e. there must be a supplier for all production and consumption. All consumption and production that do not have a defined supplier is calculated, according to calculation rules, into the metering grid losses and to the balance of the metering grid area loss supplier. Only metering grid area sum level imbalance settlement time series do not have a related supplier. These time series are not used in imbalance settlement or reported to eSett, they are only used for statistical and analytical purposes.

Of the imbalance settlement time series in datahub, only metering grid area imbalances and MGA exchange confirmations are calculated in eSett's system. Imbalance is a tool for handling situations where, due to various rounding, calculation and information exchange errors, the metering grid area's exchange point sum does not match the sum of metering grid area's productions, suppliers' deliveries' and losses. In these cases the calculated imbalance is recorded as a delivery of the metering grid area imbalance open supplier. Imbalance is calculated as the sum of the calculations 1-7 in the table below, considering the signs. Because the metering grid area losses (calculation 7) is calculated as the sum of calculations 1-6, the calculated imbalance should always be zero under normal circumstances. eSett will report separately MGA imbalance as intermediate report from open balance window and final report from the closed day of the balance window.

According to NBS rules, datahub classifies the supplier and metering grid area specific sum information it reports according to balance settlement type and method. The table below presents the metering grid area-specific sum calculations calculated by datahub, which are used in Finnish imbalance settlement. The data on the red background is reported to eSett for imbalance settlement. The principle in calculating the metering grid area losses is that the losses are calculated based on information that is reported to eSett, not based on




142 (203)

metering grid area sum calculations. The losses are calculated for example based on individual exchange point sums instead of metering grid area total exchange point sum to avoid possible rounding errors. Rounding errors could cause unnecessary imbalance in eSett calculations.

TABLE 1 METERING GRID AREA-SPECIFIC SUM CALCULATIONS CALCULATED BY DATAHUB

# Data to be calculated Description

1 Supplier's metered sum delivery

The supplier's calculated sum, in accordance with the official imbalance settlement period, of metering time series of fifteen minute and hourly-metered consumption accounting points in the metering grid area.

2 Supplier's profiled sum delivery

The supplier's calculated sum, in accordance with the official imbalance settlement period, of metering time series of profiled (reading metered or unmetered) consumption accounting points in the metering grid area.

3Supplier's small-scale production sum (per production type)

The supplier's calculated sum, in accordance with the official imbalance settlement period, of metering time series of small-scale production accounting points in the metering grid area, per production type

4 Supplier's metered own consumption sum

The supplier's calculated sum, in accordance with the official imbalance settlement period, of production unit's own consumption accounting points' metered metering time series in the metering grid area.

5 Supplier's profiled own consumption sum

The supplier's calculated sum, in accordance with the official imbalance settlement period, of production unit's own consumption accounting points' profiled metering time series in the metering grid area.

6 Exchange point sum The exchange point sum between two metering grid areas calculated from exchange point metering.

7 Metering grid area losses

Calculated based on sections 1-6 production unit productions using formulaMetering grid arealosses=Connection point sums−metered∑ deliveries−profiled∑ deliveries−meteredown consumption sums−profiled ownconsumption sums+small scale production sums+ productionunit productions

8 Supplier's total small-scale production sum Sum of supplier's small-scale production sums in section 3.

9 Metered sum delivery of the metering grid area Sum of metering grid area's sum deliveries in section 1.

10 Profiled sum delivery of the metering grid area Sum of metering grid area's sum deliveries in section 2.

11Small-scale production sum of the metering grid area (per production type)

Sum of metering grid area's small-scale production sums in section 3.




143 (203)

# Data to be calculated Description

12Metered own consumption sum of the metering grid area

Sum of metering grid area's own consumption sums in section 4.

13Profiled own consumption sum of the metering grid area

Sum of metering grid area's own consumption sums in section 5.

14Production unit sum of the metering grid area (per production type)

Sum of all production unit meterings in the metering grid area, per production type.

15Total exchange point sum of the metering grid area

Sum of exchange point sums in section 6, which are related to the metering grid area.

16Total small-scale production sum of the metering grid area

Sum of metering grid area's small-scale production sums in section 12.

17Total production unit sum of the metering grid area

Sum of metering grid area's production unit sums in section 15.

The chart below presents a diagram of how the calculations described above are dependent on each other and on individual metering time series.




144 (203)

FIGURE 1 IMBALANCE SETTLEMENT CALCULATION FOR THE METERING GRID AREA

3.5.4 Information exchange in imbalance settlement

In addition to being used in balance settlement calculations, balance settlement structural information and time series information calculated by datahub are exchanged between parties of datahub. Datahub reports daily the updated structural information and the calculated imbalance settlement data to eSett. eSett calculates the imbalances of metering grid areas based on information reported by datahub, and reports the imbalances to datahub. Finally datahub reports the imbalance settlement data it has calculated and the imbalances of metering grid areas to market parties according to their rights. In addition to the above-described daily process (DH-510), the parties can specifically request imbalance settlement data from datahub using DH-50 events.

The diagram below presents the information exchange related to imbalance settlement (datahub events).




145 (203)

KUVA 1 IMBALANCE SETTLEMENT INFORMATION EXCHANGE




146 (203)

3.5.5 Data reported to eSett

This section describes how imbalance settlement data is reported from datahub to eSett using the current interface specifications (available at https://www.ediel.org). Thus, the data exchanges presented below do not apply to DSOs, and Datahub reports this information on behalf of the DSOs. However, the DSO must for its part maintain the data described in section 3.5.1 in Datahub so that this data can be compiled and reported to eSett. Datahub and eSett can also agree on information exchange that is based on interface specifications other than those outlined above.

3.5.5.1 Structural information

Datahub reports structural information to eSett separately before the metering data can be reported. Reporting structural information is mainly based on balance settlement connections described in chapter 3.5.3. Structural information is reported to eSett on a supplier or metering grid area level, only production unit information is reported for individual metering points. Structural information includes information about which supplier operates in a certain MGA. For example, when a new supplier registers with Datahub, this information is reported to eSett. Technically speaking, also the small-scale production sum will be processed as a so-called virtual production unit and it will be separately created for each unique supplier, metering grid area and production type combination.

Datahub will report the following structural information to eSett for the DSO's imbalance settlement:

TABLE 1 DATA REPORTED TO ESETT

Data NBS Information exchange document

Metering grid area data Area Specification Document

Exchange point connections (MGA-MGA relation)

Area Specification Document

Supplier operating in the MGA Party Master Data Document

Production unit data Resource Object Master Data Document

Exchenge point connections refers to information about which two metering grid areas have transmission happening between them, i.e. which two metering grid areas have at least one exchange point. For the supplier operating in the MGA, Datahub includes the following information in its notification to eSett: MGA, consumption type




147 (203)

(BusinessTypeCode), imbalance settlement method (SettlementMethodCode) and validity data. Each balance settlement type/settlement method combination for each supplier must be reported as separate data to eSett in accordance with Table 16.




148 (203)

3.5.5.2 Time series data

Datahub reports the below-mentioned time series to eSett on a supplier- and metering grid area-specific basis:

TABLE 1 IMBALANCE SETTLEMENT DATA COMMUNICATED TO ESETT ON A SUPPLIER- AND METERING GRID AREA-SPECIFIC BASIS

Data NBS Information exchange document

BusinessTypeCode (Balance settement type)

SettlementMethodCode (Settlement method)

Metered sum deliveryAggregated Data per MGA for Settlement Responsible from MDA

Consumption (A04) Non profiled

Profiled sum deliveryAggregated Data per MGA for Settlement Responsible from MDA

Consumption (A04) Profiled

Metered own consumption sum

Aggregated Data per MGA for Settlement Responsible from MDA

Production Units own consumption (B36)

Non profiled

Profiled own consumption sum


Production Units own consumption (B36)

Profiled

MGA losses6 (must be allocated to a single supplier)


Losses (A15) Non profiled

In addition to the above, Datahub reports to eSett the production data for individual production units (PU), supplier-specific small-scale production sums by MGA and exchange point sums between grids. Datahub creates a virtual production unit (PU) for the supplier's MGA small-scale production sum, for which the data is reported. When the metering grid area loss calculation produces negative values, for example due to missing metering data, datahub will report negative values as a part of the production of the metering grid area's loss supplier's virtual production unit with the production type "other production". This is the course of action because eSett does not allow negative values for consumption (or production). The information exchange documents that Datahub can use to report this information to eSett are listed below.

6 including lossesFingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



149 (203)

TABLE 1 NBS INFORMATION EXCHANGE DOCUMENTS USED BY DATAHUB

Data NBS Information exchange document MeteringPointTypeCode

Supplier's small-scale production sum

Validated data for Aggregator from MDR Production

Production unit's production

Validated data for Aggregator from MDR Production

Exchange point sum

Aggregated Data per neighbouring grid Exchange

3.5.6 Supplier's imbalance settlement data

Datahub calculates imbalance settlement time series data for the supplier and the MGA. The diagram below presents the supplier's MGA-specific imbalance settlement data. The new and changed imbalance settlement data for the duration of the balance window and for the latest day locked in the balance settlement is reported to the suppliers on a daily basis. In addition to the notification, the suppliers can also retrieve this data separately from Datahub. In the figure, supplier's small-scale production refers to small-scale production per production type, and total small-scale production sum refers to the sum of all small-scale productions. Not every supplier has all the information. For example, the metering grid area losses are reported only to the supplier, who is the loss supplier of the metering grid area.




150 (203)

FIGURE 1 SUPPLIER'S MGA-SPECIFIC IMBALANCE SETTLEMENT DATA

3.5.7 Distribution system operator's imbalance settlement data

The DSO has the right to both the above-mentioned supplier's imbalance settlement data and the MGA imbalance settlement data. The new and changed imbalance settlement data calculated by Datahub is reported to the DSOs on a daily basis until the first day outside the balance window. In addition to the notification, the DSOs can also retrieve this data separately from Datahub. Small-scale production for metering grid areas is also reported separately both per production type and as sum of all productions.

FIGURE 1 DSO'S MGA-SPECIFIC IMBALANCE SETTLEMENT DATA

After the implementation of datahub, the DSO may not necessarily have information about the accounting point supplier in the current manner. Because of this, in addition to actual balance settlement data, datahub reports to DSO when a sales agreement of an accounting point ends so that the DSO knows to disconnect the accounting point. Datahub also reports separately to DSOs if an accounting point is without a supplier and does not have a reported disconnection. In addition to the previously mentioned, datahub provides an information request event that DSOs can use to get accounting point specific consumptions/productions, which are calculated into the DSO's losses.




151 (203)

3.5.8 Imbalance settlement calculations outside the balance window

Imbalance settlement calculations are primarily calculated in Datahub for the needs of the official imbalance settlement performed by eSett. Imbalance settlement calculations, however, have another use in addition to official imbalance settlement. For example, metering grid area losses are a significant cost to a grid company, and the exact amount of losses is also monitored by grid companies outside the balance window. Datahub will be the primary databank for metering- and imbalance settlement data, so it is natural for all up-to-date and corrected metering data and the results calculated from them to be available from Datahub with regard to all data.

Official imbalance settlement always closes when the balance window closes, after which data calculated in official imbalance settlement and reported to eSett can no longer be changed. Changes in metering data outside the balance window are mainly taken into account in balance deviation calculation. Balance deviations are, however, registered neither to exchange points nor production units, nor to those accounting points at which a metering error arises more than six weeks after the period of a terminated sales agreement. The updating of the results of imbalance settlement calculations in connection with balance deviation calculation is therefore not possible. This concerns not only metering grid area losses but also other imbalance settlement aggregations.

Calculation results corresponding to the official imbalance settlement (all types of results/aggregations) will be calculated for the period outside the balance window once a month for all metering grid areas over the past three years. These results are retrievable using DH-520 data request events. In the request event, the party must state whether it is searching for official data locked in the imbalance settlement or for the results of the correction calculations described above. In addition to monthly calculation, correction calculations may be performed separately for a freely specified period on request.




152 (203)

3.6 DH-600 Management of balance deviationManagement of balance deviation in Datahub is based on the Finnish Energy's instructions "Taseisiin jääneiden virheiden käsittely taseiden sulkeutumisen jälkeen” (Handling of balance deviation after balance window closure) [2]. Balance deviation is based on all processes that alter supplier's balance information or accounting point's metering data outside the balance window. Processes that cause balance deviation are:

DH-211 Metering data report / correcting metering errors outside the balance window7

DH-300 Agreement processes: the so-called retrospective agreement processes described in chapter 3.2.5, which alter the validities of agreements outside the balance window (retrospective agreement starts, endings and cancellations)

DH-412 Notification of supply connection related to supplier's supply connection request, if the connection time is reported outside the balance window

Manual balance information corrections performed by datahub operator at the request of parties

One should notice that after datahub deployment a separate balancing calculation for reading metered sites will not be executed. Updating reading metered site's metering data from data based on estimated yearly consumption to reading metered data, and the need for corrections caused by this, will be handled in the same balance deviation handling process as all other balance corrections.

7 metering data related to accounting points with reading metering (metering type other than "hourly metered") are reported retrospectively, which creates balance deviation.Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



153 (203)

3.6.1 Balance deviation calculation and handling process




154 (203)

FIGURE 1 BALANCE DEVIATION CORRECTION PROCESS

Balance deviation correction functions in datahub according to the diagram above. First, datahub defines supplier's settlement data per accounting point, using the data of the time of calculation. In this case, settlement data includes, in addition to the specifications in chapter 3.2.5., the measured consumption of accounting point from the time period that the supplier has the balance responsibility. Calculation is executed only for accounting points, which, outside the balance window, have new metering data or balance information changes for the calculation period that have not been taken into account in the previous calculation runs.

The accounting point specific time series, which is compiled from the settlement data of the time of calculation, is called "metered data". After this, the calculation result is compared to the accounting point specific so-called settlement data time series, which is based on the locked data reported to imbalance settlement or on previously corrected data. More specifically, the metered data is compared to the corrected data with respect to that time interval, which has been processed in the previous calculation. With respect to that time interval, which has not been processed in the previous calculation, the metered data is compared to that data which was valid at the time of balance window closure. Possible differences in the comparison are recorded as balance deviations and the supplier's correction in euros is created by multiplying the difference with the NordPool Spot Finnish area price. After this, the settlement data of the time of calculation i.e. the so-called metered data, which was defined at the beginning, is saved as the settlement data time series, with Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



155 (203)

which the next calculation result is compared. Because metering data is always handled as positive values in datahub, balance deviation calculation will take signs into account depending on whether the accounting point in question is a production or consumption accounting point.

After the calculations have been executed and the datahub operator has approved the calculation results, datahub creates metering grid area specific correction invoice materials for all suppliers and dispatches these to the DSOs and suppliers according to their rights to data. The materials include for each accounting point the so-called metered data, settlement data time series values, balance deviations, and metering grid area and supplier specific compilations of balance deviations according to descriptions in chapter 4.7. DSOs use the material for supplier specific compensation or correction invoicing for their own metering grid area and the suppliers can use the material for checking the DSO's balance deviation invoicing.

3.6.2 Balance deviations caused by metering data corrections

Balance deviation regarding metering data corrections is corrected only concerning the suppliers, which are responsible for correcting the customer's sales agreement invoicing according to chapter 3.3.4. The balance deviation regarding metering error is corrected concerning the supplier, which has a valid agreement at the time of balance deviation calculation and the moment affected by the metering error. In other words, metering error is not corrected regarding the suppliers, which have in the imbalance settlement been responsible, from their own mistake, for the consumption of an accounting point without actual right (agreement) to charge the customer of the electricity consumed. The DSO must report corrected metering data always for the whole time period affected, not only for the time period for which the supplier corrects the customer's invoice. Therefore it is made sure that the Datahub has always correct and up-to-date information available for customers and 3rd parties.

3.6.3 Balance deviation of metering grid area losses

Balance deviations are related to metering grid area losses, in addition to accounting points. Balance deviations of losses are recorded to metering grid area's loss supplier's balance. Losses are affected both by metering data corrections outside the balance window and by balance information corrections where an accounting point is left without a supplier or a supplier is added to an accounting point without a supplier. The balance deviation time series for losses in metering grid areas is created by adding together all the balance deviations of the metering grid area's accounting points, considering the signs. Settlement data time series for losses is compiled, like for an accounting point, using values locked for imbalance settlement or values updated according to metered data during the previous balance deviation calculation. In balance deviation calculation, the "metered data" of metering grid area losses is calculated conversely by adding together balance deviations of the losses and settlement data time series, and finally thus calculated metered data is saved in the settlement data time series for the next calculation. Balance deviation Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



156 (203)

information from accounting points that have caused the balance deviation of losses is not separately reported to metering grid area's loss supplier. In other words, the loss supplier only gets information about the total deviation of the losses. Balance deviations of the losses are not reported to a supplier whose supply in the metering grid area has ended.

3.6.4 Performance of balance deviation calculations

Balance deviation calculations will be performed only as separate runs started by the datahub operator. In other words, there will not be automated, such as preset, balance deviation calculations. Balance deviations will be corrected retroactively for a period of three years on an accounting point-specific basis twice a year in accordance with the Finnish Energy instructions. Calculation of balance deviations can also be initiated at the specific request of an operator if the balance deviation is large and the operator wants to handle it quickly. All balance settlement and balance deviation data, which have been the basis for correction invoicing, will be saved according to their time of calculation as history data for reviews. Thus, there's always information in datahub about what has been originally reported to imbalance settlement how this data has been corrected in each of the following balance deviation calculation runs.

3.6.5 Balance deviation data

The figure below presents the balance deviation data described in the previous chapter that datahub stores.




157 (203)




158 (203)

FIGURE 1 COLLECTION OF SINGLE BALANCE DEVIATION AND MGA AND SUPPLIER SPECIFIC BALANCE DEVIATION DATA

A noteworthy feature of balance deviation calculations is that an individual balance deviation is always related to two suppliers. The balance deviation in question is always the same magnitude for the two suppliers of the balance deviation, but different signs (positive for one, negative for the other). Thus the combined amount of energy and amount of euros for all balance deviations is always zero for each calculation run. The reason for balance deviation is determined based on the event that caused the balance deviation in the following manner:

Metering data correction: a metering data correction reported by the DSO

Supplier data correction: (balance information correction):

o The balance information of an accounting point has been transferred from one supplier to another (balance information correction)

o Supplier addition: A supplier has been added to an accounting point without a supplier (balance information correction)

o Supplier deletion: An accounting point has been left without a supplier (balance information correction)




159 (203)

As described before, in the cases of metering data correction, supplier addition and supplier deletion, the other party involved in the balance deviation is the metering grid area loss supplier.




160 (203)

[3.7] DH-700710 and DH-720 Maintenance and retrieval of product and invoice row data

3.6.6[3.7.1] Product data

Datahub enables the maintenance and transfer of product data for different needs. In order for suppliers to be able to make an electricity sales agreement with a product that corresponds to the accounting point grid service product, the DSOs must maintain the data for their own transmission products according to the structure below. Suppliers also need grid service product data for electricity delivery agreement invoicing.

Suppliers can maintain sales product data in accordance with their own needs and agreements signed with other market parties. The sales product is not forwarded to the DSO or third parties without separate consentparty authorisation from the supplier.

Product and price information must be reported and it can be retrieved via an automated interface in accordance with DH-700 events. Only the product identification is reported when retrieving accounting point data and in agreement processes, in which case the above-mentioned interface must be used to clarify the product structure. If necessary, several products can be reported for an agreement. The only product data that can be updated is the names of the product and product components, calendar and price. A new product must be created for other updating needs. Datahub data model supports storing product names and product component names in multiple different languages.Grid service product prices are public and thus they must be reported to datahub from where they are available to all parties. Sales product prices in datahub are available only to the parties to whom the supplier has given an authorisation to the data. The customer cannot provide a third party with authorisation for price information. Prices are reported to datahub without value added tax (VAT). There are also products, whose payments are based on different conditions and calculation formulas that have multiple basis for invoicing, not just electricity consumption of a specific hour. Examples of these products can be power based products whose payments are based on one or more highest metered electric power during a time interval. In these cases it may be impossible to report the price information to datahub in a reasonable manner accoring to product structure and thus it is not necessary to report the price information to datahub.




161 (203)




162 (203)

FIGURE 1 PRODUCT DATA CLASS DIAGRAM

In the above structure, the product can be, for example, "Timed transmission", which has two product components: "Day transmission" and "Night transmission". A calendar time series is a time series in which the time steps value can be 0 or 1. When the value is 1, the product component in question is applied for the time step in question. A calendar time series must be compiled separately for each year, because a calendar can vary according to public holidays falling on weekdays that occur at different times each year. The calendar time series must also take changes between daylight savings and standard time into consideration, as well as the extra day in leap years. Calendar time series must be reported by the end of September at the latest. A price-time series indicates the price for each time step.

3.6.7[3.7.2] Create a product

When reporting a new product to datahub the reporting party sends in all the required information about the product structure. After the product is reported the structure of the product cannot be changed. The structural data is reported with one message and in this message the market party reports what kind of price information the product has, whether it is a price or price time series. The reported product that has the price information type BG01=Price, will be completed once the party has submitted the price information for the product with a separate price notification message. The product cannot be used until the price information is provided and no retrospective price notifications to products are allowed. If a product price is time series based then the price time series can be reported retrospectively and the product can be used even though the price information is not submitted immediately after the product is created.

A product can include also a calendar time series. Calendar time series defines the moments in time when a certain product component (such as day-rate or night-rate electricity) is in effect. Calendar time series are reported with the same message that the price time series.

Datahub products are created by combining different product components to form a complete product. Each product has its own instance of a product component even if the same component is used in another product. This allows the reporting market party to inform different prices for the component by products.

Datahub data model supports storing product names and product component names in multiple different languages.

3.6.8 Update product structural data

The market party can update their own valid products. The structural data of product consists of the product and product component data. The product structural data that can be updated by the market party is the product name and product component name. Market party can also set the end date to the product. When setting the end date, the product is ended and no changes can be made to this afterwards. Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



163 (203)

The market parties cannot do any changes to the product structure, e.g. adding a new component or removing existing ones. If this kind of change is needed, it is then done by reporting a new product and setting an end date to the existing one.

3.6.9 Update prices or price time series data

When market parties need to change the prices to the products, they do this with separate messages.

Market party will report only a new price with the start of occurrence in the future and the old price is then automatically ended for the previous day. If for some reason the price would need to be changed retrospectively the market party reports this to Datahub operator who would then do the actual update. Only future prices other than price time series can be changed and it is done by reporting a new value that will then overwrite the existing one. Price time series can be reported retrospectively, because they might be based on a certain index or public stock prices and therefor the prices are formed retrospectively.

Prices reported to datahub are reported both with and without value added tax (VAT). This makes it easier to the party who needs these prices to do the invoicing with accurate prices, and does not need to do any calculation on these. Additional changes back and forward can cause differences in decimals and by that way have effect on end customers invoices.

There are also products, whose payments are based on different conditions and calculation formulas that have multiple basis for invoicing, not just electricity consumption of a specific hour. Examples of these products can be power based products whose payments are based on one or more highest metered electric power during a time interval. In these cases it may be impossible to report the price information to datahub in a reasonable manner according to product structure and thus it is not necessary to report the price information to datahub.

3.6.10 Product data request

Market parties can request the product data and product prices from the Datahub. The products from the DSO’s are reported to every one requesting the data but the Suppliers product are reported only to ones who have been authorized to this data.

The request for product data is divided into two different requests. Other one is for the structural data and the other one for the prices, price – and calendar time series.

The request for structural data is always done by reporting the party who’s product data is requested. The request will include also possibility to request only a specific product. In the request, market party can select whether to request the current or historical data. Historical data can be requested by giving a specific information in the request.

The request for prices and price time series is done by the product owner information and by product or by product component level. The request can be limited by providing the desired period for the Price/Calendar Time Series Data.Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



164 (203)

3.7 DH-730 and DH-740 Maintenance and retrieval of invoice row data

3.7.1 Invoice row data

If desired, market parties can communicate invoice row data via Datahub. Invoice row data can be utilised for example when a party has agreed with the customer that the customer receives only one invoice which contains both electricity sales and transmission. In this case the other party can report all their accounting point related invoicing data to the invoicing party using invoice rows. The Market Party that delivers the invoice row data to datahub needs to ensure that the delivered data is delivered to a right party. In case of combined invoicing the invoicing party reports also the receiving party’s identification and the agreement identification of the receiving party in the invoice row message. These identifications become available in the agreement processes. If for example the DSO reports the invoice row data to supplier, the DSO must be able to form the invoice rows to a correct receiver, especially taking into account the supplier change situations.

In the example above Suppliers B’s agreement begins on 1.5.2019. The grid agreement does not change in the supplier change situation. If the DSO has agreed on the combined invoicing with both of the suppliers, it needs to ensure that it does not send invoice rows to Supplier A concerning the period after 1.5.2019.

Invoice row data can also be used for forwarding invoicing data to a service provider who offers invoicing services. In these situations there is no receiving agreement identification to report. Before delivering invoice row data, parties need to agree on the delivery of data with each other and set up the party authorisation in the party user interface (the way that this is given is to be clarified as the project proceeds).. In the party user interface the authorising party select the party to be authorised for this and gives the validity period for the authorisation. The given authorisation is to all invoice rows delivered to the authorised party. The receiving of the invoice rows can be delegated to a service provider if needed. If the DSO authorises the Supplier A to its invoice rows then the Supplier A can use a delegation so that a Third party C towill receive the invoice rows on its behalf. This makes it possible to e.g. report corrections for a different period than the actual period of the invoice. The customer cannot provide a third party with authorisation to invoice row data.

A party reports invoice row data to Datahub after they have been compiled in the party’s own system according to their own invoicing process. Invoice row data is reported




165 (203)

separately for each product component. For example for an electricity product basic fee component and energy component are reported as separate rows. The invoicing period of the whole invoice and the invoicing period of a separate invoice row are both reported in the message. Invoice rows can also be used to communicate service fee invoicing between parties as separate invoice rows. The amount to be invoiced for a power based product component can also be communicated using invoice row data. This way the party who receives the invoice rows and handles the invoicing of customers does not necessarily have to maintain the calculation rules affecting the invoicing.

The reporting of the invoice rows to datahub is never cancelled or altered. If the sending party does corrections to their own invoicing, the party is obliged to report this in separate debit and correction rows to the receiving party.

Invoice row information is reported according to the structure below.

FIGURE 1 INVOICE ROW DATA CLASS DIAGRAM

3.7.2[3.7.3] Invoice row request

The Market parties retrieve the invoice rows in a same manner than all other messages. The detailed description of this process is described in the Datahub External Interface Specification. Separate request for invoice rows is not needed in normal messaging.




166 (203)

Separate request for invoice rows is meant for viewing individual invoice rows. (The request for invoice rows is to be implemented in the next stage.) By this request Market Parties can request the invoice rows of an individual accounting point or specify the request in more detail with the agreement whenever they need to find out what information has been delivered between parties through datahub.

The invoice rows described above can be retrieved on the basis of time interval. In this case, the search retrieves all the invoice rows for which the time interval intersects with the time interval reported in the request. For example, a request for the interval 1.1.2019-31.3.2019 could retrieve invoice rows for the time period of 15.12.2018–14.2.2019 and 15.2.2019–14.4.2019. The request can be delimited with accounting point, or with the agreement identification of the agreement to be invoiced. In general, Datahub must enable communication of invoice row data in accordance with the valid Decree on Invoices. Datahub invoice rows also support the forwarding of identification information according to the future Finvoice 3.0 standard.




167 (203)

3.8 DH-800 Authorisations and delegationsThe rights of Datahub parties are managed by agreements and by means of authorisations. There are two types of authorisations:

1. Authorisations granted by the customer, in which the customer provides consent to personal information and electricity consumption data. The principle of these authorisations is described under the number 1 in the figure below.

2. Delegations and party authorisations that Datahub parties grant to each other, by which the parties give other parties rights to data that they own or the right to handle a task in accordance with a certain role. The principle of these delegations and party authorisations is described in the figure below under the numbers 2 (delegations and party auhtorisations granted by the supplier) and 3 (delegations and party authorisations granted by the DSO).

FIGURE 1 AUTHORISATIONS AND DELEGATIONS REPORTED TO DATAHUB




168 (203)

3.8.1 Authorisations granted by the customer

The customer authorises a Datahub party to use its own information for a specific purpose. The following table presents examples of the most common purposes for authorisations.

TABLE 1 PURPOSES OF AUTHORISATIONS

Purpose of authorisation

Authorised Datahub party

Validity of authorisation

Rights provided by the authorisation

Rights to metering data

1a

Authorisation type: Invitation to tenderThe customer authorises the supplier to view its information so that the supplier can provide a better offer in a competitive bidding situation. Customer has an agreement to the accounting point

New supplier, potential supplier

2 working days from the time the supplier reports receiving the authorisation.

Customer information, accounting point data and metering data retrieval.

1 year maximum or the validity period of the customer’s agreement if the agreement has been valid for less than one year.

1b

Authorisation type: Invitation to tenderThe customer authorises the supplier to view its information so that the supplier can provide a better offer in a competitive bidding situation. Customer does not have an agreement to the accounting point

New supplier, potential supplier

2 working days from the time the supplier reports receiving the authorisation.

Customer information, accounting point basic information and agreement situation of the accounting point.

No access to metering data

1c

Authorisation type: Competitive biddingThe customer agrees with a consultant concerning competitive bidding and authorises the consultant to view the customer information and accounting point data.

Third party

For the duration of the competitive bidding process, max 30 days.


3 years maximum or the validity period of the customer’s agreement if the agreement has been valid for less than 3 years.




169 (203)

Purpose of authorisation

Authorised Datahub party

Validity of authorisation

Rights provided by the authorisation

Rights to metering data

1d

Authorisation type: Competitive biddingThe customer agrees with a consultant concerning competitive bidding and authorises the consultant to view the customer information and accounting point data.Customern does not have an agreement to the accounting point.

Third party

For the duration of the competitive bidding process, max 30 days.

Customer information, accounting point basic information and agreement situation of the accounting point.

No access to metering data

1e

Authorisation type: Energy reportingThe customer authorises a consultant to handle all its matters related to electricity use.

Third party Max. 2 years


6 years maximum or the validity period of the customer’s agreement if the agreement has been valid for less than 6 years.

Authorisations granted by the customer are always specific to an accounting point and they must be given a period of validity that is a maximum of two years. The validity must correspond to the purpose. For example, purposes 1b and 1c in the table entitle the euthorised party to the same information but the validity periods of the authorisations differ because the purposes are different. Authorizations also give the right to metering data for different periods depending on the type of authorization, if the customer has an agreement for the accounting point. If a customer has authorized a new supplier with an authorisation reason Invitation to tender for example, the supplier will be entitled to the data for two days, but the metering data will be received retrospectively for one years period. Even in situations when customer has granted an authorisation to an accounting point that he is moving into the authorisation is saved in customer and accounting point level. Then the customer can see that the authorisation has been saved concerning the exact accounting point. In this case, the customer cannot authorize the metering data because he has not previously been the customer of the accounting point and therefore does not own the metering data until the date of the move in. If a customer moves out from an accounting point, for which there are authorisations from the customer, these authorisations are automatically ended in Datahub when the customer moves out. The customer’s Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



170 (203)

authorisations are automatically ended also in situations when customer is updated as information restricted.

The customer grants authorisation to an authorised supplier, DSO or third party, after which the party can retrieve the specified information from Datahub. . According to the Electricity Market Act and the current data protection regulation, the authorization from a consumer customer must be made directly to datahub by himself. Therefore, the consumer customer will always authorize himself through a strong identification on the customer portal provided by datahub. The customer portal is described in section 3.11. The parties may report a company customer's authorization on behalf of the customer with the authorization notification event. Use of authorisations will be monitored by means of measures to be planned later in the project.

Same customer, party, accounting point and authorisation type can not repeat in datahub. Authorisation notifications that have that same combination of information than the existing authorisation overwrites the corresponding existing authorisation. This way the end date can be updated when needed, e.g. if the authorisation needs to be ended earlier.

If the customer has had multiple agreements to the accounting point in a way that there has been agreements for another customers in between, then the authorisation gives access to the information of latest agreement.

Both consumer and company customers will be given the opportunity to manage (add, update and remove) the authorisations in Datahub customer portal as described in section 3.12.

3.8.2 Delegations and party authorisations granted by the parties

Authorizations between the parties have two different purposes. The party giving the party authorisation shall permit the other party to obtain the kind of information, that they would not be able to obtain without the party authorisation e.g. invoice rows. The delegation on the other hand will give the other party the rights to act on behalf of another party in Datahub.

3.8.2.1 Party authorisations

The party authorisations are required for the receipt of invoice rows and the supplier’s product information. The party authorisation is given in the parties user interface by selecting the party and the function that is authorized. The party authorisation may be granted to several parties at the same time.

TABLE 1 PARTY AUTHORISATION NEEDS




171 (203)

# Purpose of party authorisationAuthorised Datahub party

Validity of party authorisation

Rights provided by the party authorisation

2aThird party or DSO handles the customer invoicing on behalf of the supplier.

Third party/ DSO

A period specified by the supplier sending the invoice rows.

Receiving the invoice rows

2bThird party or DSO needs the suppliers product information e.g. for invoicing the customer

Third party/ DSO

A period specified by the supplier

Retreiving the supplier’s product information

3aThird party or supplier handles the customer invoicing on behalf of the DSO.

Third party/ supplier

A period specified by the DSO sending the invoice rows.

Receiving the invoice rows

3b The DSO authorises a supplier to retrieve exchange point metering. Supplier

A period specified by the DSO.

Retrieval of exchange point metering data

The party authorisation does not prevent the party from being delegated with the same information. For example, the DSO may authorize the supplier to receive the invoice rows provided by the DSO. The supplier may, if needed, have a service provider delegated to this information and then the service provider will receive the invoice rows on behalf of the supplier.

3.8.2.2 Delegations between parties

The delegation between parties mean that the delegating party gives another party the rights to act on behalf of itself in datahub. Normally the receiver of the delegation is a service provider that would not otherwise have the right to act in Datahub.

Delegations that the parties grant to each other allow the service providers of suppliers and DSOs to have a direct connection with Datahub. These service providers must have an agreement with Datahub, after which they receive user rights to the Datahub system interfaces.

The following table presents examples of the most common purposes for delegations between parties.

TABLE 1 DELEGATION NEEDS BETWEEN PARTIES




172 (203)

Purpose of delegation Authorised Datahub party

Validity of delegation

Rights provided by the delegation

2cA separate invoicing service provider handles the supplier's invoicing.

Third party A period specified by the supplier.

Customer information, metering data, agreement information and product data retrieval.

3cA metering data collector for the DSO delivers metering data directly to Datahub.

Third party A period specified by the DSO.

Delivery and retrieval of metering data.

3dA service provider handles management of the DSO’s balance errors.

Third partyA period specified by the DSOgrid owner.

Retrieval of invoicing information for balance errors.

3eA separate invoicing service provider handles the DSO’s invoicing.

Third party A period specified by the DSO.

Customer information, metering data, agreement information and product data retrieval.

Delegations between parties can be granted on a data set-specific and/or event-specific basis. If a supplier or distribution grid owner has outsourced a function to a service provider, it uses delegation to inform Datahub which party is entitled to which information (for example, customer information and accounting point data and their retrieval) and to initiate which event (for example, metering data delivery). The authorised party receives rights to Datahub information and processes (such as metering data delivery) according to the details of the delegation. The market parties use the Datahub interface to manage delegations. Datahub sends a notification via email to the party who has received a delegation from another party.

If a party has given a delegation to another party to perform an information request type of event on its behalf, both the party who has given the delegation and the party who has received the delegation can perform the information request as if they were the party who gave the delegation. If an event that changes the information stored in datahub (for example update, addition or removal) has been delegated to another party, the updated information is forwarded to the party who gave the delegation. The party who gave the delegation can block forwarding of this updated information.

The parties can authorise any Datahub party with which it has an agreement for handling some task. Thus, a delegation can be granted to another supplier, DSO or a third party, in which case each party can function in several different roles with regard to Datahub. Delegations between parties cannot be transferred forward to a third party. An authorised party can no longer delegate a new party for the information or function the original party has been authorised for. Also an authorisation to customer information received from




173 (203)

customer cannot be delegated to another party. Events related to party information (DH-9XX) and update requests to customer or accounting point data (DH-112, DH-113 ja DH-124) cannot be delegated to another party.




174 (203)

3.9 DH-900 Maintaining party informationDatahub notifies all Datahub parties of the registration of new parties, termination of parties and updating of parties' information. Party information is maintained via in the Datahub for the needs of both market parties and the Datahub operator. The market parties need each other's contact information and billing information. Datahub interface. In conjunction with the operator needs information about the market parties for the service agreements. As part of the service agreement process, the operator will maintain the required information of the market party.

Although information is submitted from one party to another through the Datahub, there may occur situations when direct contact between the parties is required. For these purposes, the market parties maintain their contact information in Datahub regarding agreements, billing, metering data, balance deviations, and debt collection. These contact types will be provided with a contact person, their phone number or email address.

Market parties maintain information of their invoicing addresses in Datahub. These invoicing addresses in party information are for other market parties or Datahub operator where they may send their bills. Datahub maintains invoicing addresses for different types, such as balance deviation costs, combined billing, and connection and disconnection costs. Paper invoice and an electronic invoice invoicing channels are maintained for market parties.

New market parties are always created in the Datahub by the operator. However, the market parties may then maintain their own information in the party user interface provided by the Datahub. Datahub will notify all market parties of new party registration, termination and party information updates. Party information is maintained through the party user interface. The DSO shall also receive, upon notification, the DSO also receives the necessary information for the sending the balance errordeviation invoices.




175 (203)

The party information can be requested by the request event either with the GLN-number of the requested party when requesting a one specific organisation or with the market role when requesting multiple parties. The party information can also be searched in the party user interface.

Information about the parties is maintained in accordance with the class diagram below. .




176 (203)

FIGURE 1 PARTY INFORMATION STORED IN DATAHUB




177 (203)

3.10 Structural changes to metering grid areaThis chapter describes situations in which individual metering points are transferred from one metering grid area to another, or in which the control of a metering grid area is completely transferred from one distribution system operator (DSO) to another. The descriptions have primarily been made from the perspective of Datahub. This chapter does not deal with situations concerning normal market processes, in which new metering points are added to an existing metering grid area, or metering points are removed from it.

In connection with structural changes to metering grid areas, there is a need to exchange information between market parties about the changes. With regard to the structural changes described in this chapter, it is, however, a question of comparatively rare processes, and these changes also often concern a very large number of accounting points (possibly up to hundreds of thousands). For the above-mentioned reasons, at this stage the precise method of implementing the changes and information exchange related to them has not yet been specified in Datahub. The processes described below are not necessarily carried out through market messages but another method of it is done by using a separate data transfer may file. Market parties form the csv-transfer file of the accounting points to be used, such as MS Excel tables. The exact method of implementation will be specifiedtransferred with the selected Datahub system supplier based onhelp of datahub operator. This transfer file is used by the datahub-operator and the DSO’s involved to process descriptions in this chapter. The processes will, however, be carried out so that the changes can be made in a controlled way, and so that they do not disturb the operations of other parties using Datahub in any way.needed actions.

It is noteworthy that, when transferring accounting points to the control of another DSO, without exception DSOs must always carry out a separate data conversion outside the Datahub amongst themselves, in which data is transferred from the present grid owner to the new one. With regard to the change, it is all in all important for the new DSO to be able to ensure the correspondence between Datahub’s data and that of its own data system in connection with the change.

Some of the changes described in this chapter also affect eSett systems. For this reason, the change must also be agreed in advance with eSett before it is carried out. Generally speaking, structural changes to metering grid areas must be agreed with the Datahub organisation well in advance to ensure that the controlled introduction of the change can be carried out.

The processes also entail the transfer of grid agreements to another grid owner. In these changes, grid owners must take into account that the changes will be made in accordance with grid service terms.

These kind of structural changes affect also the suppliers for these accounting points so precise communication is very important.




178 (203)

3.10.1 Transferring control of a metering grid area

This chapter deals with situations in which the control of a metering grid area is completely transferred to a new grid company (which can be one of the existing DSOs). In Datahub data model, this concerns the relation between the metering grid area and DSO (see figure below).

FIGURE 1 TRANSFERRING THE CONTROL OF THE WHOLE MGA

The transfer of control of a metering grid area to another grid company does not in itself affect any other structure in the metering grid area. For example, accounting points belonging to the metering grid area are transferred to the control of the new grid company as they are. Information about which grid owner now controls the metering grid area will be stored in Datahub.

When the control of the metering grid area is transferred from one DSO to another, the following actions must be taken:

The termination of control of the metering grid area for the present DSO and the start of control for the new DSO from a certain point in time.

The transfer of grid agreements from the present DSO to the new DSO. The grid agreements are transferred from the present DSO to the new one as they are This can be done in two different ways:




179 (203)

o The grid agreements are transferred from the present DSO to the new one as they are (primary method)

o the agreements of the present DSO are terminated and the new DSO’s agreement starts from the following day

Balance deviation calculation for the metering grid area with regard to the present DSO.

Actions concerning the transfer of metering grid areas from one party to another are always started by the Datahub operator. In the interface provided by Datahub, the DSO does not have the right to directly control which metering grid areas are under the control of the DSO in question. The transfer of grid agreements to a new DSOWhen the operator initiates the transfer of control of a metering grid area, it specifies whether all the agreements of the previous DSO will be terminated or not, based on instructions from the DSOs. Next these two cases will be explained separately.

[3.10.1.1] The transfer of grid agreements to a new DSO

GRID AGREEMENTS ARE TRANSFERRED TO THE NEW GRID COMPANY AS THEY ARE

When the operator begins the transfer of a metering grid area, the valid accounting point, agreement and customer information productinformation for all the accounting points in the metering grid area is reported to the new grid owner for confirmation (so called confirmation request). The new DSO must confirm the transfer of . This is done by forming a report from Datahub that includes all the accounting points to its own metering grid area based on involved in this information. The new DSO must also be able to use information received from Datahub to checkchange. The report has the correspondence information of the information in its own system with agreement identifications and products. The new DSO updates its own changed agreement and product information to the information in Datahub.same file. Agreement information is also reported to the new DSO with regard to grid agreements that will enter into force in the future.

The new DSO must confirm theDatahub operator uses the same updated file to perform the actual transfer of the accounting point and its grid agreement by reporting to Datahub data corresponding to a DH-312 event for each accounting point. In connection with the confirmed data, the new DSO must report its own products (own product IDs, even if the product remains practically the same), which are applied in each agreement and accounting point. The points.

The new DSO must ensure that, if necessary, it has reported its new product data in a separate product data update notification before confirmation of the agreements. If necessary, in conjunction with the confirmation, the new DSO can alsothe actual update. If the new DSO needs to update other grid agreement informationdetails, such as the invoicing method in the agreement and the agreement ID. In accordance with the data confirmed by the DSO, new grid agreement information is transmitted, this needs to the accounting point supplier for each accounting point.be done with the agreement update event after the transfer by the Datahub Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



180 (203)

operator is done. Along with the transfer of grid agreements, rights to the invoice row data of corresponding grid agreements are similarly transferred to the new DSO. The transfer of a grid agreement to another grid company does not automatically cancel grid agreement data updates (such as update of invoicing address) made by DH-322 notification that will enter into force in the future, with the exception of product switches The exchange points are transferred manually from one metering grid area to another after the transfer of the accounting points is done.

THE TERMINATION OF VALID GRID AGREEMENTS

In situations where valid grid agreements are terminated in connection with the transfer of control of a metering grid area, procedures are almost the same as in the above-mentioned situation. A difference to the above-mentioned process is that, in data delivered by Datahub to a new DSO for confirmation, the start date of the agreement corresponds to the date of transfer of the metering grid area. Datahub also terminates the existing grid agreements. If some accounting points in the metering grid area being transferred have grid agreements of the present grid owner that will start in future or updates to grid agreement information that will enter into force in future, they are automatically cancelled.

[3.10.1.2] The transfer of rights to the new DSO

When transferring control of a metering grid area to another DSO, the new DSO receives the right to all metering grid area's exchange point-, production unit-, accounting point- and their grid agreement data affected by the transfer. The new DSO also has the right to all this data’s change history, which is registered in Datahub. The new DSO thus also has the right to this change information from an event period when it itself was not responsible for the control of the metering grid area in question. The right of the present DSO to the data is restrictedended up to the day when control of the metering grid area is transferred to another grid company.

The transfer of control of the metering grid area must also be taken into account with regard to information exchange for market processes. Generally speaking, Market process-related information exchange is done with the new DSO for all metering grid area data from the time when ownership of the metering grid area is transferred to the new DSO. After the change, if necessary the present DSO is given data only insofar as the data concerns the time when the present DSO had control of the metering grid area. This concerns, for example, calculated imbalance settlement data or invoice rows reported by the supplier for a previous period.

3.10.1.1[3.10.1.3] Rights to accounting point data

In accordance with the data model, accounting points are not directly connected to the DSO. The right to accounting points and their data always comes through the metering grid area. A change in the ownership of a metering grid area thus also transfers data ownership with regard to accounting points. The new DSO of a metering grid area mustwill have the right to accounting point data throughout the history of the accounting point.Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



181 (203)

3.10.1.2[3.10.1.4] Imbalance settlement

The transfer of control of a metering grid area to another party does not directly affect imbalance settlement calculations, as the metering points are not transferred from one metering grid area to another. A situation in which the metering points are transferred from one metering grid area to another is described separately in chapter 3.11.2. With regard to imbalance settlement, information about a metering grid area’s DSO primarily affects what data the party has a right to in Datahub. To this extent, the data also affects what data in Datahub events is transmitted to each DSO. The present DSO has a right to imbalance settlement data (at the message interface or a user interface provided by Datahub) only up to the day when the metering grid area is transferred to the new DSO. The new DSO has a right to all the historical data of the imbalance settlement. This also concerns data on which supplier has at one time or another been the loss supplier of a metering grid area or the imbalance open supplier. When transferring control to a new DSO, Datahub will ensure that the imbalance settlement data is reported to both the new and present grid owners in accordance with their rights.

Changing the party responsible for the metering grid area must also be agreed in advance with eSett.

3.10.1.3[3.10.1.5] Calculating balance deviations

The calculation of balance deviations must take into account a change in DSO controlling a metering grid area. This is because balance deviation invoicing is the responsibility of the DSO and has a direct impact on the finances of the grid company. It must be possible to perform the balance deviation calculations for the previous DSO of a metering grid area until the day when responsibility for the metering grid area is transferred to the new party. It must be possible to do this separately from a general calculation performed for the whole market. Because of this, it is ensured that the present DSO will not need to wait months for the processing of balance deviations, for example in cases where the business of the present DSO terminates completely with regard to the company in question. After the transfer of the metering grid area and its separate related balance deviation calculation, the new DSO is responsible for all new balance deviations throughout the history of the metering grid area. Because of this, from Datahub’s perspective balance deviations concerning the period of control of the previous grid company, which are not noticed and registered until after the transfer, are always recorded to the new DSO. The grid companies may naturally, however, separately agree amongst themselves on which of the companies is financially responsible for these deviations that are retrospectively identified.

3.10.1.4[3.10.1.6] Process diagram for transferring control of a metering grid area

The diagram below describes the phases of transferring the control of a metering grid area to another DSO in Datahub.




182 (203)

FIGURE 1 PROCESS DIAGRAM FOR TRANSFERRING MGA CONTROL

3.10.2 Division and merging of metering grid areas

This chapter deals with situations in which control of a metering grid area remains with the same grid owner, but one or more metering points (accounting points, exchange points or




183 (203)

production units) are transferred to another metering grid area. The matters described in this chapter also apply to a situation in which a metering grid area is divided, and the division creates a completely new metering grid area to which metering points are transferred. The metering points may be transferred either to another metering grid area of the same grid company or to a metering grid area under the control of a completely different grid company. In Datahub data model, these changes concern the relation between the metering grid area and the metering points (see figure below). Information about which metering grid area the metering point has belonged to at any given time will be stored in Datahub.

FIGURE 1 TRANSFERRING METERING POINTS TO ANOTHER MGA

Insofar as the control of certain accounting points and their grid agreements is transferred to another grid company, the same principles are observed for rights and information exchange as described about them in the previous chapter.

Next, we will review necessary actions separately for each type of metering point.

3.10.2.1 Accounting points

The transfer of accounting points to another metering grid area must always be agreed well in advance at least a month before the actual transfer date with Datahub personnel. If the accounting points are transferred to the metering grid area of another grid owner, procedures are the same as in a situation where all accounting points in a metering grid area are transferred to the metering grid area of another DSO (see chapter ). The new DSO




184 (203)

must therefore confirm the transfer of accounting points. Based on this confirmation,). Datahub operator implements the transfer of the accounting points and grid agreements to the new metering grid area, and transmits with the transfer file as described in the data confirmed by the new DSO to market parties entitled to it.

Ifearlier chapterIf an accounting point is transferred from one metering grid area to another belonging to the same grid owner, information about the transfer of the accounting point is reported to all parties entitled to data about that accounting point.the transfer is done by using the same principles described earlier.

3.10.2.2 Exchange points

In Datahub, exchange points are always between two defined metering grid areas. In Datahub it is not possible separately to change either metering grid area to which the exchange point is connected. In practice, when part of a metering grid area is transferred to another metering grid area, new exchange points must be created in Datahub between the two metering grid areas related to the case. In such situations, there is basically no need to terminate the existing exchange points. If, however, two metering grid areas are merged, in practice the exchange points between these two metering grid areas must be terminated. Control of exchange points is the direct responsibility of DSOs, and DSOs may perform necessary actions to that extent in the user interface provided by Datahub.

3.10.2.3 Production units

A DSO may create new production units in the user interface provided by Datahub. The processing of production units, however, differs from exchange points so that it is not possible to apply the termination and creation of a production unit in metering grid area changes. With regard to production units, an existing production plant should otherwise have more GSRN codes, and metering data should be divided into several metering time series for the production plant in question. The transfer of a production unit to another metering grid area is always done by the Datahub operator. This action also requires changes in the eSett system and the Datahub operator agrees on the execution of these changes with eSett.

3.10.2.4 Imbalance settlement

The transfer of metering points from one metering grid area to another affects imbalance settlement calculations. Metering grid area changes do not, however, require separate manual actions in connection with imbalance settlement calculations. Imbalance settlement calculations are specified so that calculation automatically takes into account which metering grid area each metering point is connected to at a given time. Changes in metering grid areas are visible in imbalance settlement calculation results, such as changes in the losses of metering grid areas. In connection with metering grid area changes, it is always advisable to monitor calculation results more closely, as possible errors in processing




185 (203)

changes can significantly affect these results. This is also a good way of noticing possible errors.

3.10.2.5 Calculating balance deviations

Balance deviation calculation must take into account the transfer of an accounting point to another metering grid area in the same way as when changing the DSO in control of a metering grid area (see chapter 3.10.1.5). It must be possible to perform balance deviation calculations until the day when the accounting points are transferred to the new party. If necessary, it must be possible to do this separately from a general calculation performed for the whole market.

3.10.2.6 Division and merging of MGAs under one DSOs administration

The diagram below describes the phases for handling division and merging of MGAs in Datahub, when MGAs are in controlled by the same DSO.




186 (203)

FIGURE 1 PROCESS DIAGRAM FOR MGA MERGE OR DIVISION WHEN MGAS BELONG TO THE SAME DSO




187 (203)

3.10.2.7 Division and merging of MGAs with different DSOs

The diagram below describes the phases in Datahub for handling merging of MGAs with two different DSOs, or dividing a MGA into two, when one of the two is transferred to another DSO.

FIGURE 1 PROCESS DIAGRAM FOR MGA MERGE OR DIVISION WHEN MGAS HAVE DIFFERENT DSOS

3.10.3 Complex changes and reporting

It is very possible that operationally a change may entail both the division and merging of metering grid areas in accordance with chapter 3.11.2 and the transfer of a whole metering grid area to another party in accordance with chapter 3.11.1 A situation may therefore occur where, for example, a metering grid area is both divided and the existing grid owner




188 (203)

completely winds up its operations, and one half of the grid is transferred to a third grid company. In such situations, it is possible to apply the above-mentioned principles and actions separately in two or more stages, so that the more complex changes can be processed. This concerns, for example, situations in which more than two metering grid areas are merged with each other.

Large-scale changes to metering grid areas must also be reported outside Datahub through different channels. Of these channels, the most significant is naturally the Ediel.fi service through which different matters concerning the whole market are generally reported.

One of the most important thing in this kind of large scale processes is the communication between all parties involved in this change. The process touches many market parties and so they all need to be aware of this kind of change in good time before the actual change date.

These changes include also many manual tasks for both the DSO’s involved and the Datahub operator. Manual tasks are done before and after processing the transfer file. A detailed run-book of these is to be done that includes the tasks by parties involved. The detailed description of this process flow will also updated then accordingly. The change needs to be planned well ahead so that all parties are able to do their part in the transfer. And the change needs to be planned also so that it does not cause any extra disturbance for the other market parties. And in order to avoid any changes to the accounting points in the transfer file the actual change needs to be processed during weekends.

Insofar as updates require changes in the eSett system, Datahub must ensure the agreement and execution of the necessary changes with eSett on behalf of the DSOs. Naturally DSOs are involved in the discussion insofar as their participation in the process is required.




189 (203)

3.11 Customer access to own informationDatahub will offer a user interface for the customers, a so-called customer portal, from where the customers can see information about themselves that registered to datahub. In the customer portal, the customer can see the metering data of their accounting points, agreement information and other data. The customer sees all of their own information regardless of which DSO's area their accounting points are or who the supplier is. In addition, the customer can check to which companies, for which data and for which time period they have given an authorisation. The customer can edit the authorisation information if they want to. If customer has added new authorisations or ended the existing ones Datahub will inform about these changes to parties involved. Via customer portal, the customer can remove marking “Information restriction” from his information. The restriction of customer information is described in chapter 3.1.2.

A new national suomi.fi service aimed at all citizens has been introduced in Finland during year 2017. Customer's access to datahub customer portal is arranged through this service. From suomi.fi service the citizens can get a centralised view to data about themselves registered to different registers and authorise other citizens to act on their behalf. In suomi.fi service also companies can authorise persons to access the company data. A customer can utilise aforementioned authorisations between persons, as well as persons and companies, in the use of datahub customer portal. Population register centre (Väestörekisterikeskus) is responsible for developing suomi.fi service.

The process described below shows how a customer is provided with access to the service provided by Datahub and subsequently to the customer-specific information contained in Datahub.

FIGURE 1 CUSTOMER ACCESS TO THEIR OWN INFORMATION

The customer can access their own information via the following stages:

Customer navigates to suomi.fi service with their internet browser.




190 (203)

The customer is identified by means of strong identification methods (for example TUPAS or mobile certificate).

The customer opens the "My electricity information" view in suomi.fi service, which presents a limited amount of data registered to datahub about the customer and through which the customer can log in to datahub customer portal.

Customer logs in to datahub customer portal without additional identification. When logging in, the customer can choose whether to view their own information or some other customer's information when the customer has an authorisation to someone else's data.

3.12 Report required by the Finnish Energy Efficiency ActAccording to the Finnish Energy Efficiency Act, the electricity retailers' (suppliers) are obliged to deliver once a year, properly and free of charge, a report about their energy consumption to the end user customers connected to the distribution grid. The act obliges the suppliers to present to the customer the customer's actual electricity consumption for the last three years, comparison of the customer's consumption to the consumptions of other corresponding customers and to give information about measures to improve energy efficiency. Datahub will compose user group specific anonymised summary level consumption and small-scale production data that market parties can use in their own customer service for forming comparison data required by the energy efficiency act. More detailed description of this data and the method for transferring data will be defined later in the project. Possible delivery methods are for example the data interface described in chapter 2.5, open data interface maintained by Fingrid or a fixed form report.




191 (203)

3.13 System availabilityAs a general rule, the system is always available 24/7 unless disturbances occur or the system has scheduled service interruptions.

The system environment (facilities, equipment) will be a high-availability (usability) environment, which means that it is designed so that availability with regard to the environment is 99.9%. In other words, interruptions in use caused by the environment will statistically be a maximum of nine hours during a one-year period. The system must also have the readiness to support high availability with regard to information security and ICT.

In terms of the target response times and solution times for disturbances, the operating support service for the system environment is at a level that supports the desired availability level.

These solutions are aimed at creating the best possible conditions to ensure that the Datahub system is available and that it is in use and a possible disturbance situation is not caused by equipment or environment factors.

System use, or the way in which the actual applications are used in Datahub, requires disturbance and user support and an organisation prepared to provide it that handles communication between the user organisations of different parties and service provider organisations. Support ensures that disturbances observed by users or situations related to assisting users are solved within the framework of the response times agreed with the industry. Disturbances are classified according to severity level and a solution time is specified for each level. For example, disturbances can occur in the application interfaces with which the system is used or in the information exchange interfaces between various systems and the Datahub system.

3.13.1 Users associated with system administration

Users associated with system management and disturbance clearance are:

1. The Datahub main users designated by the DSOs and electricity suppliers, who are responsible for transmitting data between the metering and customer information systems of the DSOs and suppliers and the Datahub system or who use the Datahub system directly via an interface or are responsible for its functionality. The companies are responsible for keeping the information about the main user (main users) up to date in the Datahub system.

2. The Datahub main users designated by other service providers, who are responsible for transmitting data between their own systems and the Datahub system or who use the Datahub system directly via an interface or are responsible for its functionality.

3. Main users administering the Fingrid system.Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



192 (203)

3.13.2 System support service model

A disturbance situation in which the support service is needed can occur at any user level. For example, it can be visible to the customer so that a process used to create a new electricity agreement and connect electricity to a new accounting point does not run and thus the new agreement and connection cannot be confirmed.

A disturbance can be caused by:

1. Inoperability or incorrect operation of the Datahub system,

2. Inoperability or incorrect operation of the connections, transmission services or applications used to communicate between Datahub and the Datahub systems of the supplier or DSO,

3. Inoperability or incorrect operation of the system that communicates with the Datahub of the supplier or DSO,

4. A denial-of-service attack from a party that is outside the scope of system use.

For example, a disturbance in the delivery of a single DSO's data and a process disturbance can affect operation of the entire Datahub system and the completion of processes.

The system support service model has three levels:

Level 1: The customer (consumer/company) contacts the supplier/DSO's customer service/support. This also includes the actual portal used to process information in Datahub, questions and guidance related to use.

Level 2: The main users/support persons designated by the supplier/DSO contact Fingrid's Datahub support service if the disturbance cannot be resolved in Level 1 support.

Level 3: Fingrid's Datahub support service contacts the system application support service if the disturbance cannot be resolved in Level 2 support.

3.13.2.1 Reporting disturbances

The Datahub system has a separate system for managing disturbances to which main users can report any disturbances that they observe. The company's main user classifies the severity of the disturbance (1–4). Fingrid's main user can edit the severity information for the disturbance if necessary. Information about such a change goes to the person who reported the disturbance. If necessary, the main users can also use other methods to make contact about the disturbance.

The main users of the companies can only see and follow the progress of disturbance clearance in relation to disturbances reported by their company.Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



193 (203)

Severity classifications for disturbances:

System use is completely prevented or use of a single critical element is completely prevented.

System use is partially prevented and there is no alternative route that allows use or use of a single element is completely prevented.

A system disturbance interferes significantly with use but an alternative route allows use.

A system disturbance interferes slightly with use.

3.13.2.2 On-call support

The system's on-call support must be available at all levels on weekdays from 7 am–7 pm.

Furthermore, disturbance clearance in a critical situation will continue until 10 pm in Level 3 support. After this, disturbance clearance will continue at 7 am on the next weekday. In the worst case scenario, the system would not be available during a long weekend.

On-call support at all three levels (including the support level for market parties) must be available at short notice to assist in disturbance clearance. The response time, or reaction to the problem, must be 0.5–1 hour from the time of detecting and reporting the disturbance. After this, disturbance clearance and its eventual solution continues without interruption with support people from the different levels within the framework of the response times outlined above.

3.13.3 Scheduled service interruptions

Users must be notified of scheduled service interruptions well before the planned interruption, in which case they can be performed each day between midnight–4/6 am.

However, service interruptions cannot be done during the following limited times:

At the turn of the year (23.12–7.1), the beginning and end of the school years (15.8–15.9 and 15–31.5)

At the turn of the month: The last three days and the first three days of each month

On the first weekday of a week

During the daytime 6 am–midnight

The parties associated with Datahub must stop data transmission between their own systems and the Datahub system during service interruptions or buffer the events in their own systems. Fingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



194 (203)




195 (203)

4 Source list

[1] Ministry of Economic Affairs and Emplyment of Finland, ”Työ- ja elinkeinoministeriön asetus sähköntoimitusten selvitykseen liittyvästä tiedonvaihdosta,” (Ministry's decree on infromation exchange regarding electricity delivery settlement) 13.7.2016.

[2] Finnish Energy, ”Taseisiin jääneiden virheiden käsittely taseiden sulkeutumisen jälkeen,” (Handling of balance deviations after gate closure) 27.4.2016.

[3] eSett Oy, ”Nordic Imbalance Settlement Handbook (Instructions and Rules for Market Participants)”. 21.3.2016.




196 (203)

Appendix A Descriptions of imbalance settlement calculations

This appendix describes in more detail how the time series are selected to imbalance settlement calculations. In the descriptions of calculations input refers to data, which is needed to calculate an individual imbalance settlement calculation. Other selection criteria refers to criteria, based on which the time series are selected to be used as a basis for calculations. Fulfillment of these criteria is verified by time-step and only the time-steps from the selected time series for which all the criteria are fulfilled are included in the calculated sum. In calculations, which are based on accounting point data, especially the metering method may change by time-step. In practice the accounting point type cannot change and the metering grid area, in which the accounting point belongs to, changes very rarely.

A.1 Supplier's metered sum deliveryDescription:

Supplier and metering grid area specifically calculated sum, in accordance with the official imbalance settlement period, of the metering time series of continuously metered accounting points.

Input:

Supplier

Metering grid area

Other selection criteria for metering time series:

The supplier in the input has valid balance information to the accounting point at the time-step of calculation

Accounting point belongs to the metering grid area in the input

Accounting point type = Consumption

Accounting point's metering time series type = Active energy

Accounting point metering method = Continuous metering




197 (203)

A.2 Supplier's profiled sum deliveryDescription:

Supplier and metering grid area specifically calculated sum, in accordance with the official imbalance settlement period, of the metering time series of profiled, i.e. not continuously metered, accounting points.

Input:

Supplier

Metering grid area




Accounting point type = Consumption


Accounting point metering method = Reading metering or Unmetered

A.3 Supplier's small-scale productionDescription:

Supplier, metering grid area and (NBS) production type specifically calculated sum, in accordance with the official imbalance settlement period, of accounting points' metering time series of the production type.

Input:

Supplier

Metering grid area

(NBS) production type






198 (203)


Accounting point type = Production



A.4 Supplier's metered own consumption sumDescription:

Supplier and metering grid area specifically calculated sum, in accordance with the official imbalance settlement period, of the metering time series of continuously metered own consumption accounting points.

Input:

Supplier

Metering grid area




Accounting point subtype = Own consumption



A.5 Supplier's profiled own consumption sumDescription:

Supplier and metering grid area specifically calculated sum, in accordance with the official imbalance settlement period, of the metering time series of profiled, i.e. other than continuously metered, own consumption accounting points.

Input:

Supplier

Metering grid areaFingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



199 (203)




Accounting point subtype = Own consumption


Accounting point metering method = Reading metering or Unmetered

A.6 Exchange point sum (MGA Exchange)Description:

Exchange point sum refers to the total electricity transmission between two metering grid areas that is calculated from the metering time series of the exchange points between the two metering grid areas in question. Exchange point sum includes information about which metering grid area is the "In Area" (area where electricity is transmitted to) and which is the "Out Area" (area where electricity is transmitted from).

Exchange point sums are calculated between all two metering grid areas, which have at least one exchange point metering.

Input:

Out Area

In Area

Other selection criteria for metering time series to be added:

Metering point type = Exchange point

A.7 Metering grid area lossesDescription:

Transmission losses of the metering grid area in accordance with the official imbalance settlement period.

Metering grid area losses are calculated based on other calculated sums of the metering grid area using formula:

Metering grid arealosses=Connection point sums−metered∑ deliveries−profiled∑ deliveries−metered own consumption sums− profiled ownconsumption sums+small scale production sums+ productionunit productionsFingrid Datahub OyStreet address Postal address Phone Fax Business Identity Code



200 (203)

A.8 Supplier's total small-scale production sumDescription:

Supplier and metering grid area specifically calculated sum, in accordance with the official imbalance settlement period, of the metering time series of production type accounting points for all production types together.

Input:

Supplier

Metering grid area

Other selection criteria for the time series to be added:

Small-scale production sums of the supplier in the input for the metering grid area in the input

A.9 Metering grid area's metered sum deliveryDescription:

Total sum of metered sum deliveries of the suppliers in the metering grid area.

Input:

Metering grid area

Other selection criteria for times series to be added:

Suppliers' metered sum deliveries for the metering grid area in the input.

A.10 Metering grid area's profiled sum deliveryDescription:

Total sum of profiled sum deliveries of the suppliers in the metering grid area.

Input:

Metering grid area

Other selection criteria for times series to be added:

Suppliers' profiled sum deliveries for the metering grid area in the input.




201 (203)

A.11 Metering grid area's small-scale productionDescription:

Total sum of metering grid area's suppliers' small-scale production sums per production type.

Information to be calculated:

Total sum of metering grid area's suppliers' small-scale production sums

Input:

Metering grid area

(NBS) Production type


Suppliers' (production type specific) small-scale productions for the metering grid area and production type in the input.

A.12 Metering grid area's metered own consumption sumDescription:

Total sum of the metering grid area's suppliers' metered own consumption sums.

Input:

Metering grid area


Suppliers' metered own consumption sums for the metering grid area in the input.

A.13 Metering grid area's profiled own consumption sumDescription:

Total sum of the metering grid area's suppliers' profiled own consumption sums.

Input:

Metering grid area





202 (203)

Suppliers' profiled own consumption sums for the metering grid area in the input.

A.14 Metering grid area's production unit sumDescription:

Total production of metering grid area's production units per production type.

Input:

Metering grid area

(NBS) Production type


Production units' time series with the input production type for the metering grid area in the input

A.15 Metering grid area's total exchange point sumDescription:

Metering grid area's total exchange point sum is the remainder of electric energy input to the grid and output from the grid. Total exchange point sum is calculated by adding together, including sign, all exchange point sums where the metering grid area in question is either the In Area or Out Area.

Input:

Metering grid area


Exchange point sums, where the input metering grid area is either "In Area" or "Out Area".

A.16 Metering grid area's total small-scale production sumDescription:

Total production of metering grid area's small-scale productions together.

Input:

Metering grid area




203 (203)


Input metering grid area's (production type specific) small-scale production sums

A.17 Metering grid area's total production unit sumDescription:

Total production of metering grid area's production units together.

Input:

Metering grid area


Input metering grid area's (production type specific) production unit sums



Documents

Electricity retail market business processes in Datahub · Web viewA GLN code is a 13-character code, which comprises a GS1 company ID, freely selectable numbers (3-5 of them) and