Datahub events

Transcription

1

2 2 (214) Table of Contents Change log... 8 Definitions and abbreviations Introduction General General interface specifications Namespace Versions Message version Message sub-version schemasite Message structure Header Process Payload General elements Administrators of IDs and code lists Parties and metering grid areas Accounting point s Timestamps and time periods Value units Message IDs Message validations XML schema... 24

3 3 (214) Process validations Event validations Acknowledgement processing Enquiry events Message list Cancellation messages and events Event forwarding Request event Event synchronicity/asynchronicity Asynchronous data retrievals Messaging encryption and packing DH-100 Customer and accounting point data maintenance processes DH-111 Customer information update supplier DH-112 Customer information update request - DSO DH-113 Customer information update request - 3rd party DH-121 New accounting point DH-122 Accounting point data update DH-123 Accounting point deletion DH-124 Accounting point data update request DH-131 Accounting point request DH-132 Accounting point and customer information request current supplier DH-133 Accounting point and customer information request new supplier DH-134 Accounting point and customer information request DSO DH-135 Accounting point and customer information request 3rd party DH-200 Metering data maintenance processes... 73

4 4 (214) 4.1 DH-211 Metering data report DH-221, DH-222, DH-223 Metering data requests DH-212 Reminder of metering data report DH-300 Contract processes DH-311 Notification of a new contract DH New contract information DH New contract information forward to DSO DH Notification to current supplier of contract end DH Notification of moving out to the supplier of a production accounting point DH Notification of sales agreement cancellation to the future supplier DH DH Customer information update forward DH Zeroing of consumption registered in losses DH-312 Grid agreement confirmation DH-321 Sales agreement information update DH-322 Grid agreement information update DH-323 Notification of accounting pointan accounting point without a supplier DH-331 Notification of sales agreement end DH-332 Notification of Customer Moving Out by New Supplier DH-333 Notification of grid agreement end DH-340 Contract cancellation DH-341 Notification of sales agreement cancellation DH-342 Notification of grid agreement cancellation DH-343 Notification of refusal of sales agreement restore by former supplier DH-344 Notification of grid agreement end in the case of cancellation

5 5 (214) 6 DH-400 Connection and disconnection processes DH-411 Supply connection request DH-412 Notification of supply connection DH-421 Supply disconnection request DH-422 Notification of supply disconnection DH-413, DH-423 Notification of connection or disconnection delay DH-500 Imbalance settlement DH-514, DH-522 Distribution system owner's imbalance settlement data DH-515, DH-521 Supplier s imbalance settlement data DH-523 Consumption and production data registered in losses DH-600 Balance Deviation correction DH-700 Product and invoicing information maintenance processes DH-711, DH-712 Product data update DH-721, DH-722, DH-723 Product data request DH-731, DH-732 Invoice row data report DH-741, DH-742, DH-743 Invoice row data request DH-800 Authorisations DH-811, DH-812, DH-813 Notification of customer authorisation from party DH-821, DH-822, DH-823 Notification of customer authorisation from customer DH-900 Party information DH-910 Notification of party information DH-920 Party information request Message type descriptions Header Process

6 6 (214) 12.3 Payload F01 Structural data, customer F02 Accounting point request F20 Accounting point list E58 Structural data, accounting point F03 Accounting point data request F21 Accounting point data F04 Structural data, agreement F05 Accounting point without supplier F06 Structural data, agreement ending F18 Structural data, agreement cancellation E66 Metering data F07 Metering data reminder F08 Metering data request F09 Connection - disconnection F10 Imbalance settlement data request E31 Imbalance settlement data F19 Balance deviation data F11 Structural data, product F12 Product data request F13 Invoice row data F14 Invoice row data request F15 Authorisation information F16 Party information F17 Party infromation request

7 7 (214) 12.4 ACK Acknowledgement event F99 Request event Code lists

8 8 (214) Change log Date Version Changes Added to chapter that the metering data a party requests and the metering data datahub forwards to party are split into separate queues for parties. Specifications to required data in addresses. Specifications to dependencies between invoicing channel and invoicing addresses. A contact person has been added to supply connection request. Corrected type of calculation into balance settlement type and corrected balance settlement types to chapters 7 and Price unit has been added to both product component and invoice row data, additionally quantity unit has been added to invoice row data. Specified in chapter 9.3 that report of invoice row data is rejected per accounting point. Specified invoice row retrieval criteria in chapter 9.4. Removed meter number from accounting point data request message in chapter : Supply connection/disconnection request and report have been combined into one message type description. Other small corrections to event and message contents. Changes to translations. Removed original sender from customer information message. Defined in chapter 4.1 that only the time series that contain errors are rejected from a metering time series message. Corrected sequence diagrams in chapter 7 to follow asynchronous pattern. Added possibility to request data corrected outside the balance window to imbalance settlement data request. Added customer's postal address to message F21, chapter Removed DSO information from message F04 in chapter Elaborated descriptions for time series s. Other smaller corrections. Updated definitions to input and output area, metering time series, and authorisation. Added definitions juridical actor, technical actor, metered data responsible MGA, parallel MGA and messaging decree. Improved the description of use of different kinds of acknowledgements in chapter 2.6. Further defined how requesting messages works in chapter Improved the description in chapter 2.12 on event synchronicity and asynchronicity, and added chapter Asynchronous data retrievals. Removed contact method from customer information and added it to agreement information. Elaborated in chapter 4.1 that time series values must be positive and that for exchange points both directions are reported separately. Updated new asynchronous sequence diagrams to events DH-220 and DH-740. Added product description to product data. Removed product and product component name from invoice row data. Edited party information so that a party can have multiple invoicing addresses. Corrected examples for different kinds of s in chapter 12. Remade the description of message F21 in chapter

9 9 (214) Document moved to a new template. Terminology corrections throughout the document. Text has been rephrased in several parts of the document. Outdated or unnecessary comments have been removed. Updated definitions for customer, DSO, accounting point, 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. Specified the s used for parties, metering grid areas and accounting points (chapters and 2.4.3). Elaborated the description of partially approved acknowledgement type in chapter 2.6. Columns of message list in chapter 2.8 have been updated. Chapter 2.13 Messaging encryption and packing has been added. The data fields in message tables have been updated to better match the process document. Data fields and their levels have been updated to be more consistent. Messages F02 and F03 have been split into two separate messages each. Former message F02 has been split into messages F02 (accounting point request) and F20 (accounting point list), former message F03 has been split into messages F03 (accounting point data request) and F21 (accounting point data). Free form text fields in addresses have been updated to c/o. 3rd party update requests to customer and accounting point information have been added to chapter 3. Added to chapters 3.2 and 3.3 that if a customer has no sales agreements in datahub, customer information is updated based on DSO's update request. Separate message tables have been added for customer information update requests in chapters 3.2 and new chapter 3.3. Customer information forward to DSO has been added to event DH-112 in chapter 3.2. Clarified procedure with customer and accounting point information update requests in chapters 3.2, 3.3 and 3.7. Updated the necessity of data fields in accounting point update request in chapter 3.7 and in accounting point structural data message in chapter Accounting point type and accounting point subtype data fields have been added to accounting point request message in chapters 3.8 and Metering grid area data has been added to accounting point list message in chapters 3.8 and Tax category has been added to reply message of event DH-133 in chapter 3.10 and to message type F21 in chapter Grid agreement information has been added to reply message of event DH-135 in chapter Metering data report sequence diagram has been updated in chapter 4.1. Forward to the other party of the exchange point has been added. An elaboration has been added to time series in chapter 4.1. Accounting point type has been added metering data request in chapters 4.2 and Metering data request (note 2 in chapter 4.2) has been changed so that active and reactive power are only returned if they have been given a unit in the request. Information forward messages have been added to the notification of a new contract process in chapter 5.1. In addition, cancelling an upcoming agreement, customer information update and zeroing of consumption registered in losses have been added. Product name has been removed from message F04 in chapters 5.1.1, 5.2 and Sales agreement ending process has been updated in chapter 5.6. Information forward to 3rd party and cancelling an upcoming agreement have been added.

10 10 (214) First official version Reason for contract end has been changed to mandatory in event DH-331 in chapter 5.6. Validation rules of connection-disconnection message that are related to accounting point status have been corrected to match the process document in chapter 6. New chapter 7.3 has been added. It describes event DH-523 requesting production and consumption registered in losses. Message types used in the event have been corrected. Notes 1, 2 and 3 have been added to chapter 8 related to reporting balance deviations. Content of message F11 in chapters 9.1 and have been updated to answer the model where products and product components can have multiple names in different languages. Invoice row data report in chapter 9.3 has been altered so that each invoicing row has start and end time. In addition to that, the report has a total invoicing period. Mention of online service has been removed from the beginning of chapter Chapter 10.2 that describes notifying a party about an authorisation given by the customer has been added. Erroneous sequence diagram has been corrected in chapter Necessity of data fields in message F01 in chapter have been changed. Production types, balance settlement types, user groups, customer subtypes, metering methods and metering grid area types have been added to chapter 13. Other invoicing channel has been added to invoicing channels. Biopower and other production have been added to production types.

11 11 (214) 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 metered. 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 an operator s electricity production and acquisition and in its consumption and supply. Balance deviation. A retrospective correction of an error outside the balance window that can be caused by erroneous accounting point metering data or erroneous supplier information. Balance information. Information about an 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. (Metering grid area) balance discrepancy. The total amount of electricity (including losses) supplied to the metering grid area or transmitted from it. If the reported data is correct, the result of the calculation is zero (specified in the esett Handbook). Balancing calculation. A calculation currently in use concerning reading metered locations, 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 metering 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. Exchange point is a point on the border between two electricity grids at which the transmission of electricity between these grids is specified.

12 12 (214) Exchange point metering is a metering related to an exchange point. Consumer. A customer, who is a natural person and acquires or produces electricity mainly for a purpose that is not connected to a business enterprise. Contract information. Information about an accounting point that tells which electricity supplier has a valid sales agreement for which time period. Contract 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 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 an accounting point connected to an agreement process when the process begins. Customer. A physical person, company, association or other community e.g. municipality with a contract 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 is a centralised information exchange solution for the electricity retail market. Dissolving an agreement. The immediate unilateral dissolving of an agreement as a result of breach of contract by one party or some other occurrence entitling the party to dissolve it. Distribution system operator (DSO). A party that manages one or more distribution or high voltage grid and practises licensed electricity grid operation in the grid. (Distribution system operator's) imbalance settlement. An imbalance settlement concerning a DSO and its metering grid areas, as specified in the Electricity Market Act and Metering Decree. 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).

13 13 (214) esett. An organisation responsible for the Nordic Balance Settlement. esett maintains the handbook for the Nordic Balance 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 is a metering related to an exchange point. Finnish Energy (ET) is an organisation for the industrial and labour market policy of the energy and district heating sector. Former supplier. A supplier of electricity whose sales agreement has ended at the accounting point as a result of a new sales agreement reported by the new supplier. 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 an accounting point in Datahub. A GSRN code comprises a GLN code, a serial number and a control number. Hourly data. Metering data where the time interval is an hour. Hourly-metered accounting point. Accounting point at which an installed energy meter registers and forwards hourly data. Hourly metering. Refers to the hourly metering (by hourly time steps) of electrical energy and registering the metered data in the memory of metering equipment. (Metering grid area) imbalance. The total amount of electricity (including losses) supplied to the metering grid area or transmitted from it. If the reported data is correct, the result of the calculation is zero (specified in the esett Handbook). Imbalance settlement. Refers to studying the electricity transactions made during each imbalance settlement period. As a result of this study, the electricity balance of each electricity market party can be determined.

14 14 (214) Imbalance settlement window. A period during which changes can be made to hourly data before the closing of the electricity balances. Input area. A metering grid area to which electricity is transmitted from output area in exchange point metering data and exchange point sum reports. Juridical actor. Messages of messaging interface include defined technical and juridical actors for the information. Technical actor is the system user, who reports or receives the message. Juridical actor is the party, whose information the message includes. 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 balace area consists of metering grid areas. Messaging decree. A decree concerning the information exchange regarding settlement of electricity deliveries. (273/2016) 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 an accounting point or, for example, other indicators in an apartment block. 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 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 decree. A government decree prescribed under the Electricity Market Act, concerning the clarification and metering of the supply of electricity (66/2009). Metering grid area. An area of electricity grid managed by a distribution system operator that contains metering points (accounting points, exchange points and production units). A metering grid area is delimited by individual exchange points. Imbalance settlement is performed on the metering grid area level. 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 contracts from the entities where energy products are metered or computed.

15 15 (214) 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 reactive power from the grid. The register may include hourly data or cumulative readings from reading meterings. 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 DSO. Metering (time series). A concept, that refers to metering data and related metadata, such as time series, 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. Move-in location. An accounting point to which a customer is moving. Move-out location. An accounting point from which a customer is moving. New supplier. An electricity supplier, which initiates an agreement process for a certain accounting point. A new supplier may also be the current supplier of the accounting point. Open supplier. An operator 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 ). Operator. An electricity supplier, DSO or metering responsible party. Output area. A metering grid area from which electricity is transmitted to input area in exchange point metering data and exchange point sum reports. 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. Party. A company or community which functions in one or more roles in the electricity retail market, i.e. electricity market party. A party can be a supplier, a DSO or a 3rd party, and a party must have a contract with datahub. Price time series. Defines the price of a certain product component for each regular time interval (for example each hour). (Electricity) purchase agreement. An agreement by which the customer sells and the supplier buys the customer s small-scale production of electrical energy. (Market) process. A business process between operators described in this document, which concerns the exchange of information between the parties. The processes include agreement

16 16 (214) processes, such as moving or switching suppliers, the delivery of metering data and imbalance settlements. Processing of balance errors. A process in which a monetary supplier- and metering grid areaspecific correction is carried out after the closing of the balance settlement window, as a result of corrected metering errors and balance data. (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 balance side. Profile. An (hourly) time series based on metering data used in imbalance settlement or an annual usage estimate, which comprises those metering points at which electrical consumption, production or transmission are not registered hourly (or through another time step used in imbalance settlement). Reading (or meter reading). A cumulative reading registered by metering equipment. Reading metering. Metering that registers cumulative readings without timestamp data. (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. 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. 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.

17 17 (214) 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 customer production). (Electricity) supply. Refers to the delivery of electricity to be used or resold. (Electricity) supply agreement. An electricity supply agreement is an agreement between a seller and a customer, in which the seller also assumes responsibility for the grid service. If necessary, the seller agrees with the DSO on the grid service. Technical actor. Messages of messaging interface include defined technical and juridical actors for the information. Technical actor is the system user, who reports or receives the message. Juridical actor is the party, whose information the message includes. Terminating an agreement. The termination of an agreement by one of the parties in accordance with the terms and conditions specified in the agreement. Third party. A party operating in the electricity retail market, which provides a service for operators and customers. Time stamp. Data concerning metering, which indicates the moment in time at which metered energy is registered. (Metering data) time stamp. The time-related register marking of metering data, which indicates which period of time the data concerns. 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. (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 series of zero values.

18 18 (214) 1 Introduction 1.1 General This document contains interface descriptions concerning Datahub information exchange. The document is based on business processes and data models described by Datahub process workgroups. The documentation has been produced in close co-operation with the industry by a Datahub technical group of experts. The industry had an opportunity to comment the document after it was completed. In addition to the Fingrid project group the members of the technical expert group were: Jari Arve, Ari Hallikainen, Jari Hirvonen, Mikko Horsmanheimo, Marko Juslin, Arttu Lahtinen, Esa Pietarinen, Marjut Puukangas, Joni Räsänen, Merja Toikko, Satapirkan Sähkö Oy Enoro Oy (workshop facilitation) Fingrid Oyj (group chairman) Caruna Oy Fingrid Oyj Fortum Markets Oy Fingird Oyj Fingird Oyj Tieto Oyj Enfo Zender Oy Chapter 2 presents general rules concerning messages and events, which are generally related to interfaces. Chapters 3 to 11 describe data content used in different datahub events, event forward chains and preliminary event validations. The event validations presented in the document are preliminary and validations will be specified in conjunction with the system s design and implementation phase. In addition to the listed checks, event validation also looks at event-specific data necessities and enumerations. A negative setoff is returned for erroneous events. Chapter 12 gives a description of the general message types, which are used to implement the events in chapters XML specifications will be done based on this chapter.

19 19 (214) 2 General interface specifications As a basis for interface specifications, ebix message specifications have been used, as well as specifications and documentation from the Harmonised Nordic Retail Project (HNR) and Norway Datahub project (Elhub). The above-mentioned standards and message specifications have been applied where possible. The functional entity of Finland s Datahub is, however, considerably more extensive, so the direct utilisation of existing specifications, such as they are, remains limited. Compared to Elhub, Finland s Datahub models more exactly a centralised customer register, information about sales and grid agreements, product and price information and invoice row information. Finland s Datahub is also based entirely on hourly metering data, whilst Elhub also processes reading meterings for profile accounting points. Because of this, a significant number of national extensions has had to be carried out on the interfaces. Because the number of necessary extensions is significant, in certain situations the message structure has also been simplified in comparison to the ebix message specifications. An acknowledgement message utilising the ebix structure is used, which is specified for the needs of Datahub. 2.1 Namespace XML namespace specifies the elements and attributes of messages and events. Datahub messages use the following specification for namespace: urn:fi:datahub:mif:<package>:<message name>:<major version> Package - The following values are used: Masterdata - Messages related to structural data updates Metering - Messages related to metering data Invoicing - Messages related to invoicing Query - Messages related to enquiries Message name Specifies the name of a message Major version specifies the message version, uses the prefix v. In the message, the namespace abie is also used to define general entities and code lists, which are used in messages. Example:

20 20 (214) <rsm:masterdatacustomer xmlns:rsm="urn:fi:datahub:mif:masterdata: MasterDataCustomer:v1" xmlns:abie="urn:fi:datahub:mif:common:aggregatedbusinessdataentities:v1" <rsm:header><abie:identification>123e4567-e89b-12d3-a </abie:identification> 2.2 Versions Message version The message version is presented under the namespace specification of the xml file. The message version will be updated when changes are made to messages, which no longer guarantee retrospective compatibility with the previous message version. Such changes include: Enumeration - the elimination or changing of values Changes to the names of elements, types or attributes Changes to the structure or order of a message The elimination or addition of compulsory elements or attributes Making elements or attributes compulsory Message sub-version Message specifications can be updated with a sub-version without a version update if the retrospective compatibility of messages is preserved. These changes are presented in the XML schema specification with the xsd version attribute in the schema file (xsd). Addition of enumeration values Non-compulsory message extensions schemasite A reference to the schema file used (xsd) is presented in the specification xsi:schemasite in the form <nimiavaruus><xsd tiedosto>. Example: xmlns:xsi= xsi:schemasite="urn:fi:datahub:mif:masterdata:masterdatacustomer:v1 MasterDataCustomer.xsd">

21 21 (214) 2.3 Message structure All Datahub messages comprise the following parts: Message header data Process data Payload Header Message header data includes the following data: Data field Level Pakollisuus Kommentti Huom: Header data [1] Message Message's unique identifier [2] Message type Message creation time Technical sender of message Juridical sender of message Technical recipient of message Juridical recipient of message See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) Sender s routing data Routing data set by the sender [4] Note Specification [1] In Datahub messaging, an acknowledgement message is formed for all received messages. No acknowledgement request is presented in the message header. [2] The message ID must always be unique to the sender. Datahub will reject a message if a message has already been received from the same sender with the same message ID Resending is always done with a new message ID, both for corrected data, and in a situation where the same data is re-sent. [3] Technical actor of a message means the party that delivers/receives the message. Juridical actor of a message means the party whose data is handled in the message. For example, if the service provider takes care of the collection and delivery of metering data to Datahub (on behalf of the DSO), the technical sender is the service provider and the juridical sender is the DSO. The technical actor must always have an authorisation for the process in question from the juridical actor. [3] [3] [3] [3]

22 22 (214) [4] The message sender may set routing data for the message, which is returned in an acknowledgement message. Routing data can be utilised in the routing of the received acknowledgement to the system sending the original message. A more detailed description of a header is presented in chapter Process Message process data includes the following data: Data field Level Necessity Comment Note Process Process Uses Datahub event s (e.g. DH-111-1) Information exchange role Industry Electricity A technical description of process data is presented in the message description section, Process Payload Events and data content related to processes are described event-specifically in chapters 3 to 11. Technical descriptions of general message types, which are used to implement the events described in chapter 3-11, are described in chapter General elements This chapter describes rules generally applicable to messages and events. The rules are applicable to all event descriptions presented below, unless otherwise stated in an individual description Administrators of IDs and code lists The following administrators of IDs and code lists are used in messages and events: ID administrators: EIC, schemaagencyidentifer = 305 GS1, schemaagencyidentifer = 9 ebix and national ID, schemaagencyidentifier = 260

23 23 (214) Code list administrators: UN/CEFACT, listagencyidentifer = 6 ISO, listagencyidentifer = 5 ebix, listagencyidentifer = 260. Country code, listagencyidentifer = NFI Parties and metering grid areas GLN codes of the GS1 system are used for party IDs and EIC codes are used for metering grid area IDs Accounting point s GSRN codes of the GS1 system are used for accounting point IDs Timestamps and time periods All timestamps are presented in UTC (Coordinated Universal Time), and in XML format YYYY-MM- DDTHH:MM:SS+00:00 or YYYY-MM-DDTHH:MM:SS. Example: T21:00:00+00: T21:00:00Z Default validity periods (start time and end time) are set at the end of 24-hour periods (official Finnish time). In metering data, timestamps are set for full hours. Message creation times (and other corresponding technical event times) are presented to the level of accuracy of a second. The times for the ending of validity periods (e.g. end date of agreement) are presented as moments of ending. For example, if the last date of validity of an agreement is 31 December 2015, the moment of ending is T22:00:00+00:00 (according to official Finnish time :00) Value units IDs based on the SI system are used as unit codes for values, e.g. kw, MW, kwh, MWh, kvar, MVAR, kvarh, Mvarh Message IDs UUID IDs (Universally Unique Identifiers) are used as message IDs.

24 24 (214) 2.5 Message validations Datahub validates messages on three different levels presented below XML schema In XML schema validation, the message is checked on a technical level against the schema. Validation checks the message structure, the necessity of elements and attributes, and the correctness of the form of data (format and maximum length of field), and the enumeration of data. In case of error, a rejection of the SOAP level is returned (SOAP Fault) Process validations In process validation, process level data and the process ID and role are checked, as well as the rights of the party to report the process event in question. The roles of message senders are listed in chapter Message list. In case of error, a rejection of the SOAP level is returned (SOAP Fault) Event validations Event validation includes event-specific validations based on market processes, which are not validated in XML schema- and process validations. In event validation, the attainment of interdependencies and time limits between the report s attributes are validated, and the reported values are validated against the data content of Datahub. A positive acknowledgement message is returned for an event that passed the validations. A negative acknowledgement including an error report (error ID and error text) is returned for incorrect messages. In connection with event validation, reported attribute values are also validated against rules specified in the data standard column permitted values. A Finnish personal ID should, for example, meet the requirements set for it in legislation ( In event-specific descriptions (chapters 3 to 11), event validations related to the event in question are listed. 2.6 Acknowledgement processing Datahub acknowledges requests of parties on two levels: technical and process level. On technical level, the datahub interface always responds to each request by a party communicating whether the request was understood and received in its entirety, or not. This is a so-called technical acknowledgement of the interface, which is separate from e.g. process level business acknowledgements presented in sequence diagrams. Technical acknowledgements are not presented in sequence diagrams. Datahub delivers a positive or negative acknowledgement to all received messages also on process level. In data retrieval events the retrieved data serves as a positive acknowledgement

25 25 (214) and a negative acknowledgement is returned in error situations. The errors found in process and event validations described in chapter 2.5 are reported in the negative acknowledgement. For synchronous services the process level acknowledgement is returned to the party when datahub has processed the request in its entirety. For asynchronous services, datahub returns first a technical acknowledgement for accepting the request and later an asynchronous process level acknowledgement for processing the event. Asynchronous services are described in more detail in chapter An acknowledgement message is always used at Datahub interfaces so that message header data does not separately specify whether an acknowledgement is wanted or not. When retrieving messages, the party retrieving them from Datahub should acknowledge receipt of the messages with a separate acknowledgement message as described in chapter An acknowledgement message based on the ebix structure is applied in Datahub interfaces in process level acknowledgements. It includes the header, process and acknowledgement event. In terms of content, a message s process element is the same as in the original message to be acknowledged. The content of an acknowledgement event is as follows: Data field Level Necessity Comment Note Acknowledgement event Acknowledgement time Original message Original message sender Description Acknowledgement of event level 1 1..n Acknowledgement type Approved Partially approved Rejected [1] Acknowledgement text Error text, if the event is not approved Update type Switching agreements Switching suppliers Moving in [2] Acknowledgement of time series level Sender s time series Only used for metering data Acknowledgement type Error code Acknowledgement text Error text Note Specification

26 26 (214) [1] [2] The partially approved type of acknowledgement is used in metering data messages when Datahub is receiving metering data. In that case, the rejected time series are reported when acknowledging the time series level. When retrieving metering data from Datahub, this type of acknowledgement is not used. The partially approved type of acknowledgement is also used when authorisations to customer or accounting point information are reported, if the customer does not have a contract for the accounting point of the reported authorisation (DH-810). In this case, the party who reports the authorisation gains authorisation only to the customer's information. Used in a positive acknowledgement to express the type of update in Datahub. For example, when acknowledging a sales agreement, the reason for the sales agreement that Datahub comes up with is returned (switching agreement, switching supplier, moving in). The technical description of the acknowledgement message is presented in chapter Enquiry events Values for enquiry events can be entered into the text-based data fields in upper and lower case. The retrieval does not differentiate between upper- and lower-case characters. In retrieving an accounting point, the retrieval value of a street name is supported by a star (*) to denote a wildcard character at the beginning and end of the value (e.g. Syy*, *riankatu, *yy*ia*). A wildcard character can also be supported in the building number and floor ID fields. 2.8 Message list The table below is a summary of market process events and messages used in them. The message column of the table refers to the general message types. A general message type can be utilised in one or several market processes. Data content, format of data fields, exemplary data, XML reference of data as well as levels and obligatoriness of data fields concerning XML messages and schemas for these message types are describedin chapter 12. Process specific data contents, data field levels and obligatoriness as well as process specific comments are presented in chapters Time series-type messages use ebix messages applied based on NBS specifications (for E66 metering data and E31 imbalance settlement data). With regard to other events, adequate correlation from ebix specifications was only found for accounting point structural data (E58). For other messages, national Datahub messages had to be separately specified (Fxx messages).

27 27 (214) Process Sender Recipients Message type ID Message type description Datahub DH-111 Customer information update Supplier DSO Supplier F01 Structural data, customer 3rd party DH-112 Customer information update request DSO Datahub Supplier F01 Structural data, customer DH-121 New accounting point DSO Datahub E58 Structural data, accounting point DH-122 Accounting point data update DSO Datahub Supplier 3rd party E58 Structural data, accounting point DH-123 Accounting point deletion DSO Datahub E58 Structural data, accounting point DH-124 Accounting point data update request Supplier Datahub DSO E58 Structural data, accounting point DH-131 Accounting point request Supplier DSO 3rd party Datahub F02 F20 Accounting point request Accounting point list DH-132 Accounting point and customer information request current supplier Supplier Datahub F03 F21 Accounting point data request Accounting point data DH-133 Accounting point and customer information request new supplier Supplier Datahub F03 F21 Accounting point data request Accounting point data DH-134 Accounting point and customer information request DSO DSO Datahub F03 F21 Accounting point data request Accounting point data DH-135 Accounting point and customer information request 3rd party 3rd party Datahub F03 F21 Accounting point data request Accounting point data DH-211 Metering data report DSO Datahub Supplier 3rd party E66 Metering data DH-221, DH-222, DH-223 Metering data requests Supplier DSO 3rd party Datahub F08 Metering data request DH-212 Reminder of metering data report Datahub DSO F07 Metering data reminder

28 28 (214) Process Sender Recipients Message type ID Message type description DH-311 Notification of a new contract Supplier Datahub DSO (Supplier) F04 Structural data, agreement DH-312 Grid agreement confirmation DSO Datahub Supplier F04 Structural data, agreement DH-321 Sales agreement information update Supplier Datahub DSO F04 Structural data, agreement DH-322 Grid agreement information update DSO Datahub Supplier F04 Structural data, agreement DH-323 Notification of an accounting point without a supplier Datahub DSO F05 Accounting point without supplier DH-331 Notification of sales agreement end Supplier Datahub DSO Supplier F06 Structural data, agreement ending DH-322 Notification of customer moving out by new supplier Supplier Datahub DSO F06 Structural data, agreement ending DH-333 Notification of grid agreement end DSO Datahub Supplier F06 Structural data, agreement ending DH-341 Notification of sales agreement cancellation Supplier Datahub DSO Supplier F18 Structural data, agreement cancellation DH-342 Notification of grid agreement cancellation DSO Datahub Supplier F18 Structural data, agreement cancellation DH-343 Notification of Refusal of Sales Agreement Restore by Former Supplier Supplier Datahub DSO F06 Structural data, agreement ending DH-344 Notification of Grid Agreement End In the Case of Cancellation DSO Datahub Supplier F06 Structural data, agreement ending DH-411 Supply connection request Supplier Datahub DSO F09 Connection - disconnection request DH-412 Notification of supply connection DSO Datahub Supplier F09 Connection - disconnection report DH-421 Supply disconnection request Supplier Datahub DSO F09 Connection - disconnection request

29 29 (214) Process Sender Recipients Message type ID Message type description DH-422 Notification of supply disconnection DSO Datahub Supplier F09 Connection - disconnection report DH-413, DH-423 Notification of connection or disconnection delay DSO Datahub Supplier F09 Connection - disconnection report DH-514 Distribution system operator's imbalance settlement data report DH-515 Supplier s imbalance settlement data report Datahub DSO E31 Imbalance settlement data Datahub Supplier E31 Imbalance settlement data DH-522, DH-523 Distribution system operator's imbalance settlement data request DSO Datahub F10 E31 Imbalance settlement data request Imbalance settlement data DH-521 Supplier s imbalance settlement data request Supplier Datahub F10 E31 Imbalance settlement data request Imbalance settlement data DH-600 Balance deviation correction Datahub Supplier DSO F19 Balance deviation data DH-711, DH-712 Product data update Supplier DSO Datahub F11 Structural data, product DH-721, DH-722, DH-723 Product data request Supplier DSO 3rd party Datahub F12 F11 Product data request Datahub DH-731, DH-732 Invoice row data report Supplier DSO DSO Supplier F13 Invoice row data 3rd party DH-741, DH-742, DH-743 Invoice row data request Supplier DSO 3rd party Datahub F14 F13 Invoice row data request DH-811, DH-812, DH-813 Customer authorisation from party Supplier DSO 3rd party Datahub F15 Authorisation information DH-821, DH-822, DH-823 Customer authorisation from customer Datahub Supplier DSO 3rd party F15 Authorisation information

30 30 (214) Process Sender Recipients Message type ID Message type description Supplier DH910 Party information Datahub DSO F16 Party information 3rd party DH920 Party information request Supplier DSO 3rd party Datahub F17 F16 Party information Acknowledgement event Supplier DSO 3rd party Supplier DSO 3rd party ACK Acknowledgement event Datahub Datahub Request event Cancellation event Supplier DSO 3rd party Supplier DSO Datahub F99 Request event Datahub E67 Original event, see Cancellation messages and events Cancellation practices for different events are described in the table below. Cancellation conditions, i.e. the rules according to which the cancellation may happen, are described eventspecifically in the process document. When using a cancellation message, the original message data is sent using message type E67. Data to explain the cancellation may also be sent. Process Message Cancellation method DH-111 Customer information update supplier DH-112 Customer information update request DH-121 New accounting point DH-122 Accounting point data update DH-124 Accounting point data update request F01 F01 E58 E58 E58 Cancellation is done with a new update Cancellation message Creation of the accounting point may be cancelled by removing the accounting point (DH-123), if no other events have yet been allocated to the accounting point. Cancellation is done with a new update Cancellation message DH-211 Metering data report E66 Cancellation is done with a new update DH-311 Notification of a new contract F04 Separately defined cancellation message (DH-341) DH-312 Grid agreement confirmation F04 Separately defined cancellation message (DH-342)

31 31 (214) Process Message Cancellation method DH-321 Sales agreement information update DH-322 Grid agreement information update DH-331 Notification of sales agreement end DH-333 Notification of grid agreement end F04 F04 F06 F06 Cancellation is done with a new update Cancellation is done with a new update Cancellation message Cancellation message DH-411 Supply connection request F09 Cancellation message DH-412 Notification of supply connection DH-421 Supply disconnection request DH-422 Notification of supply disconnection DH-413, DH-423 Notification of connection or disconnection delay DH-711, DH-712 Product data update DH-731, DH-732 Invoice row data report DH-811, DH-812, DH-813 Notification of customer authorisation F09 F09 F09 F09 F11 F13 F15 Cancellation message Cancellation message Cancellation message Cancellation done by connection/disconnection report Cancellation is done with a new update Cancellation done by correction rows (rows with an inverse amount to be invoiced compared to the original rows). Cancellation message The following validations are carried out for a general cancellation event (E 67): # Event validation 1 The original message to be cancelled is received in the system. In the cancellation message, reference is made to the original message with the element original message. 2 The sender of the cancellation message is the same as the sender of the original message. 3 The date of validity of the cancellation message and original message is the same Event forwarding Datahub forwards received events to the necessary parties. By default, the same data as in the received message is forwarded. If the data content differs, this is separately mentioned. With regard to agreement events (agreement creation and updating events), separate forwarding events are specified because not all agreement information should be relayed between the parties.

32 32 (214) If an update event reported to datahub based on an update request does not include changes compared to the data in Datahub, information is forwarded only to the party that has requested the data update. Such request events are a customer information update request from the DSO to the supplier and an accounting point data update request from the supplier to the DSO Request event Datahub does not deliver messages going to parties automatically. The messages created are buffered in a delivery queue, from which the party retrieves them one by one. Datahub delivers messages in an order accordance with the creation time presented in the message s header. A retrieved message remains in the queue until the party has separately informed datahub that the message has been retrieved The parties retrieve the messages using the request event. The data content of a request event is as follows: Data field Level Necessity Comment Note Request event 1..1 Time stamp Party [1] Message package Description Structural data Metering data Invoicing information [2] Note Specification [1] Events allocated to the party in question are returned [2] In addition to payload, acknowledgement events related to the message package in question are also returned. Asynchronous data retrievals are differentiated to their own separate queues for each party, i.e. metering data and invoice row data retrievals. This way asynchronous retrievals do not get mixed up with other information exchange. Metering data is differentiated for each party separately to queues for DH-211 data forwarded by Datahub and DH-220 data requested by the party. Parties can decide themselves how the queues will be unloaded to the party's own systems when the interface is implemented Event synchronicity/asynchronicity With regard to structural data updating and enquiry events, service interfaces are synchronised. Acknowledgement and/or response data to the enquiry are returned as a service request response during the same session.

33 33 (214) With regard to time series data (metering data and imbalance settlement data) and invoice row data, services are asynchronous both for reporting and retrieving data. Datahub returns a synchronous technical level acknowledgement immediately for receiving data. Processing of actual event is acknowledged and response data to the enquiry is returned separately asynchronously through the retrieval service Asynchronous data retrievals When a request event is received the interface verifies that its form matches the specifications. At the same time, it is verified that the party is authorised, based on their role, to send that type of request event. If the form check or the role check produces a negative outcome, datahub returns a negative acknowledgement and the processing of the request ends. If the request event is in correct format and the party has the required role, datahub starts processing the request. During processing, datahub verifies that the party is authorised to the requested data on the accounting point level. If the party has requested a set of data and they are only authorised to part of it, datahub returns the part of the requested data the party is authorised to. An error message is returned for the data that the party was not authorised to. After the result of the request datahub produces a positive acknowledgement for the party to retrieve. After retrieving the acknowledgement the party knows they have received all the messages related to the request Messaging encryption and packing Events are transferred as encrypted HTTPS (TLS 1.2). Messages are signed with certificates using WS-Security. Messages are not separately encrypted using WS-Security. The metering data events which are sent must be packed and respectively metering data events sent forwarded by datahub are packed. Packing is done alongside of data transfer (HTTP/S) using HTTP Compression method.

34 34 (214) 3 DH-100 Customer and accounting point data maintenance processes FIGURE 1 CUSTOMER AND ACCOUNTING POINT EVENTS

35 35 (214) 3.1 DH-111 Customer information update supplier Customers are created in connection with agreement events. Customer information updates are carried out in Datahub by the supplier. Datahub forwards the updated customer information to DSOs and suppliers, which have a valid or soon-to-be valid agreement with the customer. Data is also forwarded to third parties authorised by the customer to receive customer information. Event Message type Message type description Sender Recipient Note [*] DH F01 Structural data, customer Supplier Datahub DH F01 Structural data, customer Datahub DSO DH F01 Structural data, customer Datahub Supplier DH F01 Structural data, customer Datahub 3rd party Note [*] Specification Datahub forwards the same payload to the other parties. The of the original message is added to the message. If the message data received from the supplier is the same as the data in Datahub (the data does not change), the payload is not forwarded to other parties. The exception to this is a situation in which the DSO has requested a customer information update (DH-112-1). In that case, the data is forwarded to the DSO in question.

36 36 (214) FIGURE 2 DH-111 CUSTOMER INFORMATION UPDATE SUPPLIER Payload sent by the supplier includes the following information: Information field Level Necessity Comment Note Customer information Start of occurrence Original message Only used in a relayed message [1] Basic customer information

37 37 (214) Customer Customer type Customer type Customer sub-type Either business ID, association ID, personal identity number or party's own customer is used. Business ID Association ID Personal ID Party s own Company Consumer Normal Estate of a deceased person [2] Party s own customer [3] Information restriction Yes/No. Language ISO ID used. Company name Given name Compulsory for business customer Compulsory for consumer customer Middle names Family name Date of birth Compulsory for consumer customer Compulsory for consumer customer, if no personal ID has been given YYYY-MM-DD Additional Contact information [4] Type Telephone address Telephone number address Postal address [5] c/o Address specifier Street name Building number Floor Room Postal code

38 38 (214) PO Box Post office Country ISO alpha-2 ID is used. Note [1] [2] [3] [4] [5] Specification Datahub forwards the of the original message from the supplier with the forwarded message in this field. If a business customer also needs to have a personal identity number, that is reported in the additional field. If party's own customer is used, it is in the form <supplier s >_<customer number> (used as specifying data in a situation in which the personal is not known). This field is used only in a situation in which party's own customer is updated into a personal ID. One telephone number and one address may be specified for a customer. At least one of them must be given. In the address information, either the street name and building number, or the PO Box number must be given in addition to the postal code. The following event validations are carried out for payload: # Event validation 1 Post office is correct based on the postal code. This check is made only for Finnish addresses. 2 The customer is found in Datahub. 3 The supplier has a valid or soon-to-be valid agreement with the customer. 4 The Start of Occurrence may not be in the past.

39 39 (214) 3.2 DH-112 Customer information update request - DSO The DSO may request a customer information update. In such a request, the DSO sends the customer s customer information. Datahub relays a request to the supplier, which last made an agreement with the customer in question. If the customer has no sales agreements in datahub, customer information is updated directly based on the update request. In that case datahub returns the stored data as a confirmation to the DSO. Event Message type Message type description Sender Recipient Note [*] DH F01 Structural data, customer DSO Datahub DH F01 Structural data, customer Datahub Supplier DH F01 Structural data, customer Datahub DSO Note [*] Specification Datahub relays the same payload to the supplier. The ID of the original message is added to the message. FIGURE 3 DH-112 CUSTOMER INFORMATION UPDATE REQUEST - DSO

40 40 (214) In the event, compulsory data is forwarded as well as the data to be updated. If some data is to be deleted, an empty element/data field which corresponds the data to be deleted is sent. If one does not want to alter optional data, the element/data field in question is not sent at all. Message payload includes the following information: Information field Level Necessity Comment Note Customer information Start of occurrence Original message Only used in a relayed message [1] Description Only used in an update request Basic customer information Customer Customer type Customer type Customer sub-type Either business ID, association ID, personal identity number or party's own customer is used. Business ID Association ID Personal ID Party s own Company Consumer Normal Estate of a deceased person [2] Party s own customer [3] Information restriction Yes/No. Language ISO ID used. Company name Given name Middle names Family name Date of birth Compulsory for consumer customer, if no personal ID has been given YYYY-MM-DD Additional Contact information [4] Type Telephone address Telephone number address

41 41 (214) Postal address c/o Address specifier Street name Building number Floor Room Postal code PO Box Post office Country ISO alpha-2 ID is used. Note [1] [2] [3] Specification Datahub forwards the of the original message from the supplier with the forwarded message in this field. If a business customer also needs to have a personal identity number, that is reported in the additional field. If party's own customer is used, it is in the form <supplier s >_<customer number> (used as specifying data in a situation in which the personal is not known). This field is used only in a situation in which party's own customer is updated into a personal ID. [4] One telephone number and one address may be specified for a customer. No cancellation message is used for a customer information update request. Cancellation is done with a new update message. The following event validations are carried out for payload: # Event validation 1 Post office is correct based on the postal code. This check is made only for Finnish addresses. 2 The customer is found in Datahub. 3 The DSO has a valid agreement customer. 4 The Start of Occurrence may not be in the past.

42 42 (214) 3.3 DH-113 Customer information update request - 3rd party The 3rd party may also request a customer information update. In such a request, the 3rd party sends the customer s customer information. Datahub relays a request to the supplier, which last made an agreement with the customer in question. If the customer has no sales agreements in datahub, request is relayed to the DSO, which last made an agreement with the customer in question. Event Message type Message type description Sender Recipient Note [*] DH F01 Structural data, customer 3rd party Datahub DH F01 Structural data, customer Datahub Supplier DH F01 Structural data, customer Datahub DSO Note [*] Specification Datahub relays the same payload to the supplier. The ID of the original message is added to the message. FIGURE 4 DH-113 CUSTOMER INFORMATION UPDATE REQUEST - 3RD PARTY

43 43 (214) In the event, compulsory data is forwarded as well as the data to be updated. If some data is to be deleted, an empty element/data field which corresponds the data to be deleted is sent. If one does not want to alter optional data, the element/data field in question is not sent at all. Message payload includes the following information. Information field Level Necessity Comment Note Customer information Start of occurrence Original message Only used in a relayed message [1] Description Only used in an update request Basic customer information Customer Customer type Customer type Customer sub-type Either business ID, association ID, personal identity number or party's own customer is used. Business ID Association ID Personal ID Party s own Company Consumer Normal Estate of a deceased person [2] Party s own customer [3] Information restriction Yes/No. Language ISO ID used. Company name Given name Middle names Family name Date of birth Compulsory for consumer customer, if no personal ID has been given YYYY-MM-DD Additional Contact information [4] Type Telephone address Telephone number address

44 44 (214) Postal address c/o Address specifier Street name Building number Floor Room Postal code PO Box Post office Country ISO alpha-2 ID is used. Note [1] [2] [3] Specification Datahub forwards the of the original message from the supplier with the forwarded message in this field. If a business customer also needs to have a personal identity number, that is reported in the additional field. If party's own customer is used, it is in the form <supplier s >_<customer number> (used as specifying data in a situation in which the personal is not known). This field is used only in a situation in which party's own customer is updated into a personal ID. [4] One telephone number and one address may be specified for a customer. No cancellation message is used for a customer information update request. Cancellation is done with a new update message. The following event validations are carried out for payload. # Event validation 1 Post office is correct based on the postal code. This check is made only for Finnish addresses. 2 The customer is found in Datahub. 3 The DSO has a valid agreement customer. 4 The Start of Occurrence may not be in the past.

45 45 (214) 3.4 DH-121 New accounting point A new accounting point is created in Datahub by the distribution system operator. At this stage, the accounting point does not have registered agreements so the creation event is not forwarded. Event Message type Message type description Sender Recipient Note [*] DH-121 E58 Structural data, accounting point DSO Datahub FIGURE 5 DH-121 NEW ACCOUNTING POINT Message payload includes the following information: Information field Level Necessity Comment Note Accounting point data Start of occurrence Original message Original message sender Only used in a forwarded message Only used in a forwarded message Description Only used in an update request Basic accounting point data

46 46 (214) Accounting point Accounting Point Status Accounting point type Accounting point sub-type Connected Disconnected Under construction Consumption Production Production unit s own consumption Normal Property accounting point Remotely connectable Yes/No Area information Metering grid area [1] Meter number Active metering meter number Related accounting point The for a corresponding consumption accounting point/production accounting point is given for a small-scale production location. Accounting point addresses 3 1..n Type of address Main address Additional address Street name [2] Building number Floor Room Postal code Post office Country ISO ID used. c/o Language ISO ID used. Coordinates WGS84 standard is used. Latitude Longitude Accounting point characteristics Compulsory if the status of the accounting point is not under construction.

47 47 (214) Remotely readable Yes/No Metering method User group Hourly metering Reading metering Unmetered Classification specified by Statistics Finland is used based on the purpose of electricity consumption. Compulsory for consumption accounting point. Heating is dependent on electricity Yes/No Fuse size Format used based on procedural guidelines for messaging: <number of cables>x<number of phases>x<amperes> The number of cables is excluded if only one cable is in use. See chapter 3.8 for procedural guidelines for messaging. For example, 3x25, 2x3x25 [3] Connection capacity Always given in kilowatts [3] Annual consumption estimate Always given in kilowatt-hours Controlled load 3 0..n Storage equipment 3 0..n Production device 3 0..n See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) Note [*] Specification The data Reactive energy time series available and Metering time step is not relayed in the accounting point event. Datahub concludes this data based on received metering data. Time zone data is not kept at the accounting point, but is specified based on the grid agreement product/product components and calendar. [1] An EIC code is used as the for a metering grid area. [2] The address of an accounting point must always include the street name. If the accounting point has no official street address, the name of the nearest street is marked as the street name and the location of the accounting point is specified in the c/o field.

48 48 (214) [3] Either fuse size or connection capacity must be given. Extract from the procedural guidelines: It is recommended that fuse data be recorded in messages on the following conditions: without dashes, in lower case (x) and without ampere symbols (A, a), i.e.3x25 for example. If the location has several connection cables, it is entered, for example, as 2x3x63. The 1x3x63 notation must not be used in lower case (x) without ampere symbols (A, a), i.e.3x25 for example. If the location has several connection cables, it is entered, for example, as 2x3x63. The notation 1x3x63 should not be used. The following event validations are carried out for payload: # Event validation 1 Accounting point has not yet been entered in the system. 2 Accounting point ID (GS1) is in the correct form. 3 Metering grid area belongs to DSO. 4 Post office is correct based on the postal code. This check is made only for Finnish addresses.

49 49 (214) 3.5 DH-122 Accounting point data update Accounting point data updates are carried out in Datahub by the distribution system operator. Datahub relays the updated accounting point data to the valid and future supplier of the accounting point. In addition to this, changed accounting point data is relayed to third parties with valid authorisation from the customer for the accounting point. Event Message type Message type description Sender Recipient Note [*] DH E58 Structural data, accounting point DSO Datahub DH E58 Structural data, accounting point Datahub Supplier DH E58 Structural data, accounting point Datahub 3rd party Note [*] Specification Datahub forwards the same payload to the other parties. The and sender of the original message are added to the message. If the message data received from the DSO is the same as the data in Datahub (the data does not change), the payload is not forwarded to other parties. The exception to this is a situation in which the supplier has requested an accounting point data update (DH-124-1). In that case, the data is forwarded to the supplier in question.

50 50 (214) FIGURE 6 DH-122 ACCOUNTING POINT DATA UPDATE A message s payload includes the same data as event DH-121. In an update event, all the accounting point s data is delivered, not only the data that has changed. The following event validations are carried out for payload: # Event validation 1 Accounting point found in the system. 2 Metering grid area belongs to DSO.

51 51 (214) 3 Post office is correct based on the postal code. This check is made only for Finnish addresses. 4 Accounting point cannot be updated to a status removed from use, if the accounting point has a valid sales or grid agreement.

52 52 (214) 3.6 DH-123 Accounting point deletion The deletion of an accounting point is done by the distribution system operator. An accounting point may be deleted only if it has no agreement events. The deletion message is not forwarded. A deletion message is only used to completely delete from the system accounting points that have been incorrectly created. The deletion from use of an accounting point is done in the accounting point s update event by updating the status. Event Message type Message type description Sender Recipient Note [*] DH-123 E58 Structural data, accounting point DSO Datahub Note Specification FIGURE 7 DH-123 ACCOUNTING POINT DELETION Message payload includes the following information: Information field Level Necessity Comment Note Accounting point data Start of occurrence Basic accounting point data

53 53 (214) Accounting point Area information Metering grid area The following event validations are carried out for payload: # Event validation 1 Accounting point found in the system. 2 No agreement events have been entered for the accounting point.

54 54 (214) 3.7 DH-124 Accounting point data update request The supplier or 3rd party may request an accounting point data update. Datahub relays the request to the DSO. Event Message type Message type description Sender Recipient Note [*] DH E58 Structural data, accounting point Supplier 3rd party Datahub DH E58 Structural data, accounting point Datahub DSO Note [*] Specification Datahub forwards the same payload to the DSO. The and sender of the original message are added to the message. FIGURE 8 DH-124 ACCOUNTING POINT DATA UPDATE REQUEST DIAGRAM In the event, compulsory data is forwarded as well as the data to be updated. If some data is to be deleted, an empty element/data field which corresponds the data to be deleted is sent. If one does not want to alter optional data, the element/data field in question is not sent at all. Message payload includes the following information:

55 55 (214) Information field Level Necessity Comment Note Accounting point data Start of occurrence Original message Original message sender Only used in a forwarded message Only used in a forwarded message Description Basic accounting point data Accounting point Accounting point address n Address type Main address Additional address Street name Building number Floor Room Postal code Post office Country ISO ID used. c/o Language ISO ID used. Accounting point characteristics User group 4 0.,1 Classification specified by Statistics Finland is used based on the purpose of electricity consumption. Annual consumption estimates Tax category [1] Controlled load 3 0..n Storage equipment 3 0..n See message type's general description (chapter 12) See message type's general description (chapter 12)

56 56 (214) Production device 3 0..n Note [1] Specification See message type's general description (chapter 12) The tax category is agreement-level data, not a characteristic of the accounting point. The tax category is included in the accounting point update request so that the supplier may request an update of the tax category. The following event validations are carried out for payload: # Event validation 1 Accounting point found in the system. 2 Accounting point and metering grid area tally. 3 The supplier has a valid or soon-to-be valid agreement for the accounting point. 4 Post office is correct based on the postal code. This check is made only for Finnish addresses. 6 The Start of Occurrencemay not be in the past.

57 57 (214) 3.8 DH-131 Accounting point request An accounting point ID can be retrieved based on the accounting point address. The request can be specified using the meter number. The request returns a list of accounting points plus their address data. Event Message type Message type description Sender Recipient Note [*] DH F02 Accounting point request Supplier 3rd party Datahub DH F20 Accounting point list Datahub Supplier 3rd party Note Specification FIGURE 9 DH-131 METERING DATA IDENTIFICATION REQUEST DIAGRAM The following request criteria are available for query events:

58 58 (214) Information field Level Necessity Comment Note Accounting point address enquiry Street name Building number Floor Room Supported by wildcard characters in the retrieval value. Supported by wildcard characters in the retrieval value. Supported by wildcard characters in the retrieval value. [1] Postal code [1] Post office [1] Meter number Active metering meter number Accounting point type Accounting point sub-type Normal Building Accounting Point Related accounting point Note [1] Specification In addition to the street name, either the postal code or post office must always be given in the retrieval. In an enquiry event, no other event validations are made in addition to the necessities. An error message is returned if not a single accounting point is found using the retrieval criteria. In a response event, a list of accounting points plus their address data is returned. In a response, up to 50 accounting points may be delivered. If a retrieval finds more accounting points, the enquiry returns an error message and the retrieval criteria must be specified. Information field Level Necessity Comment Note Accounting point list Basic accounting point data Accounting point Accounting Point Status Connected Disconnected Under construction Removed from use

59 59 (214) Accounting point type Accounting point sub-type Consumption Production Production unit s own consumption Normal Building Accounting Point Remotely connectable Yes/No Meter number Active metering meter number [1] Related Accounting Point Identification Area Information Metering grid area name Metering grid area Metering grid area type Accounting point addresses n Type of address Main address Additional address Street name Building number Floor Room Postal code Post office Country ISO ID used. c/o Language ISO ID used. Coordinates Latitude Longitude Note Specification [1] Meter number can be used for identifying the accounting point.

60 60 (214) 3.9 DH-132 Accounting point and customer information request current supplier Event DH DH Note Message type F03 Message type description Sender Recipient Note [*] Accounting point data request Current supplier F21 Accounting point data Datahub Specification Datahub Current supplier The accounting point and contract are used as retrieval criteria in the retrieval. In the retrieval, accounting point data, agreement information and agreement customers are returned. FIGURE 10 DH-132 ACCOUNTING POINT AND CUSTOMER INFORMATION REQUEST CURRENT SUPPLIER In an enquiry, the following data is given: Information field Level Necessity Comment Note Accounting point data request

61 61 (214) Accounting point Sales agreement Note Specification In an enquiry event, no other event validations are made in addition to the necessities. An error message is returned if not a single accounting point is found using the retrieval criteria. In the retrieval of an enquiry, the following data is returned: Information field Level Necessity Comment Note Accounting point data response 1 1..n [1] Start of occurrence Date from which the data is reported. [2] Basic accounting point data Accounting point Accounting Point Status Accounting point type Accounting point sub-type Remotely connectable Connected Disconnected Under construction Removed from use Consumption Production Production unit s own consumption Normal Property accounting point Meter number Active metering meter number Related accounting point Area Information Metering grid area Grid agreement information Grid service product 3 1..n Grid agreement product

62 62 (214) Accounting point addresses 3 1..n See message type's general description (chapter 12) Coordinates See message type's general description (chapter 12) Accounting point characteristics See message type's general description (chapter 12) Controlled load 3 0..n Storage equipment 3 0..n See message type's general description (chapter 12) See message type's general description (chapter 12) Production equipment Sales agreement information Sales agreement customers 3 0..n n See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) Note [1] [2] Specification The retrieval may return more rows in a situation in which a fixed-term agreement is renewed using the same agreement number. If a supplier s agreement is valid at the moment of retrieval, data for the moment of the retrieval is returned. If a supplier s agreement has ended, data at the moment of ending is returned. If a supplier s agreement enters into force in the future, data for the moment that it enters into force is returned.

63 63 (214) 3.10 DH-133 Accounting point and customer information request new supplier Event Message type Message type description Sender Recipient Note [*] DH F03 Accounting point data request New supplier Datahub DH F21 Accounting point data Datahub New supplier Note Specification FIGURE 11 DH-133 ACCOUNTING POINT AND CUSTOMER INFORMATION REQUEST NEW SUPPLIER In a request, the accounting point and customer are used as retrieval criteria. The supplier should have authorisation from at least one customer to access the accounting point data. If there is no such authorisation, an error message is returned. In a retrieval, accounting point data, the contractual situation and customer information are returned. In an enquiry, the following data is given:

64 64 (214) Information field Level Necessity Comment Note Accounting point data request Accounting point Customer information Customer Note 1 1..n n [1] Specification [1] The enquiry contains all customers included in a new contract. In an enquiry event, no other event validations are made in addition to the necessities. An error message is returned if not a single accounting point is found using the retrieval criteria. In a retrieval, the following data is returned: Information field Level Necessity Comment Note Accounting point data response Start of occurrence Date from which the data is reported. [1] Basic accounting point data Accounting point Accounting Point Status Accounting point type Connected Disconnected Under construction Removed from use Consumption Production Production unit s own consumption Accounting point subtype Normal Property accounting point Remotely connectable Meter number Active metering meter number Related accounting point Area information Metering grid area

65 65 (214) Grid agreement information 3 1..n [2] Tax category Grid service product Grid agreement product [2] Accounting point addresses 3 1..n See message type's general description (chapter 12) Coordinates See message type's general description (chapter 12) Accounting point characteristics See message type's general description (chapter 12) [2] Controlled load 3 0..n Storage equipment 3 0..n Production device 3 0..n Agreement situation See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) [2] [2] [2] Beginning sales agreement Start date of following agreement event Sales agreement with the customer Agreement with the customer Agreement partially with the customer No agreement with the customer [3] Fixed-term sales agreement Yes/No [2] End date of fixed term This data is not returned if it ends within more than 90 days. [2] Valid sales agreement ends Notification previously received at the accounting point concerning the ending of the sales agreement. Special termination clause Yes/No [2] Notice days Exceptional notice period in days [2] Notice period [2] Start time of notice period End time of notice period [2] [2] Grid agreement with the customer Agreement with the customer Agreement partially with the customer No agreement with the customer [3]

66 66 (214) Customer information Individual fields described in chapter 12 [4] Note Specification [1] Data reported from the moment of retrieval. [2] Data is returned only if the customer has a valid agreement for the accounting point. [3] [4] The value is decided upon as follows: "Agreement fully with the customer", if exactly those customers that have a grid or sales agreement for the accounting point are entered into the retrieval. No agreement with the customer, if not a single reported customer has a grid or sales agreement. In other situations Agreement partially with the customer Data is returned for customers listed in the enquiry. Customer information is only returned if the supplier has the authority to access the customer information.

67 67 (214) 3.11 DH-134 Accounting point and customer information request DSO The accounting point data is retrieved using the accounting point ID. Event Message type Message type description Sender Recipient Note [*] DH F03 Accounting point data request DSO Datahub DH F21 Accounting point data Datahub DSO Note Specification FIGURE 12 DH-134 ACCOUNTING POINT AND CUSTOMER INFORMATION REQUEST DSO In an enquiry event, the following data is given: Information field Level Necessity Comment Note Accounting point data request Start of occurrence Accounting point

68 68 (214) Note Specification The following event validations are carried out for an enquiry: # Event validation 1 The accounting point is located in the metering grid area of the DSO. In a response event, data related to the accounting points is returned. Information field Level Necessity Comment Note Accounting point data response Start of Occurrence Date from which the data is reported. [1] Basic accounting point data Accounting point Accounting Point Status Accounting point type Accounting point sub-type Remotely connectable Connected Disconnected Under construction Removed from use Consumption Production Production unit s own consumption Normal Property accounting point Meter number Active metering meter number Related accounting point Area information Metering grid area Sales agreement information 3 0..n Sales product [2]

69 69 (214) Sales product Supplier information Supplier Accounting point addresses Sales agreement product ID [2] 3 1..n Coordinates Accounting point characteristics Controlled load 3 0..n Storage equipment 3 0..n Production device 3 0..n Grid agreement information Grid agreement customers Note 3 0..n 2 0..n Specification See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) [1] Information is returned according to the time shown on the enquiry. [2] Returned if the supplier has provided authorisation for the data

70 70 (214) 3.12 DH-135 Accounting point and customer information request 3rd party Accounting point data can be retrieved with the accounting point ID and customer information for the desired moment in time. Event Message type Message type description Sender Recipient Note [*] DH F03 Accounting point data request 3rd party Datahub DH F21 Accounting point data Datahub 3rd party Note Specification FIGURE 13 DH-135 ACCOUNTING POINT AND CUSTOMER INFORMATION REQUEST 3RD PARTY In an enquiry event, the following data is given: Information field Level Necessity Comment Note Accounting point data request Start of Occurrence Accounting point

71 71 (214) Customer information 2 1..n Customer Note Specification The following event validations are carried out for an enquiry: # Event validation 1 The party has been authorised by the customer to access the accounting point. In a response event, data related to the accounting point is returned. The third party must be authorised by the customer to access the accounting point data. Information field Level Necessity Comment Note Accounting point data response Start of Occurrence Date from which the data is reported. [1] Basic accounting point data Accounting point Accounting Point Status Accounting point type Accounting point sub-type Remotely connectable Connected Disconnected Under construction Removed from use Consumption Production Production unit s own consumption Normal Property accounting point Meter number Active metering meter number Related accounting point Grid agreement information n Tax category

72 72 (214) Grid service product data Grid service product Area information Metering grid area Accounting point addresses Grid agreement product 3 1..n Coordinates Accounting point characteristics Controlled load 3 0..n Storage equipment 3 0..n Production device 3 0..n Customer information Note 2 1..n Specification See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) [1] Data is reported for the reporting time presented in the enquiry. [2] Only returned from customers that have authorised the third party and have been entered for the retrieval. [2]

73 73 (214) 4 DH-200 Metering data maintenance processes FIGURE 14 METERING EVENTS 4.1 DH-211 Metering data report The hourly metering data from a metering point is reported to Datahub by the DSO or the service provider. Datahub forwards the metering data to the valid supplier and to third parties who are authorised to access the metering data. A supplier that is authorised to access an accounting point or has an agreement may retrieve data through a metering data retrieval. In a metering data event, E66 message content will be applied, which is also used in production reporting metered for NBS. (NEG (ebix based) Validated Data for Settlement for Aggregator (E66)). By default, metering data is delivered in 24-hour periods (official Finnish 24-hour period). In special and error correction situations, the reporting period may, however, be longer or shorter. In an event, a complete timeline with time series values for the whole reporting period must always be delivered. For each position, either value or value missing data is presented for the reporting period. Event Message type Message type description DH E66 Metering data Sender Recipient Note [*] Metering responsible party Datahub DH E66 Metering data Datahub Supplier DH E66 Metering data Datahub 3rd party

74 74 (214) FIGURE 15 DH-211 METERING DATA REPORT Information field Level Necessity Comment Note Metering time series Time series Message creation time [1] Reporting period Time step Start time End time Metering type Metering time series type Consumption Production Reactive energy output Reactive energy input Connection point transmission

75 75 (214) Unit Metering charasteristics Metering point type Accounting point Production unit Exchange point Metering point Metering point Area information Metering grid area Not used for connection point metering Output area Output area Only used for connection point metering Input area Input area Only used for connection point metering Time series values Position Values Value [2] Value missing Yes/No [3] Status Uncertain Estimated Corrected OK [3] Note [1] [2] [3] Specification Time series data is linked to the metering point based on metering point. Time series is the used by the reporting system and it can be used for handling possible error situations. Either value or value missing data is presented. Values must always be positive. For exchange points, both transmission directions are reported separately. Status is presented if other than metered. (136=OK) (Missing), not presented, only expressed as value missing in the field. Uncertain Estimated Corrected OK

76 76 (214) The following event validations are carried out for payload. Datahub rejects message data by metering time series. A whole message is not rejected if it includes even one error, only the metering time series that contain errors are rejected. # Event validation 1 Metering point found in the system 2 The party (DSO or 3rd party) is entitled to supply metering data to the metering grid area. 3 Metering data resolution is correct (at present one hour, in future, possibly 15 minutes or 5 minutes). 4 Reported time period is not in the future or more than six years in the past 5 Time series includes value (or value missing data) for each reporting period position 6 If the metering point is an exchange point or a production unit, metering data cannot be corrected outside the balance window.

77 77 (214) 4.2 DH-221, DH-222, DH-223 Metering data requests Metering data may be retrieved by the supplier, third party or distribution system operator. Event Message type Message type description Sender Recipient Note [*] DH Supplier DH DH F08 Metering data request DSO 3rd party Datahub DH DH DH E66 Metering data Datahub Supplier DSO 3rd party

78 78 (214) FIGURE 16 DH-220 METERING DATA REQUEST In a query event, the following data is given:

79 79 (214) Information field Level Necessity Comment Note Metering data request Metering point In the same enquiry, several accounting points may be retrieved [1] Metering grid area [1] Accounting point type Time step If no type is given, both consumption and production accounting points' data is returned Unit of Active Power [2] Unit of Reactive Power [2] Request period Start time End time Note [1] [2] Specification A retrieval may be carried out either for all metering points based on metering grid area or for an individual metering point. Active and reactive energy meterings may be retrieved in a specified unit. If no unit is given in the request, the corresponding active or reactive power is not returned. At least one of the units must be given for datahub to return any data.. If the metering is retrieved with greater resolution than Datahub s storage resolution, the weakest status within the time step is set as the status of the value. If metering is retrieved at lower resolution than Datahub s recording resolution, the metering is returned at the storage resolution. The following event validations are carried out for an enquiry: # Event validation 1 Enquiry period is up to one year. 2 Enquiry period is not in the future or more than six years in the past. 3 The time step is at least as great as the time step with which the metering is stored in Datahub. 4 The unit of enquiry is a unit of energy. A response event includes the same data as DH-211 (Metering data). Metering data is only delivered for a time period the data of which the party is authorised to access. Parties rights to data

80 80 (214) are described in document "Electricity retail market business processes in datahub", chapter 2.2. In a response event, all meterings recorded at the accounting point are delivered (also reactive meterings if they have been delivered to Datahub). A response event for metering data is returned asynchronously. When retrieving a large volume of metering data, the formation of a response event may, if necessary, be delayed in Datahub if the resource situation of the system so requires.

81 81 (214) 4.3 DH-212 Reminder of metering data report Datahub reports incorrect or unreported metering data to the distribution system operator. Event DH-212 Message type Message type description Sender Recipient Note [*] F07 Metering data reminder Datahub Metering responsible party FIGURE 17 DH-212 REMINDER OF METERING DATA REPORT Information field Level Necessity Comment Note Metering data reminder Metering point Metering grid area Request period Start time End time Note [1] Specification Accounting point, production unit or connection point The time period of the first and last missing value is given as the time period. Datahub carries out an examination of a certain time period (e.g. an open balance window). In that case, a request period may be either a whole open balance window or the period of the first and last missing value. [1]

82 82 (214) 5 DH-300 Contract processes FIGURE 18 CONTRACT EVENTS

83 83 (214) 5.1 DH-311 Notification of a new contract The supplier supplies the information about a new sales agreement to Datahub. Datahub delivers the new sales agreement information to the DSO. Datahub delivers the sales agreement ending notification to the current supplier of the accounting point. Event Message type Message type description Sender Recipient Note [*] DH F04 Structural data, agreement New supplier Current supplier Datahub DH F04 Structural data, agreement Datahub DSO DH F06 Structural data, agreement ending Datahub Current supplier DH F06 Structural data, agreement ending Datahub Production accounting point supplier DH F18 Structural data, agreement cancellation Datahub Future supplier DH DH F01 Structural data, customer Datahub Supplier DSO 3rd party DH E66 Metering data Datahub DSO Note Specification [*]

84 84 (214) FIGURE 19 DH-311 NOTIFICATION OF A NEW CONTRACT

85 85 (214) DH New contract information Message payload includes the following information: Information field Level Necessity Comment Note New agreement information Start of Occurrence Contract start date Agreement information Contact method Electronic Other Agreement Agreement type Sales agreement Delivery contractt Yes/No Fixed-term agreement End date of fixed term Yes/No Invoicing method Separate invoicing, Grid invoices both Supplier invoices both [5] Special termination clause Yes/No Notice days Special termination period in days [1] Notice period [1] Start of Occurrence [1] End of Occurrence [1] Interruption Critical Yes/No Invoicing channel Paper invoice Electronic invoice E-Invoice Netposti Direct debit Mobile invoice Other invoicing channel [4] Tax category ,1,2

86 86 (214) Product data 3 0..n Product code Sales agreement product Customer specifier Contact person 3 0..n Type Trustee Responsible for agreements Responsible for invoicing Responsible for connections Fault communication Given name Family name Other name Contact information Type Telephone address Telephone number/ address Postal invoicing address [2] [7] c/o Address specifier Street name Building number Floor Room Postal code PO Box Post office Country ISO code used in accordance with alpha-2 Electronic invoicing address [3] Buyer reference Electronic invoicing address Mediator

87 87 (214) Other invoicing address [6] Type Electronic address Accounting point data Accounting point Area information Metering grid area Supplier information Supplier Basic customer information Customer Customer type n Either business ID, association ID, personal identity number or party's own customer is used. Business ID Association ID Personal identity number Party s own Customer type Customer sub-type Company Consumer Normal Estate of a deceased person Information restriction Yes/No. Language ISO ID used. Company name Compulsory for business customer Given name Compulsory for consumer customer Middle names Family name Compulsory for consumer customer Date of birth Compulsory for consumer customer, if no personal identity number has been given YYYY-MM-DD Additional Contact information

88 88 (214) Type Telephone address Telephone number address Postal address [2] c/o Address specifier Street name Building number Floor Room Postal code PO Box Post office Country ISO ID used in accordance with alpha- 2 Note [1] [2] Specification If an agreement has a special termination clause, either the notice period in days or the entire notice period must be specified in the agreement. The notice period specifies the time period during which the agreement may be terminated. If a notice period is used, the supplier must ensure that it is updated in the agreement. In the address information, either the street name and building number, or the PO Box number must be given in addition to the postal code. [3] Must be given if the invoicing channel is invoice. [4] [5] The consumer s e-invoicing address is not entered into Datahub. E-invoice or direct debit may, however, be marked as the invoicing channel. Then the postal invoicing address is compulsory. In case of an electricity delivery agreement, the invoicing method should be Supplier invoices both. [6] Obligatory, if invoicing channel is mobile invoice or . [7] Obligatory, if invoicing channel is paper invoice, e-invoice, netposti, direct debit or other invoicing channel. The following event validations are carried out for payload: # Event validation 1 In the addresses, the post office is correct based on the postal code. This check is made only for Finnish addresses. 3 If the contact method is electronic, the contact information must include an address 3 The Start of Occurrence is in accordance with the business process specifications.

89 89 (214) 4 The accounting point can be found in the system and its status is other than removed from use. 5 6 The sales agreement for a accounting point does not have valid exceptional termination terms. A check is not carried out if the customer of an accounting point changes. If an accounting point has a valid fixed-term sales agreement, the start time of the new agreement may not be earlier than the end date of the fixed term agreement. A check is not carried out if the customer of an accounting point changes. 7 No other sales agreement for the same start date is registered for the accounting point. If the new sales agreement enters into force retrospectively (the Start of occurrencies earlier than the current day), the agreement is accepted but is not activated in Datahub. The agreement is only activated once the new supplier has confirmed it and the old supplier has approved it. Confirmation and acceptance of the agreement are done manually using the online service DH New contract information forward to DSO Information field Level Necessity Comment Note New contract information Start of Occurrence Original message Original message sender Requires new grid agreement Only used in a forwarded message [1] Only used in a forwarded message Yes/No Reason for starting agreement Agreement change Switching suppliers Moving in Contract information Contact method Electronic Other Contract Contract type Sales agreement Delivery contract Yes/No Contract start date Invoicing method Separate invoicing, Grid invoices both Supplier invoices both

90 90 (214) Interruption Critical Yes/No Invoicing channel Paper invoice Electronic invoicing E-Invoice Netposti Direct debit Mobile invoice Other invoicing channel Tax category ,1,2 Customer note Contact person 3 0..n Contact information See message type's general description (chapter 12) See message type's general description (chapter 12) Postal invoicing address Electronic invoicing address Other invoicing address Accounting point data See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) Accounting point ID Area information Metering grid area Supplier information Supplier ID Basic customer information 3 1..n See message type's general description (chapter 12) Postal address See message type's general description (chapter 12) [2] Note [1] Specification Datahub forwards the ID of the original message from the supplier with the forwarded message in this field.

91 91 (214) DH Notification to current supplier of contract end Datahub notifies the current supplier of the end of the sales agreement. The notification uses the same content as in the normal ending of a sales agreement. The message gives information about the agreement that is ending DH Notification of moving out to the supplier of a production accounting point Datahub notifies the production accounting point supplier of the end of the production accounting point agreement. The notification uses the same content as in the normal ending of a sales agreement. The message gives information about the production accounting point agreement DH Notification of sales agreement cancellation to the future supplier When a new customer is moving in, datahub notifies the future supplier of the accounting about the cancellation of their sales agreement, which is not of the customer moving in and which would take effect in the future. Notification is done using sales agreement cancellation message with a reason "Customer's cancellation" DH DH Customer information update forward Datahub notifies all parties authorised to customer information is the customer information changes when a new agreement is reported. Notification is done like all other customer information update forwards in event DH DH Zeroing of consumption registered in losses Datahub notifies zero time series to a DSO, if a retrospective move-in is reported to an accounting point without a supplier. Based on the notification, DSO can zero out the consumption registered in losses in their system they have earlier retrieved with event DH-523. Notification is done similar to event DH-523.

92 92 (214) 5.2 DH-312 Grid agreement confirmation The distribution sytem operator delivers the grid agreement confirmation information to Datahub. Datahub delivers the confirmation information to the valid and new supplier of the accounting point. Event DH DH Note Message type F04 F04 Specification Message type description Structural data, agreement Structural data, agreement Sender Recipient Note [*] DSO Datahub [1] Grid agreement confirmation information forwarded to the supplier. Datahub New supplier Current supplier [1] FIGURE 20 DH-312 GRID AGREEMENT CONFIRMATION Message payload includes the following information: Information field Level Necessity Comment Note Contract data Start of Occurrence

93 93 (214) Original message Original message sender Grid agreement acceptance Only used in a forwarded message Only used in a forwarded message Yes/No [1] Description Description for rejection of agreement Contract information [3] Contact method Electronic Other Contract Contract type Grid agreement Contract start date Invoicing method Separate invoicing Grid invoices both Supplier invoices both Interruption Critical Yes/No Invoicing channel Paper invoice Electronic invoicing E-Invoice Netposti Direct debit Mobile invoice Other invoicing channel Tax category ,1,2 Customer note Product data 3 0..n Product code Grid agreement product ID Contact person 3 0..n Type Guardian Responsible for agreements Responsible for invoicing Responsible for connections Fault communication Given name Family name Other name

94 94 (214) Contact information Type Telephone address Telephone number/ address Postal invoicing address [2] [4] c/o c/o Street name Building number Floor Room Postal code PO Box Post office Country ISO code used in accordance with alpha-2 Electronic invoicing address [5] Buyer reference Electronic invoicing address Mediator Other invoicing address [6] Type Electronic address Accounting point data Accounting point Area information Metering grid area Note [1] [2] Specification If the DSO does not accept the grid agreement, a rejection message is returned. In such a case, agreement information is not included in the message. In the address information, either the street name and building number, or the PO Box number must be given in addition to the postal code.

95 95 (214) [3] Contract information must be reported if grid agreement is accepted. [4] Obligatory, if invoicing channel is paper invoice, e-invoice, netposti, direct debit or other invoicing channel. [5] Obligatory, if invoicing channel is electronic invoicing. [6] Obligatory, if invoicing channel is mobile invoice or . The following event validations are carried out for payload: # Event validation 1 In the addresses, the post office is correct based on the postal code. This check is made only for Finnish addresses. 2 The accounting point can be found in the system and its status is other than removed from use. 3 Accounting point metering grid area belongs to DSO. 4 Sales agreement given for accounting point has not been cancelled.

96 96 (214) 5.3 DH-321 Sales agreement information update Sales agreement information updates are carried out in Datahub by the supplier. Datahub forwards the updated agreement information to the DSO. Event DH DH Note Message type F04 F04 Specification Message type description Structural data, agreement Structural data, agreement Sender Recipient Note [*] Current supplier [1] Changed sales agreement information is forwarded to the DSO. Datahub Datahub DSO [1] FIGURE 21 DH-321 SALES AGREEMENT INFORMATION UPDATE Message payload includes the following information: Information field Level Necessity Comment Note Contract information Start of Occurrence

97 97 (214) Original Business Document Reference Original Business Document Sender Only used in a forwarded message Only used in a forwarded message Contract information Contract Contract type Sales agreement Contact method Electronic Other Fixed-term agreement End date of fixed term Yes/No Invoicing method Separate invoicing Grid invoices both Supplier invoices both Special termination clause Yes/No Notice days Special termination period in days Termination Notice period Start time of notice period End time of notice period Interruption Critical Yes/No Invoicing channel Paper invoice Electronic invoicing E-Invoice Netposti Direct debit Mobile invoice Customer note Product data 3 0..n Product code Contact person 3 0..n See message type's general description (chapter 12)

98 98 (214) Contact information Postal invoicing address Electronic invoicing address Other invoicing address Accounting point data Accounting point Note [1] Specification See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) See message type's general description (chapter 12) Obligatory, if invoicing channel is paper invoice, e-invoice, netposti, direct debit or other invoicing channel. [2] Obligatory, if invoicing channel is electronic invoicing. [3] Obligatory, if invoicing channel is mobile invoice or . [1] [2] [3] In an update event, all payload is delivered, not only changed data. The following event validations are carried out for payload. # Event validation 1 In the addresses, the post office is correct based on the postal code. This check is made only for Finnish addresses. 2 Sales agreement found in the system. 3 If the contact method is electronic, the contact information must include an address 4 The start of occurrence is in accordance with the business process specifications.

99 99 (214) 5.4 DH-322 Grid agreement information update Grid agreement information updates are carried out in Datahub by the DSO. Datahub forwards the updated agreement information to the valid and possible new supplier of the accounting point. Event DH DH Note Message type F04 F04 Specification Message type description Structural data, agreement Structural data, agreement Sender Recipient Note [*] DSO [1] Changed grid agreement information is forwarded to the supplier. Datahub Datahub Current supplier [1] FIGURE 22 DH-322 GRID AGREEMENT INFORMATION UPDATE Messages payload includes the same data as event DH-312. In an update event, all the agreement information is delivered, not only the information that has changed. The following event validations are carried out for payload. # Event validation

100 100 (214) 1 In the addresses, the post office is correct based on the postal code. This check is made only for Finnish addresses. 2 Grid agreement found in the system

101 101 (214) 5.5 DH-323 Notification of accounting pointan accounting point without a supplier Datahub forwards a list of accounting points without suppliers to the distribution system operator. The check is run daily and, in the event, accounting points are reported whose agreements are expiring within 14 days and no new suppliers have been registered for those accounting points. Event DH-323 Note Message type F05 Specification Message type description Accounting point without supplier Sender Recipient Note [*] Datahub DSO FIGURE 23 DH-323 NOTIFICATION OF ACCOUNTING POINTS WITHOUT SUPPLIERS Message payload includes the following information: Information field Level Necessity Comment Note Accounting point data Accounting point 1 1..n Area information Metering grid area Time without an agreement Start time

102 102 (214) End time Note Specification

103 103 (214) 5.6 DH-331 Notification of sales agreement end The supplier reports the ending of a sales agreement to Datahub. Datahub forwards the information to the DSO if the accounting point has a valid grid agreement. Event DH DH DH DH DH Note Message type F06 F06 F06 F06 F18 Specification Message type description Structural data, agreement ending Structural data, agreement ending Structural data, agreement ending Structural data, agreement ending Structural data, agreement cancellation Sender Recipient Note [*] Current supplier Datahub Datahub DSO [1] Datahub [1] Notification of the ending of sales agreement forwarded to the DSO. [2] [3] [4] Production accounting point supplier [2] Datahub 3rd party [3] Datahub Future supplier [4] If the accounting point has a related accounting point for production, notification of the ending of the agreement is forwarded to the production accounting point supplier (buyer of electricity) in a moving out situation. The of the ending sales agreement is not forwarded. Datahub notifies 3rd party about customer's sales agreement ending on the accounting point. Authorisation, however, is not cancelled or terminated so that historical data can be retrieved after agreement has ended. When a customer moves out, datahub notifies the future supplier of the accounting point about the cancellation of their sales agreement, unless their upcoming sales agreement is a move-in.

104 104 (214) FIGURE 24 DH NOTIFICATION OF SALES AGREEMENT END Message payload includes the following information: Information field Level Necessity Comment Note Contract information End date Original message Original message sender Only used in a forwarded message [1] Only used in a forwarded message [1] Reason Moving out Termination Dissolving [2]

105 105 (214) Contract information Contract Contract type Postal invoicing address Compulsory in an original message, not forwarded in a forwarded message. Compulsory in an original message, not forwarded in a forwarded message [3] c/o c/o Street name Building number Floor Room Postal code PO Box Post office Country Accounting point data Accounting point Note [1] [2] [3] Specification ISO code used in accordance with alpha-2 Datahub forwards the of the original message from the supplier with the forwarded message in this field. Agreement terminations (termination by the customer or supplier) is done using an agreement termination message. The termination message gives the reason for the termination and information as to whether or not it was done by the customer. In the address information, either the street name and building number, or the PO Box number must be given in addition to the postal code. The customer s new address is the postal invoicing address, for example, the address to which the final invoice will be sent. The following event validations are carried out for payload. # Event validation 1 In the addresses, the post office is correct based on the postal code. This check is made only for Finnish addresses. 2 Valid sales agreement found in the system. 3 The date of ending is in accordance with the business process specifications.

106 106 (214) 5.7 DH-332 Notification of Customer Moving Out by New Supplier The customer s new supplier informs the DSO about the customer s moving out from the customer s current accounting point. Datahub forwards the notification to the DSO. Event DH DH Note Message type F06 F06 Specification Message type description Structural data, agreement ending Structural data, agreement ending [1] Notification of moving out forwarded to the DSO. Sender Recipient Note [*] New supplier Datahub Datahub DSO [1] FIGURE 25 DH-332 NOTIFICATION OF CUSTOMER MOVING OUT BY NEW SUPPLIER Message payload includes the following information: Information field Level Necessity Comment Note Contract information End of occurrence Date of moving out

107 107 (214) Original message Only used in a forwarded message [1] Original message sender Only used in a forwarded message [1] Reason Moving out Accounting point data Accounting point Basic customer information 2 1..n Customer Customer type Either business ID, association ID, personal identity number or party's own customer is used. Business ID Association ID Personal identity number Party s own Company name Compulsory for business customer Given name [2] Middle names [2] Family name [2] Date of birth [2] Postal invoicing address [3] c/o c/o Street name Building number Floor Room Postal code PO Box Post office Country ISO code used in accordance with alpha-2 Note [1] [2] Specification Datahub forwards the of the original message from the supplier with the forwarded message in this field. The fields are used to specify the customer if the customer (personal identity number) is not given in the message.

108 108 (214) [3] In the address information, either the street name and building number, or the PO Box number must be given in addition to the postal code. The customer s new address is the postal invoicing address, for example, the address to which the final invoice will be sent. The following event validations are carried out for payload. # Event validation 1 2 In the addresses, the city name is correct based on the postal code. This check is made only for Finnish addresses. The customer has a valid sales and grid agreement for the accounting point in the system. 3 The End of occurrence is in accordance with the business process specifications.

109 109 (214) 5.8 DH-333 Notification of grid agreement end The DSO informs Datahub about the ending of the grid agreement. Datahub forwards the information to the supplier with a valid sales agreement for the accounting point. Event DH DH Note Message type F06 F06 Specification Message type description Structural data, agreement ending Structural data, agreement ending Sender Recipient Note [*] DSO Datahub Datahub Current supplier [1] [1] Notification of ending of grid agreement forwarded to the current supplier. FIGURE 26 DH-333 NOTIFICATION OF GRID AGREEMENT END Message payload includes the following information:

110 110 (214) Information field Level Necessity Comment Note Contract information End of occurrence Original message Only used in a forwarded message [1] Original message sender Only used in a forwarded message [1] Reason Moving out Termination Dissolving Contract information Contract Identification Contract type Grid agreement Postal invoicing address [2] [3] c/o c/o Street name Building number Floor Room Postal code PO Box Post office Country ISO code used in accordance with alpha-2 Accounting point data Accounting point Note [1] [2] [3] Specification Datahub forwards the of the original message from the grid company with the forwarded message in this field. In the address information, either the street name and building number, or the PO Box number must be given in addition to the postal code. The customer s new address is the postal invoicing address, for example, the address to which the final invoice will be forwarded. The following event validations are carried out for payload. # Event validation 1 Valid grid agreement found in the system.

111 111 (214) 2 The End of occurrence is in accordance with the business process specifications.

112 112 (214) 5.9 DH-340 Contract cancellation The general cancellation message (E67) is not used to cancel agreements. Dedicated messages have been specified for cancellation events DH-341 Notification of sales agreement cancellation The supplier reports the cancellation of a sales agreement to Datahub. Datahub forwards the information to the DSO and the previous supplier. Event Message type Message type description Sender Recipient Note [*] DH F18 Structural data, agreement cancellation Current supplier New supplier Datahub DH F18 Structural data, agreement cancellation Datahub DSO [1] DH F18 Structural data, agreement cancellation Datahub Previous supplier Current supplier [2] Note Specification [1] Notification of the cancellation of sales agreement forwarded to the DSO. [2] Notification of the cancellation of sales agreement forwarded to previous supplier.

113 113 (214) FIGURE 27 DH-341 NOTIFICATION OF SALES AGREEMENT CANCELLATION Message payload includes the following information: Information field Level Necessity Comment Note Contract information Start of Occurrence Start date of cancelled agreement. Original message Only used in a forwarded message Original message sender Only used in a forwarded message Reason for cancellation Agreement cancelled by the customer Agreement cancelled by the supplier Description Contract information Contract Identification for rescinded agreement forwarded to previous/current supplier Accounting point data

114 114 (214) Accounting point Note Specification DH-342 Notification of grid agreement cancellation The DSO informs Datahub of the cancellation of a grid agreement. Datahub forwards the information to the current supplier. Event Message type Message type description Sender Recipient Note [*] DH F18 Structural data, agreement cancellation DSO Datahub DH F18 Structural data, agreement cancellation Datahub Current supplier New supplier [1] Note [1] Specification Notification about cancellation of sales agreement forwarded to new or current supplier, to the supplier to which the original confirmation was delivered. FIGURE 28 DH-342 NOTIFICATION OF GRID AGREEMENT CANCELLATION

115 115 (214) Message payload includes the following information: Information field Level Necessity Comment Note Contract information Start of Occurrence Start date of cancelled agreement. Original message Only used in a forwarded message Original message sender Only used in a forwarded message Reason for cancellation Agreement cancelled by the customer Agreement cancelled by the supplier Description Contract information Contract Accounting point data Accounting point Note Specification DH-343 Notification of refusal of sales agreement restore by former supplier When a new supplier cancels a sales agreement, the accounting point is returned to the sales of the previous supplier. If the previous supplier does not wish to continue the agreement, the supplier forwards a notification of agreement termination. The message content is the same as in the normal ending of a sales contract DH-331. Event Message type Message type description Sender Recipient Note [*] DH F06 Structural data, agreement ending Current supplier Datahub DH F06 Structural data, agreement ending Datahub DSO [1] Note Specification [1] Notification of the ending of sales agreement forwarded to the DSO.

116 116 (214) FIGURE 29 DH-343 NOTIFICATION OF REFUSAL OF SALES AGREEMENT RESTORE BY FORMER SUPPLIER DH-344 Notification of grid agreement end in the case of cancellation When the supplier ends a sales contract (DH-343), if necessary, the DSO terminates the grid agreement. The message content is the same as for the normal ending of a grid agreement DH Event DH DH Note [1] Message type F06 F06 Specification Message type description Structural data, agreement ending Structural data, agreement ending Sender Recipient Note [*] DSO Datahub Datahub New supplier [1] Notification of ending of grid agreement forwarded to the new supplier, which terminated the sales agreement.

117 117 (214) FIGURE 30 DH-344 NOTIFICATION OF GRID AGREEMENT END IN THE CASE OF CANCELLATION

118 118 (214) 6 DH-400 Connection and disconnection processes FIGURE 31 CONNECTION AND DISCONNECTION EVENTS 6.1 DH-411 Supply connection request The supplier relays the connection request event to Datahub. Datahub forwards the request to the DSO. Event DH DH Note Message type F09 F09 Specification Message type description Connection - disconnection Connection - disconnection [1] Connection request forwarded to the DSO. Sender Recipient Note [*] Supplier Datahub Datahub DSO [1]

119 119 (214) FIGURE 32 DH-411 SUPPLY CONNECTION REQUEST Message payload includes the following information: Information field Level Necessity Comment Note Connection - disconnectin Date of connection Original message Original message sender Accounting point Only used in a forwarded message Only used in a forwarded message Connection status Connection request Contact person 2 1..n Type Given name Family name Other name Contact information Responsible for connections Type Telephone

120 120 (214) Telephone number/ address Telephone number must be reported The following event validations are carried out for payload. # Event validation 1 The supplier has a valid sales agreement both at the moment of request and on the date of connection. 2 The date of connection is not in the past. 3 The accounting point is found in the system and its status is not "removed from use".

121 121 (214) 6.2 DH-412 Notification of supply connection The distribution grid owner reports the connection notification to Datahub. Datahub forwards the notification to the supplier with a valid sales agreement for the accounting point. Event DH DH Note Message type F09 F09 Specification Message type description Connection - disconnection Connection - disconnection [1] Connection notification forwarded to supplier. Sender Recipient Note [*] DSO Datahub Datahub Supplier [1] FIGURE 33 DH-412 NOTIFICATION OF SUPPLY CONNECTION Message payload includes the following information:

122 122 (214) Information field Level Necessity Comment Note Connection - disconnection Moment of connection Original message Original message sender Accounting point Connection status Connected Only used in a forwarded message Only used in a forwarded message The following event validations are carried out for payload. # Event validation 1 The accounting point is in the metering grid area of the distribution grid. 2 The accounting point is found in the system and its status is not "removed from use".

123 123 (214) 6.3 DH-421 Supply disconnection request The supplier sends the disconnection request event to Datahub. Datahub forwards the request to the DSO. Event DH DH Note Message type F09 F09 Specification Message type description Connection - disconnection Connection - disconnection [1] Disconnection request forwarded to the DSO. Sender Recipient Note [*] Supplier Datahub Datahub DSO [1] FIGURE 34 DH-421 SUPPLY DISCONNECTION REQUEST Message payload includes the following information: Information field Level Necessity Comment Note Connection - disconnection

124 124 (214) Date of disconnection Original message Original message sender Accounting point Only used in a forwarded message Only used in a forwarded message Connection status Disconnection request The following event validations are carried out for payload. # Event validation 1 The supplier has a valid sales agreement both at the moment of request and on the date of disconnection. 2 The date of disconnection must be at least one week in the future. 3 The accounting point is found in the system and its status is not "removed from use".

125 125 (214) 6.4 DH-422 Notification of supply disconnection The DSO reports the disconnection notification to Datahub. Datahub forwards the notification to the supplier with a valid sales agreement for the accounting point. Event DH DH Note Message type F09 F09 Specification Message type description Connection - disconnection Connection - disconnection Sender Recipient Note [*] DSO Datahub Datahub Supplier [1] [1] Disconnection notification forwarded to supplier and/or possible 3rd party. FIGURE 35 DH-422 NOTIFICATION OF SUPPLY DISCONNECTION Message payload includes the following information:

126 126 (214) Information field Level Necessity Comment Note Connection - disconnection Moment of disconnection Original message Original message sender Accounting point Only used in a forwarded message Only used in a forwarded message Connection status Disconnected The following event validations are carried out for payload. # Event validation 1 The accounting point is in the metering grid area of the distribution grid. 2 The accounting point is found in the system and its status is not "removed from use".

127 127 (214) 6.5 DH-413, DH-423 Notification of connection or disconnection delay The distribution grid owner reports the notification of delay to Datahub. Datahub forwards the notification to the supplier with a valid sales agreement for the accounting point. Event Message type Message type description Sender Recipient Note [*] DH DH F09 Connection - disconnection DSO Datahub DH DH F09 Connection - disconnection Datahub Supplier [1] Note Specification [1] Notification of delay sent to supplier. FIGURE 36 DH-413 NOTIFICATION OF CONNECTION DELAY Message payload includes the following information:

128 128 (214) Information field Level Necessity Comment Note Connection - disconnection At the earliest Original message Original message sender Accounting point Requested connection status Earliest moment for connection/disconnection Only used in a forwarded message Only used in a forwarded message Description Status reported, which supplier has requested. Description for disconnection delay The following event validations are carried out for payload. # Event validation 1 The accounting point is in the metering grid area of the distribution grid. 2 Accounting point is found in the system.

129 129 (214) 7 DH-500 Imbalance settlement FIGURE 37 IMBALANCE SETTLEMENT EVENTS Datahub performs imbalance settlement calculations for DSOs and delivers the imbalance settlement data to esett. The relaying of data takes place in accordance with NBS specifications, so events DH-511 DH-513 are not described in this document. esett delivers DSO balance discrepancy data to Datahub and Datahub forwards it to the DSOs and suppliers. Event DH-512 also observes NBS specifications, so it is not described in this document.

130 130 (214) 7.1 DH-514, DH-522 Distribution system owner's imbalance settlement data Imbalance settlement data is sent to the DSO, once the balance discrepancy data is received from esett. The DSO can also retrieve imbalance settlement data for its metering grid areas from Datahub. Data can be retrieved supplier-specifically or as the total sum of the metering grid area. All imbalance settlement series are delivered in the return. Event Message type Message type description Sender Recipient Note [*] DH-514 E31 Imbalance settlement data Datahub DSO DH F10 Imbalance settlement data request DSO Datahub DH E31 Imbalance settlement data Datahub DSO FIGURE 38 DH-514 IMBALANCE SETTLEMENT DATA REPORT TO DSO

131 131 (214) FIGURE 39 DH-522 IMBALANCE SETTLEMENT DATA REQUEST DSO In an enquiry event, the following data is given: Information field Level Necessity Comment Note Time series request Metering grid area Supplier [1] Data corrected outside the balance window

132 132 (214) Request period Start time End time Note Specification [1] If no supplier ID is given, the total sum of the metering grid area is returned. The following time series data is returned in imbalance settlement data and response events: Information field Level Necessity Comment Note Total time series Time series Message creation time Reporting period Time step Start time End time Total series type Product type Active energy Unit Time series characteristics Type of time series Consumption Production Connection point Imbalance settlement method Profile imbalance settlement Hourly imbalance settlement Balance settlement type See additional comment [1] Supplier Supplier Area information Metering grid area Input area

133 133 (214) Input area Output area Output area Time series values Position Values Value Status Note [1] Specification Small-scale production Imbalance Exchange point sum Total exchange point sum Production unit's production Own consumption Losses Sum delivery The following event validations are carried out for payload. # Event validation 1 Metering grid area belongs to DSO

134 134 (214) 7.2 DH-515, DH-521 Supplier s imbalance settlement data Imbalance settlement data is sent to the DSO, once the balance discrepancy information is received from esett. A supplier may retrieve supplier-specific metering grid area total data from Datahub. Event Message type Message type description Sender Recipient Note [*] DH-515 E31 Imbalance settlement data Datahub Supplier DH F10 Imbalance settlement data request Supplier Datahub DH E31 Imbalance settlement data Datahub Supplier [1] FIGURE 40 DH-515 IMBALANCE SETTLEMENT DATA REPORT TO SUPPLIER

135 135 (214) FIGURE 41 DH-521 IMBALANCE SETTLEMENT DATA REQUEST SUPPLIER In an enquiry event, the following data is given: Information field Level Necessity Comment Note Time series request Metering grid area Data corrected outside the balance window Request period

136 136 (214) Start time End time In an enquiry event, no other event validations are made in addition to the necessities. An error message is returned if not a single total series is found using the retrieval criteria. The following time series data is returned in imbalance settlement data and response events: Information field Level Necessity Comment Note Total time series Time series Message creation time Reporting period Time step Start time End time Total series type Product type Active energy Unit Time series characteristics Type of time series Consumption Production Imbalance settlement method Profile imbalance settlement Hourly imbalance settlement Balance settlement type See additional comment [1] Supplier Supplier Area information Metering grid area Time series values Position Values Value

137 137 (214) Status Note [1] Specification Small-scale production Imbalance Exchange point sum Total exchange point sum Production unit's production Own consumption Losses Sum delivery

138 138 (214) 7.3 DH-523 Consumption and production data registered in losses DSO can request data about their losses from datahub. Event Message type Message type description Sender Recipient Note [*] DH F08 Metering data request DSO Datahub [1] DH E66 Metering data Datahub DSO [1] Note Specification [1] Information on losses is retrieved by metering grid area through the metering data request. FIGURE 42 DH-523 CONSUMPTION AND PRODUCTION DATA REGISTERED IN LOSSES REQUEST

139 139 (214) In an enquiry event, the following data is given: Information field Level Necessity Comment Note Metering data request Metering grid area [1] Request period Start time End time The following event validations are carried out for an enquiry: # Event validation 1 Enquiry period is up to one year. 2 Enquiry period is not in the future or more than six years in the past. The following data is returned as the answer: Information field Level Necessity Comment Note Metering time series Time series Message creation time [1] Reporting period Time step Start time End time Metering type Metering time series type Consumption Production Unit Metering charasteristics Metering point type Accounting point Metering point

140 140 (214) Metering point Area information Metering grid area Time series values Position Values Value [2] Value missing Yes/No [3] Status Uncertain Estimated Corrected OK [3] Note [1] Specification Time series data is linked to the metering point based on metering point. Time series is the used by the system that reports the accounting point metering data and it can be used for handling possible error situations. [2] Either value or value missing data is presented. [3] Status is presented if other than metered. (136=OK) (Missing), not presented, only expressed as value missing in the field. Uncertain Estimated Corrected OK

141 141 (214) 8 DH-600 Balance Deviation correction FIGURE 43 BALANCE DEVIATION EVENTS Datahub forwards balance error calculation results to the DSOs and suppliers. Event Message type Message type description Sender Recipient Note [*] DH-611 F19 Balance deviation data Datahub Supplier DH-612 F19 Balance deviation data Datahub DSO FIGURE 44 DH-611 BALANCE DEVIATION DATA REPORT TO SUPPLIER

142 142 (214) FIGURE 45 DH-612 BALANCE DEVIATION DATA REPORT TO DSO In balance deviation data, the following data is returned: Information field Level Necessity Comment Note Balance deviation data Metering grid area Supplier See message type's general description (chapter 12) Supplier Date of registration Moment of balance error calculation Correction total EUR Reporting period Time step Start time End time Balance deviations Balance deviation type Accounting point Loss Accounting point Only used for accounting pointspecific series Hourly values Position Metered energy kwh [1]

143 143 (214) Energy entered in balance kwh [2] Balance deviation kwh [3] Price information Position SPOT price EUR/MWh Correction total EUR Total corrected energy Note [1] [2] Specification kwh Metered energy is reported for accounting points only if the supplier in question has balance responsibility according to the balance information for the accounting point and hour in question. Energy entered in balance is reported for accounting points only if the supplier in question has balance responsibility registered for the hour and accounting point in question either when balance window closes or from a previous balance deviation calculation, and there is a metering value for the hour and accounting point in question. [3] The value is zero if metered energy and energy entered in balance are not defined.

144 144 (214) 9 DH-700 Product and invoicing information maintenance processes FIGURE 46 PRODUCT AND INVOICING ROW EVENTS

145 145 (214) 9.1 DH-711, DH-712 Product data update In a product data update, the DSO and supplier maintain their agreement product data in Datahub. Event Message type Message type description Sender Recipient Note [*] DH-711 F11 Structural data, product Supplier Datahub DH-712 F11 Structural data, product DSO Datahub FIGURE 47 DH-710 PRODUCT DATA UPDATE The update event includes the following information: Information field Level Necessity Comment Note Product data 1 1..n Product validity period Start time End time Product code Product owner's party ID Product description Supplier or DSO

146 146 (214) Product name 2 1..n Language Product name Product components 2 1..n Product component code Product component data Language Product component name Price unit Used also as the unit of price time series. Price unit Calendar time series See message type's general description (chapter 12) Price information 3 1..n Price [1] Price validity period [1] Start time End time Price time series See message type's general description (chapter 12) [2] Note [1] Specification Either fixed price or time series-based price shown. Fixed price is shown in the price field and with the validity period of the price. A time series based price (e.g. hourly price) is shown in the price time series. In relaying information and returning retrievals, price information is only shown if the party is authorised to access the information.

147 147 (214) 9.2 DH-721, DH-722, DH-723 Product data request In a product data request, the parties (DSO, supplier, 3rd party) retrieve the product data of another party from Datahub. Event Message type Message type description Sender Recipient Note [*] DH Supplier DH DH F12 Product data request DSO 3rd party Datahub DH DH DH F11 Structural data, product Datahub Supplier DSO 3rd party Note Specification FIGURE 48 DH-720 PRODUCT DATA REQUEST In an enquiry event, the following data is given:

148 148 (214) Information field Level Necessity Comment Note Product request Product owner 2 0..n Supplier or DSO In a product data request, products valid at the moment of request and in the future are returned. Returned information is the same as in the update of product data (DH-711, DH-712).

149 149 (214) 9.3 DH-731, DH-732 Invoice row data report The DSO and supplier may report invoice row datato Datahub in invoicing information events. Event Message type Message type description Sender Recipient Note [*] DH F13 Invoicing data Supplier Datahub DH F13 Invoicing data Datahub DSO DH F13 Invoicing data Datahub 3rd party DH F13 Invoicing data DSO Datahub DH F13 Invoicing data Datahub Supplier DH F13 Invoicing data Datahub 3rd party Note [*] Specification Invoice row information is forwarded to parties who have been authorised to access such information by the sending party. FIGURE 49 DH-730 INVOICE ROW DATA REPORT

150 150 (214) An invoice row data report event includes the following information: Information field Level Necessity Comment Note Invoice row data Accounting point Contract Party Invoicing period Start time End time Invoice rows 2 1..n Product code Product component code Total invoicing period fpr which invoice rows are reported Price [1] Price unit Price unit Currency EUR Price taxation Yes/No Quantity Quantity unit kwh Quantity unit Invoice row total [1] Description VAT percentage Start time End time Note [1] Specification Price unit is unit of currency/unit of electrical power, e.g. EUR/kWh. The unit of the total is currency, e.g. EUR. If errors are found in message validation, Datahub rejects invoice rows per accounting point. The whole message is not rejected if there is one error, only the invoice rows related to the accounting point with erroneous invoice rows are rejected.

151 151 (214) 9.4 DH-741, DH-742, DH-743 Invoice row data request In an invoice row data request, the parties (DSO, supplier, third party) retrieve the invoice row data of another party from Datahub. Event Message type Message type description Sender Recipient Note [*] DH Supplier DH DH F14 Invoice row data request DSO 3rd party Datahub DH DH DH F13 Invoicing data Datahub Supplier DSO 3rd party Note Specification

152 152 (214) FIGURE 50 DH-740 INVOICE ROW DATA REQUEST In an enquiry event, the following data is given: Information field Level Necessity Comment Note Invoicing data request 1 1..n Invoicing period [1] Start time End time Party [2]

153 153 (214) Accounting point [2] Contract Note Specification [1] Invoice rows that intersect with the invoicing period are returned. [2] Request made either using the party, both party and contract s or an individual accounting point s. If the request is not restricted by party and/or accounting point, all invoice rows belonging to the retrieving party are returned. In a request of invoice row data, invoice row data is returned. Returned information is the same as in the invoice row data report (DH-731, DH-732).

154 154 (214) 10 DH-800 Authorisations FIGURE 51 AUTHORISATION EVENTS 10.1 DH-811, DH-812, DH-813 Notification of customer authorisation from party The supplier, DSO and third party notify Datahub of authorisation received from the customer. Event Message type Message type description Sender Recipient Note [*] DH-811 F15 Authorisation information Supplier Datahub DH-812 F15 Authorisation information 3rd party Datahub DH-812 F15 Authorisation information DSO Datahub

155 155 (214) FIGURE 52 DH-810 NOTIFICATION OF CUSTOMER AUTHORISATION FROM PARTY Information field Level Necessity Comment Note Authorisation 1 1..n Description Free-form description Party Identification of the reporting party Authorisation period Start time End time Authorisation function Energy reporting Invitation to tender Competitive bidding for an agreement as a service Accounting point Customer information 2 1..n Customer Note Specification The following event validations are carried out for payload.

156 156 (214) # Event validation 1 A customer who has given authorisation should have a valid sales or grid agreement for the accounting point for the period of authorisation.

157 157 (214) 10.2 DH-821, DH-822, DH-823 Notification of customer authorisation from customer Customer has edited the authorisation given to the party using the customer user interface. Datahub notifies the party about the changes in authorisation information. Event Message type Message type description Sender Recipient Note [*] DH-821 F15 Authorisation information Datahub Supplier DH-822 F15 Authorisation information Datahub 3rd party DH-823 F15 Authorisation information Datahub DSO FIGURE 53 DH-820 NOTIFICATION OF CUSTOMER AUTHORISATION FROM CUSTOMER Information field Level Necessity Comment Note Authorisation 1 1..n Description Free-form description Party Identification of the reporting party Authorisation period Start time End time

158 158 (214) Authorisation function Energy reporting Invitation to tender Competitive bidding for an agreement as a service Accounting point Customer information 2 1..n [1] Customer Note Specification [1] Customer can authorise access only to their own information The following event validations are carried out for payload. # Event validation 1 A customer who has given authorisation should have a valid sales or grid agreement for the accounting point for the period of authorisation.

159 159 (214) 11 DH-900 Party information FIGURE 54 PARTY EVENTS 11.1 DH-910 Notification of party information Party information is maintained through the online service. Datahub forwards new and changed information to DSOs, suppliers and 3rd parties. Event Message type Message type description Sender Recipient Note [*] DH-911 F16 Party information Datahub Supplier DH-912 F16 Party information Datahub DSO DH-913 F16 Party information Datahub 3rd party FIGURE 55 DH-910 NOTIFICATION OF PARTY INFORMATION