UTILTS User Guide

Ediel-guide
UTILTS & APERAK

Version E5SE1B - valid from October 1st 2011, October 1st 2012 and October 1st 2013
Ediel-guide
UTILTS & APERAK
EDIFACT-message:
EDIFACT-version:
EDIFACT-release:
IG-version:
IG-revision:
Valid from:
IG-Status:
IG-Date:
Published (translated)
UTILTS
D
02B
E5SE1B
6
2011-10-01, 2012-10-01 and 2013-10-01
Published
2015-01-19
2015-01-26
UTILTS-APERAK
Document name: 150119_Ediel_UTILTS-APERAK_User_Guide_Version_11-B-6.doc
Latest updated: 2015-01-26
Page 1 of 137
Ediel-guide
UTILTS & APERAK
Version E5SE1B - valid from October 1st 2011 and October 1st 2012
Content
1
Introduction ................................................................................................................................................................... 4
1.1
General about Ediel ............................................................................................................................................... 4
1.2
Using and implementing Ediel .............................................................................................................................. 5
1.3
Who is the Ediel-guide intended for? .................................................................................................................... 5
1.4
Development and updating of the guide ................................................................................................................ 5
1.5
Tests of UTILTS APERAK................................................................................................................................ 6
1.6
References ............................................................................................................................................................. 6
1.7
Appendices ............................................................................................................................................................ 6
1.8
Change log ............................................................................................................................................................. 6
2
UTILTS a short introduction .................................................................................................................................... 11
3
UTILTS ....................................................................................................................................................................... 12
3.1
UTILTS roles, flows and message types ............................................................................................................. 12
3.1.1
Reporting of values for single objects ......................................................................................................... 13
3.1.2
Reporting of aggregated time series and settlement information ................................................................. 15
3.1.3
Message types per phase.............................................................................................................................. 17
3.1.4
EDIFACT version ....................................................................................................................................... 19
3.2
UTILTS models ................................................................................................................................................... 19
3.2.1
UTILTS S02 (consumption forecast per object) ......................................................................................... 20
3.2.2
UTILTS S03 and S04 (preliminary load profile shares/usage profile shares/aggregated monthly average
power) 21
3.2.3
UTILTS E30 (collected data per object) ..................................................................................................... 22
3.2.4
UTILTS E66 (validated metered data per object) ....................................................................................... 23
3.2.5
UTILTS S07 (time series per object) .......................................................................................................... 26
3.2.6
UTILTS E31 (aggregated metered data, incl. final load profile shares/final usage profile shares) ............. 26
3.2.7
UTILTS S01 and S05 (aggregated settlement values) ................................................................................. 27
3.3
UTILTS-REQUEST (request missing time series) .............................................................................................. 27
3.3.1
UTILTS E72 and E73 (request missing collected/validated metered data per object) ................................ 28
3.3.2
UTILTS E74 and S06 (Request missing aggregated time series / aggregated settlement values) ............... 28
3.4
Negative UTILTS UTILTS-ERR (rejection).................................................................................................... 29
3.4.1
Model for negative UTILTS (UTILTS ERR) as answer to messages with metered values for single
facilities 30
3.4.2
Model for negative UTILTS (UTILTS ERR) as answers to messages with aggregated time series /
settlement information ................................................................................................................................................. 31
3.5
Some fields and terms in UTILTS ....................................................................................................................... 32
3.5.1
Time series product ..................................................................................................................................... 32
3.6
UTILTS general rules .......................................................................................................................................... 35
3.6.1
Summertime/Wintertime.............................................................................................................................. 35
3.6.2
Rules for date formats.................................................................................................................................. 35
3.6.3
Sign direction ........................................................................................................................................... 35
3.6.4
Rules for number of decimals ...................................................................................................................... 37
3.6.5
Quality control ............................................................................................................................................. 37
3.6.6
The register of a meter has gone full circle.................................................................................................. 37
3.6.7
Facilities with registers ................................................................................................................................ 37
3.6.8
Grading [Quality] ........................................................................................................................................ 38
3.6.9
Change of meter........................................................................................................................................... 40
3.6.10 Reason for transaction ................................................................................................................................. 41
3.6.11 Reference to PRODAT transaction ............................................................................................................. 43
3.6.12 UTILTS after PRODAT Z06F .................................................................................................................... 43
3.6.13 Changes/corrections and about registration dates/latest update date ........................................................... 45
3.6.14 The reporting of metered values when interpolating and simultaneous change of supplier (if any) ............ 48
3.6.15 Representative ............................................................................................................................................. 48
3.6.16 Rules for UNB and addressing .................................................................................................................... 48
3.6.17 Transactions, delivery period and resolution ............................................................................................... 48
UTILTS-APERAK
Page 2 of 137
Ediel-guide
UTILTS & APERAK
3.6.18 Number of transactions in a message, number of messages in an interchange etc. ...................................... 49
3.6.19 Size limitations ............................................................................................................................................ 49
3.6.20 UTILTS for yearly metered facilities and when resending of information after July 1 st 2009, previously sent
with MSCONS ............................................................................................................................................................ 50
3.7
UTILTS attributes ............................................................................................................................................... 51
3.7.1
Attributes in phase Planning ....................................................................................................................... 51
3.7.2
Attributes phase Meter reading and Settlement ........................................................................................... 54
3.7.3
Attributes for UTILTS Request ................................................................................................................... 62
3.7.4
Attributes for UTILTS-ERR ........................................................................................................................ 65
3.8
UTILTS message diagram ................................................................................................................................... 68
3.9
UTILTS segment description .............................................................................................................................. 69
4
Acknowledgements and error handling ..................................................................................................................... 102
5
APERAK ................................................................................................................................................................... 106
5.1
APERAK models............................................................................................................................................... 106
5.1.1
Positive APERAK ..................................................................................................................................... 106
5.1.2
Negative APERAK .................................................................................................................................... 107
5.2
APERAK general rules ...................................................................................................................................... 108
5.3
APERAK attributes ........................................................................................................................................... 110
5.4
APERAK message diagram ............................................................................................................................... 112
5.5
APERAK segment description .......................................................................................................................... 113
Appendix 1 Rules for APERAK Guide validation ...................................................................................................... 123
Appendix 2 Rules for UTILTS ERR Processability validation ................................................................................... 132
Appendix 3 UTILTS EDIFACT-examples per object.................................................................................................... 136
Appendix 4 APERAK and UTILTS ERR EDIFACT-examples per object ................................................................... 136
Appendix 5 UTILTS EDIFACT-examples for aggregated time series........................................................................... 136
Appendix 6 APERAK and UTILTS ERR EDIFACT-examples for aggregated time series .......................................... 136
Appendix 7 EAN-numbers for electricity meters and facilities ...................................................................................... 137
UTILTS-APERAK
Page 3 of 137
Ediel-guide
UTILTS & APERAK
1 Introduction
Notes to the reader:
Text within brackets, [], are further comments not included in the original Swedish guide. Figures are not (yet) translated.
This UTILTS user guide is valid from October 1st 2011, and regarding the rule about bundling of messages from
October 1st 2012 and regarding sending positive APERAK for time series where a notify is possible from October 1st
2013.
[Not translated]
Mjliga framtida ndringar
En frsta strre revision gjordes till anvisningen giltig frn april 2010, drefter har ndringar gjorts till oktober 2011,
oktober 2012 och oktober 2013. Hr listas planerade ndringar, nnu inte genomfrda.
3) Infrande av rollerna Reconciliation Responsible och Reconciliation Accountable, jfr kapitel 3.1. Samtidigt
utreds infrandet av rollen Billing Agent vilken skickar meddelandet E70 (Exchange Price Volume
Combination for Reconciliation from Billing Agent to Reconciliation Accountable). Meddelandet erstter i s fall
S01 och S05 fr slutavrkning frn Svenska kraftnt och balansansvariga. Den freslagna ndringen kommer att
behandlas i det kommande nordiskt harmoniseringsarbetet.
5) Nya och tydligare felkoder kan behvas. Fel fr vissa befintliga koder kan ocks behva ndras, t.ex. delas upp i
olika varianter som tydligare sger vad som r fel. Detta tas upp i det kommande nordiskt harmoniseringsarbetet.
10) I ett UTILTS S03-meddelande r alltid avrkningsmetoden schablon. Fltet fr avrkningsmetod skulle drfr
kunna utg. ven fltet Typ av anlggning kan komma att utg i UTILTS S03. Detta behandlas i det kommande
nordiska harmoniseringsarbetet. Fr naturgasmarknadens behov planeras en ndring s att fltet
Avrkningsmetod grs villkorligt av tidsserieprodukten.
12) Viss skrpning av rekommendationerna fr UTILTS efter PRODAT Z06F, se kapitel 3.6.12, planeras gras i
framtida version. Detta tas upp i det kommande nordiskt harmoniseringsarbetet.
19) Nytt flt infrs fr att srskilja p energivrden p naturgasmarknaden baserade p preliminrt eller slutligt
vrmevrde. Avsikten r att infra tv koder i SG7/CCI/CAV.
23) En ny meddelandetyp med fakturaunderlag (belopp och/eller priser) fr enskild anlggning har freslagits. Den
skulle exempelvis kunna anvndas som underlag fr samfakturering, meddelandetypen blir E70. Frgan kan
komma upp i det kommande nordiska harmoniseringsarbetet.
24) Registreringstidpunkten/Senaste uppdateringstidpunkten mste fr skede Avrkning alltid vara senare n
leveransperioden. Men regeln kan komma att ndras s att denna tidpunkt mste vara minst samma som
starttidpunkten fr den sista sekvensen i leveransperioden. P det sttet kan avrkningen starta direkt efter
"leverans" av den sista "energimngden" (eller motsv.) innan perioden, t.ex. sista timmen i dygnet, r slut.
Infrandet grs tidigast i april 2014.
25) Hll ihop kvittenser p UTILTS-meddelanden, ett UTILTS-meddelande utan fel kommer d kvitteras med ett
enda positivt APERAK oavsett antalet transaktioner. Negativa APERAK och negativa UTILTS (UTILTS-ERR)
br ven hllas ihop och skickas som varsitt meddelande och inte med ett meddelande per transaktion. Denna
ndring grs tidigast i april 2014.
1.1
General about Ediel
Ediel is a standard for electronic interchange of structured information within the electricity- and natural gas-markets. The
information is structured in the form of standardized EDIFACT messages, known as Ediel messages.
The standard development is in European level driven by ebIX (European forum for energy Business Information
eXchange) where among others Sweden participates. More information about ebIX, see www.ebix.org.
In Sweden the Ediel-messages are developed and administrated by Svenska kraftnt. The work is done in different
working groups, such as within Elmarknadsutveckling (in cooperation with Energy Markets Inspectorate
[Energimarknadsinspektionen], Swedenergy [Svensk Energi] and Independent Power Traders [Oberoende Elhandlare])
and Ediel Technology-group [Ediel Teknikgrupp]. In the different working groups there are, besides representatives from
Svenska kraftnt, Energy Markets Inspectorate [Energimarknadsinspektionen], Svensk Energi and Oberoende Elhandlare,
UTILTS-APERAK
Page 4 of 137
Ediel-guide
UTILTS & APERAK
representatives from different actors within the electricity market, natural gas market as well as, as observers in the Ediel
Technology group, system developers who supply Ediel-systems.
1.2
Using and implementing Ediel
To use and implement Ediel the right way, you must on one hand know how the routines work in the electricity and
natural gas-market from a business perspective and on the other how Ediel messages are implemented technically. After
implementation but before start of operation, tests must be carried out and be approved.
The process of reporting time series is described in the Handbook for the Swedish Electricity Market [Elmarknadshandboken] [1] and in the Swedish Gas Market Handbook [Gasmarknadshandboken] [2] respectively (henceforth called
The Handbook). Therefore it is of outermost importance that the implementation of UTILTS is done on the basis of this
guide together with the rules in The Handbook in parallel to get a correct implementation. The Swedish Electricity Market
[Elmarknadshandboken] can be found at www.elmarknadsutveckling.se [in Swedish] and the Swedish Gas Market
Handbook [Gasmarknadshandboken] at www.gasmarknadshandboken.se [in Swedish].
For each Ediel-message normally an international EDIFACT-specification is written, a so-called Implementation guide.
There is also an international guide for common rules within Ediel Functional Description, or now within ebIX
Common rules and recommendations. The UTILTS implementation guide and Common rules and recommendations can
be found at www.ebix.org, and an older guide for APERAK as well as Functional Description at www.ediel.org.
Since the implementation guides are general and are valid for Ediel both within the Nordic Countries and Europe, national
technical Ediel-guides are necessary. The national technical Ediel-guides are more detailed and describe the national
rules. Notice also the general technical Ediel user guide.
This document contains the national technical Ediel-guide for UTILTS and adherent APERAK. For each message it is
described both what information an application shall send or receive and also how this information shall be structured in
an EDIFACT message. Together with the guide there are some appendices with rules for how an UTILTS shall be
validated at the recipient and examples of EDIFACT messages. Read the guide and the appendices with examples in
parallel to get the best understanding of how the different EDIFACT-segments shall be repeated and used. For the
collections of example, see separate documents, one for values per object and another one for aggregated time series.
Notice that this Ediel-guide only describes the technical rules. The technical Ediel-guides and the Handbook complement
each other since the Handbook describes the way Ediel-messages shall be used in practice.
1.3
Who is the Ediel-guide intended for?
The Ediel-guide is intended for System developers and actors that develop own systems and solutions for Ediel in Sweden
and that will implement incoming and/or outgoing UTILTS- together with APERAK-messages. The document is technical
and concentrated on EDIFACT. For business rules and routines we refer to The Handbook.
The reader is expected to have a good knowledge about the EDIFACT-standard. Current EDIFACT-terms are not
explained in the document.
1.4
Development and updating of the guide
Ediel Technology group maintains this Ediel-guide. Updating of versions (major changes requiring system updates) is
done twice a year at maximum, normaly once in April, and another in October. Updates of versions are normally
published 6 months in advance. Revisions (clarifications, corrections, spelling mistakes, restructuring of text etc.) can be
made at any time.
All information about guides for Ediel messages can be found at the Ediel Portal, www.ediel.se.
EbIX Technical Committee (ETC), maintains the implementation guides, more information at www.ebix.org.
UTILTS-APERAK
Page 5 of 137
Ediel-guide
UTILTS & APERAK
Feedback, suggestions and questions on the Ediel-guide or the implementation guides are gratefully received. Please send
your feedback to the chairman of Ediel Technology group, Oscar Ludwigs at Svenska kraftnt (oscar.ludwigs@svk.se), or
to ediel@svk.se.
1.5
Tests of UTILTS APERAK
Tests of UTILTS and APERAK are done in Ediel test system at the Swedish Ediel Portal.
For detailed information about the tests at the Ediel Portal, see test guide for the different messages.
Documentation [in Swedish] can be found at www.ediel.se below Test och certifiering Information Tester UTILTS.
1.6
References
Reference documents:
[1] Elmarknadshandboken, www.elmarknadsutveckling.se [An English version from 2005 exists]
[2] Gasmarknadshandboken, www.gasmarknadshandboken.se [Gas-market, in Swedish]
[3] ebIX dokumentation, www.ebix.org [In English]
[4] Ediel-documentation from Svenska kraftnt
a. www.svk.se > Drift och marknad > Verktyg fr branschaktrer > Ediel [Only in Swedish]
b. www.ediel.se, here you among other things can find a common technical Ediel-guide [in Swedish]
[5] EDIFACT messages (UTILTS D02B, APERAK D04A), www.unece.org/trade/untdid
1.7
Appendices
To the guide there are seven appendices.

1. Rules for APERAK Guide validation. I.e. the validations against this guide that shall be made for a received UTILTS
2. Rules for UTILTS-ERR Processability validation. Here is for instance described the error codes used after validation
of the received UTILTS-message against The Handbook.
3. UTILTS EDIFACT-examples for values per object
4. APERAK and UTILTS-ERR EDIFACT-examples for values per object
5. UTILTS EDIFACT-examples for aggregated time series
6. APERAK and UTILTS-ERR EDIFACT-examples for aggregated time series
7. GS1-numbers for electricity meters and facilities
Appendix 3-6 is found in separate collection of examples.
1.8
Change log
Changes earlier than version 10.A.0 are not included.

Version/Rev
Date
News/corrections/changes/clarifications
UTILTS-APERAK
Page 6 of 137
Ediel-guide
UTILTS & APERAK
10.A.0
(2009-10-01)
10.A.1
(2009-10-09)
10.A.2
2010-01-25
Changes:
In UTILTS E73 the fields Type of Metering Point and Produkt identification has been added to
clearly identify which facility's meter readings that are wanted, see chapter 3.3.1 and 3.7.3.
RegisterId 901 is used for hourly metered facilities (according to the Handbook) unless otherwise
agreed upon, see chapter 3.6.7.
In chapter 3.6.8 the recommendation not to specify status code for load profile share has been
changed to a rule. See the model for UTILTS S03 and S04 in chapter 3.2.2, as well as the
tables in 3.7.1 and 3.7.2.
The field Unit measurement is not specified in UTILTS S01 or S05 if the transaction is a time
series with amounts see the model in 3.2.7 and the table in 3.7.2. The use depends on the
current Time series product
The field Settlement method in UTILTS S01 and S05 are now dependent on current Time series
product. See the model in 3.2.7 and the table in 3.7.2.
The field Diverging number of Metering Points are not sent for aggregated hourly values. See the
table in 3.7.2.
In UTILTS ERR the field Reason for transaction has been added as an ebIX harmonisation. Thus
the STS segment occurs twice in UTILTS ERR. See 3.7.4 and 3.9.
The measurement unit Z10 added into the MEA segment has been withdrawn since the MEA
segment no longer is required in UTILTS S01 or in UTILTS S05, but instead depends on the
Time series product.
The data element 1131 has been added into the DOC segment in APERAK, and it contains
"SVK" if the APERAK refers to UTILTS S01-S07.
In the UNH segment, both for UTILTS and APERAK, the version E5SE0A is specified.
Clarifications:
In chapter 3.6.4 it is clarified that profile shares are sent in whole kWh.
Clarified in chapter 3.9 that Transactionsid shall be unique over time for all of the senders
applications.
Additions:
In the introduction the part about possible future changes has been rewritten since several of the
changes now are incorporated.
The changes, corrections and clarifications are also included in version 09.A.21.
Corrections
The rules for some fields in specific segments in chapter 3.9 has been corrected from "R"
(Required) to "M" (Mandatory) according to the EDIFACT message, see [5]. The corrections
are:
3496 in MKS, 3227 in SG5/LOC, first C212 in SG5/PIA, 9015 in SG5/STS, 4405 in
SG5/STS, 9013 in SG5/STS, 6411 in SG5/MEA, 7037 in SG7/CCI, C889 in SG7/CAV
and 7037 in SG12/CCI.
Changes:
Gas industry and Electricity industry has been changed to Gas market and Electricity market.
Clarifications:
The clarification in chapter 3.6.17 is that a transaction for an hourly read facility may cover a
shorter period than a month after a PRODAT Z06F.
Clarified in the LOC segment in chapter 3.9 that Metering Point Id also may be used for metering
points, e.g. for metering points that together with other metering points is a part of a facility.
Relevant corrections, clarifications and additions are also included in version 09.A.22.
Corrections
In the introduction it is stated that the guide is valid from April 6 th 2010 and nothing else.
Removed unused error code E86 in the diagrams in chapter 3.4.1 and 3.4.2.
Corrected in chapter 3.6.10 that Reason for transaction is specified in every UTILTS message.
Added that the same code used in the received message also is used in UTILTS ERR.
Corrected in chapter 3.6.13 a statement that the registration date was changed at resending, it
should be at corrections.
Missing information about EDIFACT mapping for the field Reason for transaction has been
added in chapter 3.7.4.
Corrected in Appendix 1 that the code in the UNH segment, field 312, shall be E5SE0A.
The reference in Appendix 2 to Case 2008:44 at www.elmarknadsutveckling.se has been
removed.
Changes
Among future possible changes the recommendation for UTILTS after PRODAT Z06F has been
rewritten, only parts of the recommendations are expected to be rules.
In chapter 2 the text about a time schedule for introduction of UTILTS has been removed.
The text about representatives in chapter 3.6.15 has been removed, instead is added a reference to
the General technical Ediel user guide.
Chapter 3.6.20 has after the introduction of UTILTS partly been rewritten and the text about
usage of UTILTS before July 1st 2009 has been removed.
Clarifications
Clarified in chapter 3.2.7 that the energy quantity, price and / or amount sent depends on the
UTILTS-APERAK
Page 7 of 137
Ediel-guide
UTILTS & APERAK
10.A.3
(2010-03-09)
10.A.4
(2010-03-29)
10.A.5
(2010-06-23)
current time series product.

The rules in chapter 3.6.3 have been rewritten to make it clearer that when the "buyer" has sold
energy to the "seller", the sign is reversed from when the "buyer" buys from the "seller".
Clarified in chapter 3.6.8 that no quality marks are used for prices or amounts.
Clarified in chapter 3.6.13 that the section about resending describes the resending of previously
sent metered values, not of EDIFACT files. Clarified that transaction id in a resending should
be different from the one in the original message.
The field [Swedish] Avvikande antal mtpunkter is now called Diverging number of Metering
Points in English (chapter 3.7.1 and 3.7.2).
Clarified the text about Number of Metering Points in SG7/CAV, e.g. it is not used when losses
are included in the aggregated time serie, e.g. for consumption profiles.
Clarified that the field A203 in APERAK (Document identifier in BGM), in the same way as 203
in UTILTS, is unique over time for all of the senders applications.
Made it more clearly in SG5/RFF (APERAK) that Reference to original UTILTS transaction id
will not be sent if the APERAK is a negative APERAK sent due to errors in the message
header. Added a remark (in chapter 5.3) that the field always is sent in a positive APERAK.
Clarified in Appendix 1, according to the rule that a negative APERAK is sent due to errors in the
message header, that when there is an error concerning the unique document id, the message is
rejected with the error code 42.
Clarified in Appendix 2 that the error code E14 (other reason) in UTILTS ERR should be avoided
as much as possible.
Additions
Added an e-mail address to ediel@svk.se in chapter 1.4.
Added the unit CEL for degrees Celsius, used in bilateral time series.
Clarifications:
Clarified below figure 3 that it is about the flow of E31 for the imbalance settlement
[balansavrkningen].
Clarified below figure 5 that it is about the flow of E31 for the reconciliation [slutavrkningen].
Additions:
Added a new product code in SG5/LIN for heating value (used in the gas market), expected to be
used from October 2010.
In the introduction the part about possible future changes has been supplemented with a couple of
updates planned for October 2010.
Correction:
In SG12/CAV the information that a status code should be specified if diverging number of
metering points were sent has been excluded. This is because diverging number of metering
points only is sent for load profile shares/usage profile shares and no status codes are sent for
load profile shares/usage profile shares.
Clarifications:
Clarified in 3.6.8 that status codes not are sent for load profile shares/usage profile shares.
Changes and corrections:
In the introduction the text about future changes has been updated since the changes at the earliest
will be implemented from [october] 2011. Two future possible changes have also been added.
Changed the role "Electricity user" to "Electricity/Gas user"
Added sub chapters describing the rules for natural gas market: 3.5.1.1 (time series products),
3.6.1.1 (summer time/winter time), 3.6.3.1 (sign direction), 3.6.4.1 (number of decimals),
3.6.9.1 (change of meter) and 3.6.10.1 (reason for transaction).
Corrected the rules for number of decimals for prices since prices specified with two decimals in
re/kWh will have four decimals in SEK/kWh, so we need to handle four decimals in the
messages.
In chapter 3.6.20 the reference to an example for a yearly read metering point has been cut out
since the examples is no longer part of the collection of examples.
Added a new code for Reason for transaction in SG5/STS, Z02 Preliminary imbalance
settlement, used in the natural gas market.
Clarifications:
Clarified in chapter 3.5.1 that the five parts of the time series product is three characters long.
Clarified in chapter 3.6.12 that reporting after changed number of digits only will be done if the
meter has gone full circle since last meter reading. And that the recommendation is to send the
first transaction after changed counter code as soon as possible after the change.
Clarified in chapter 3.6.13 that if the aggregated values have been changed a new latest updated
date should be specified, cfr case 2010:15 at www.elmarknadsutveckling.se.
Clarified in chapter 3.7 that in UTILTS S03 the Type of metering point is always consumption.
Clarified that document id in BGM (in UTILTS as well as in APERAK) should be unique for
every application at the sender that sends UTILTS messages (and APERAK as answer to
UTILTS).
Clarified in SG5/STS which Reason for transactions that are used in UTILTS E30.
In general clarified that S03 and S04 in the natural gas market also is used for aggregated monthly
average power.
UTILTS-APERAK
Page 8 of 137
Ediel-guide
UTILTS & APERAK
In general changed "gas-market" to "natural gas-market".
10.A.6
(2011-01-28)
10.A.7
(2011-03-21)
11.B.0
(2011-04-01)
11.B.1
(2011-11-16)
The unit code Z15 (kWh/m3) has been changed to E46 (only used in the natural gas market).
The recommendation in chapter 3.6.11 that referencing to the change of supplier when a UTILTS
transaction can be linked to two PRODAT processes, e.g. both to a change a supplier and a
change of meter process, has (cfr the Handbook and case 2009:01 at
www.elmarknadsutveckling.se) been changed to that you ought to specify the code "P" in the
field with the reference to the PRODAT transaction.
Clarified in the description of the LOC segment in chapter 3.9 that the same code for code list
responsible (for Metering point ID) used in PRODAT also should be used in UTILTS.
Clarified the figure in chapter 4 that it is more obvious beeing a loop to handle all transaction and
that the process does not end until all transactions has been handled. The figure has also been
updated so that you typically send positive APERAK when all transactions are handled.
Clarified in chapter 3.9, the SG11/STS segment, that the quality code 125 only occurs in E30.
Exemplfied in appendix 2 that the error code E62 may be used when there are several registers, but
only one is sent, or opposite, two are sent when expecting one.
Three future changes has been added to chapter 1, and changed dates for when earlier discribed
future possible changes may be implemented.
In general "Counter" has been changed to "Register", except for "Counter codes".
Changed in chapter 3.5.1 that there may be time series products with amounts in different
currencies, even if it is unusual.
Changed in chapter 3.6.4 according to the Handbook that the energy for hourly metered facilities are
sent in kWh with kWh 0-3 decimals. Added a text telling that the decimal rules are valid when no
agreement, regulation or Handbook say otherwise.
Supplemented chapter 3.6.5 with the need to notify the modification of approved ("first rate") values
for single facilities.
Clarified that the examples about changed status of installation in chapter 3.6.12 requires a
electricity or a gase user and a supplier in the facility.
In the introduction the part about possible future changes has been rewritten since several changes
are supposed to be implemented October 1 st 2011, and in other cases will be handled in the
Nordic harmonisation work.
Added a new role "Statistikinsamlare" (Market Information Aggregator) that after bilateral
aggreement can receive UTILTS messages.
Updated the figures in chapter 3.1.1 and 3.1.2 so that they better describes the flow within the
natural gas market and with addition of the new role Market Information Aggregator.
Changed in chapter 3.6.4 prices can be specified with up to six decimals.
Has changed the term prima value into approved value in chapter 3.6.8.
An importent change concerns hourly values with status Temporary, they must at the latest after day
5 be replaced with a value with status Estimated or Approved (first rate), see chapter 3.6.8.
Otherwise, the chapter has been rewritten and references to old rules in MSCONS and DELFOR
have been removed.
The recommendation to specify P as the reference to the PRODAT transaction
(rendereferensen) when a UTILTS transaction can be linked to two different PRODAT
transactions has been changed; you should specify the code P, see chapter 3.6.11.
When sending missing monthly energy values at turn of month, option 2 has been removed. I.e.
you should now always send only the NULL energy from the latest month, see chapter 3.6.13.
In the UNH segment, both for UTILTS and APERAK, the version E5SE1B is specified.
Regarding the recommendation to keep the acknowledgements from an UTILTS message together,
see chapter 4, is referred also to case 2009:18 at www.elmarknadsutveckling.se.
Regarding the field Transaction id, that since April 2010 should be unique over time, it will be
rejected with negative APERAK if you find duplicates of the transaction id, see Appendix 1.
In Appendix B the rule has been removed that the error code E10 (Metering point not identifiable)
should be used for the case the installation has ceased. Instead, the error code E50 (Invalid period)
is used for the case that the installation is known, the latter rule has been possible to follow since
April 2010.
In Appendix B the rule that the error code E62 can be used for the case there is no register in the
transaction, has been changed; the error code E62 should be used in this case.
In the introduction the part about future changes has been rewritten since several of the changes now
are incorporated.
Earliar changes than from April 2010 has been removed from chapter 1.8.
Updated the text about future changes in chapter 1 since no changes will occur in April 2012.
Added Energy Markets Inspectorate [Energimarknadsinspektionen] in chapter 1.1.
Changed the term observation period to delivery period.
Updated the header and introduction in chapter 3.5 UTILTS is not new anymore.
Clarified the rules regarding grading (status codes), specielly for hourly metered values, in chapter
3.6.8.
Clarified in chapter 3.6.17 that the same meter stand (for one and the same meter reading date) may
not be sent several times within the same transaction.
UTILTS-APERAK
Page 9 of 137
Ediel-guide
UTILTS & APERAK
11.B.2
(2012-03-30)
11.B.3
(2012-10-01)
11.B.4
(2013-04-02)
11.B.5
(2013-09-27)
11.B.6
(2015-01-19)
Clarified in 3.6.17 and in Appendix 2 that for resolution month the transaction (delivery period)
normally covers a calender month, and at the most a calender month. For resolution day the
period is at the most a calender month.
Updated in Figure 24, from sending Positiva APERAK to sending Positivt APERAK.
Since October 1st 2012 messages should be bundled. E.g. if at the same time 10 time series should
be sent to a recipient, theses should be sent as 10 transactions in one single message. Chapter
3.6.18 is therefore updated. Note that there is no new version in October 2012.
Added about planned changes related to acknowledgements in the text about future changes in
chapter 1.
Chapter 4 is updated in order to more clearly point to the recommendation holding the
acknowledgments together in the response to UTILTS messages.
Clarified in chapter 3.6.13 that if the aggregated values have been changed, the latest update date
should be later than an earlier sent point in time.
Updated the introduction about future changes since new changes not will occur before October
2013.
Since October 1st the rule is, according to the updated regulation, that the status Temporary only will
be used for installation part of the imbalance settlement. Se below in chapter 3.6.8 and in the
description of the STS segment in segment group 11, chapter 3.9.
Since October 1st the rule is, according to the updated regulation, that meterstands, and therefore
also meter number, always should be sent for profiled settled hourly metered installations. See
below figure 11 in chapter 3.2.4.
The text about possible future changes in chapter 1 is updated since the next version will come
earliest in April 2014.
In chapter 3.6.5 there has been added a rule, valid from October 1st 2013, regarding sending
positive APERAK if the sender has right to notify changes of metered data. I.e. if the rules about
notifying are fulfilled, the receiver have no right to reject the UTILTS message only for the reason
that the notification does not arrive before the UTILTS message has reached the recipient.
In chapter 3.6.18 there is a clarification that several different legal receivers may not be specified
within one and the same interchange, this rule applies directly.
Added to figure 6 it is clearified that the code ERR for Document name only is an example.
Removed text with reference to MSCONS and DELFOR in several chapters, mostly in chapter 3.5.
The text about sending messages to the issuer of certificats has been changed since
Energimyndigheten now acts in that role.
Clarified in 3.6.7 that if a meter stand is missing, then NULL should be specified, and in that case
the energy volume may not be compared with the meter stands, see also Appendix 2.
Clarified in 3.6.12 that UTILTS is not sent to a possible future supplier
Clarified in 3.6.13 that if a corrigendum transaction is created before the original transaction has
been sentm the latter ought to be deleted. Should they anyway be sent in the same message, the
original transaction must come before the corrigendum.
Clarified in 3.6.14 that several meter stands may be sent for one and the same day and night.
Clarified in SG7/CAV that a facility, linked to one and the same supplier during separate periods
within a month, only should be counted once when calculating number of metering points.
UTILTS-APERAK
Page 10 of 137
Ediel-guide
UTILTS & APERAK
2 UTILTS a short introduction

The UTILTS message (Utility Time Series Message) was developed by Ediel during 1999-2002 since MSCONS- and
DELFOR-messages did not follow the structure and had no place for all of the information we wanted to send. Further on
it was unreasonable using two different messages sending time series.
In general a UTILTS message has exactly the same information and the same basic structure as an MSCONS- or a
DELFOR-message, i.e. each such message (document) contains one or more time series (transactions) with one or more
values (observations).
Thus the UTILTS messages are divided in separate levels corresponding with different EDIFACT segment groups:
Level 1 UTILTS-message (BGM SG2/NAD)
Level 2
UTILTS-transaction (SG5/IDE SG7/CCI-CAV)
Level 3
UTILTS-observation (SG8/SEQ SG12/CCI-CAV)
Level 1 UTILTS-message (document)
The UTILTS message level, contains the header information, i.e. all information concerning the whole UTILTS message,
like message type, message date, sender, recipient, phase etc. Level 1 corresponds with the segments from BGM up to and
including segment group 2 (NAD).
Level 2 UTILTS-transaction
An UTILTS-messages consists of one or more UTILTS-transactions. The transaction is the level where the time series is
described, i.e. it is always one time series per transaction. An UTILTS-transaction is repeated one time per installation
(facility) and/or time series product. The UTILTS transaction contains information like transaction id, metering point id,
meter number, time series product, delivery period, reason for transaction1, resolution of the energy values in the
observations etc. The UTILTS transaction corresponds with segment group 5 (IDE) segment group 7 (CCI-CAV).
If an UTILTS transaction belongs to a PRODAT transaction then the reference to the PRODAT transaction can be sent in
the UTILTS transaction.
Level 3 UTILTS-observation
A UTILTS transaction consists of one or more UTILTS observations. E.g. metered valus for:
- energy volume, hourle values
- energy volume, in the delivery period (according to the resolution)
- planned energy volume
- meter readings
This is reported in separate UTILTS observations. Examples of information in an UTILTS-observation are observation id
[position], time period, meter reading, energy volume, etc.
Energy volumes should normally always be sent, it is however not required in UTILTS E30 (meter readings and/or energy
volumes are sent) nor in transactions with aggregated time series only consisting of prices or amounts and nor in the
natural gas market in UTILTS E66 if only a start stand is sent.
The UTILTS-observation corresponds with segment group 8 (SEQ) up to segment group 12 (CCI-CAV).
Acknowledgements in APERAK are reported per UTILTS transaction, i.e. in each APERAK it is a reference to each
UTILTS transaction id. The same apply for negative UTILTS messages, UTILTS-ERR. A UTILTS message with several
transactions can be followed by several acknowledgement messages corresponding to one transaction each. But
acknowledgment messages can also contain several transactions but you may never mix positive and negative answers in
the same message. Read more in chapter 4 about Acknowledgements and error handling.
Reason for transaction is always the same in the whole message.
UTILTS-APERAK
Page 11 of 137
Ediel-guide
UTILTS & APERAK
3 UTILTS
3.1
UTILTS roles, flows and message types
UTILTS-messages are grouped into different message types sent between different roles in the electricity- and in the
natural gas- market. In Sweden we have four major actor types in the power market: System responsible, Balance
Responsible [also called Balance Provider], Balance Supplier and Network owner. In addition there are for example
representatives who act for one or more types of actors, but the role representative do we not specify in the messages. But
instead we specify the role for the actor who engages the representative. Further on producers and meter data collectors
can use Ediel, not at the same time being Balance responsible or Network owners. In addition Electricity/Gas users who
whishes can use Ediel and receive metered values / time series.
According to ebIX it is the role that should be specified in the messages, and not that you are a Network owner a
Network owner can do more than just own a grid, or perhaps parts of the Network owners tasks roles are handled by
other actors.
As an example ebIX for measure has identified eleven different attached roles, see figure 1.
Measure
Party connected
to grid
Metered data
collector
Collect
Grid access provider
Balance supplier
Metered data
responsible
Validate
Balance
responsible party
Metered Data
Aggregator, local
Transport capacity
Responsible party
Aggregate local
Imbalance
Settlement responsible
Reconciliation
Accountable
Reconciliation
Responsible
In the figure the roles typically for a network owner are marked in green. Some roles are not in use in Swedish messages,
e.g. Reconciliation Responsible (in Sweden: Svenska kraftnt, Imbalance Settlement Responsible or Balance providers,
Balance responsible party is used instead) and Reconciliation Accountable (in Sweden: Balance providers, Balance
responsible party or Suppliers, Balance supplier, is used instead). Some roles are added for the Swedish message
exchange, see the next figure.
The following message types are described in this user guide
Phase: Planning
S02 Consumption forecast per object, sent from network owners (Metered data responsible)
E73 Request missing validated metered data per object
UTILTS-APERAK
Page 12 of 137
Ediel-guide
UTILTS & APERAK
S03 Preliminary load profile shares/usage profile shares/aggregated monthly average power, sent from network
owners
E74 Request missing aggregated time series
S04 - Preliminary load profile shares/aggregated monthly average power, sent from Svenska kraftnt
S06 Request missing aggregated settlement values
Phase: Meter reading and Settlement
E30 Collected data per object, sent from metered data collectors
E72 Request missing collected metetered data per object
E66 Validated metered data per object, sent from network owners (metered data responsible)
E73 Request missing validated metered data per object
S07 Time series per object, sent from suppliers
E31 Aggregated metered data, incl. final load profile shares /usage profile shares, sent from network owners
E74 Request missing aggregated time series
S01 Aggregated values for settlement, sent from Svenska kraftnt
S06 Request missing aggregated settlement values
S05 Aggregated values for settlement, sent from Balance responsibles parties
3.1.1
Reporting of values for single objects
For the report of values for single objects, nine different roles are used in the Swedish electricity market, see the following
figure and table:
S07
Bilateralt/enligt avtal Ntgare

Enl. freskrifter
aggregerar
Leverantr
S02
E66
E66
S07
S07
Mtvrdesinsamlare
Mtvrdesansvarig
E30
E66
E66
E66
Systemansvarig
Certifikatutfrdare
E66
Producent
Elanvndare
E66
Statistikinsamlare
Balansansvarig
Figure 2a. Flows of metered values per object within the electricity market. Green arrows includes exchanges according to
regulation, but may also include bilateral agreed exchanges, so-called free time series.
For the report of values for single objects, seven different roels are used in the Swedish natural gas market, see the
following figure and table:
UTILTS-APERAK
Page 13 of 137
Ediel-guide
UTILTS & APERAK
S07
Ntgare
aggregerar
Bilateralt/enligt avtal
Enl. Gasmarknadshandboken
E66
Leverantr
E66
S07
S07
Mtvrdesinsamlare
E30
Mtvrdes ansvarig
E66
Producent
Gasanvndare
E66
E66
Statistikinsamlare
Balansansvarig
Figure 2b. Flows of metered values per object within the natural gas market. Green arrows includes exchanges according
to the Handbook (for gas), but may also include bilateral agreed exchanges, so-called free time series.
Internally within a network owner you may also have flows of UTILTS E66 from Metered data responsible to Metered
data aggregator, but also from Metered data responsible to Grid access provider (cfr figure 1), i.e. in the latter case
for billing the grid cost.2 Not described in the figure is that the supplier also may send messages to the Market Information
Aggregator.
ebIX role
Metered Data Collector (DDE)
Metered Data Responsible

(MDR)
Used by
Metered data collector
(typical another than
network owner)
Network owner,
including Svenska
kraftnt in this role3
Reports to
The Network owner (in the role Metered Data
Responsible)
Supplier [i.e. Balance supplier]
Electricity/Gas user (with Ediel)
Producer (with Ediel)
Balance Responsible
Market Information Aggregator (with Ediel)
[Swedish: Statistikinsamlare]
(adjacent) Network owner in the role Metered
Data aggregator
Svenska kraftnt in the roles System operator
(Svenska kraftnt as System operator) and
Metered data aggregator (in the role as
network owner)
Energimyndigheten in the role Issuer of
certificates (for energy certificates)
The role Grid access provider is expressed with the ebIX-code DDM. In Sweden we have chosen not to separate
between billing of energy and billing of grid cost, instead we always specify the code E88 Billing Energy as Reason for
transaction. ebIX on the other hand uses also the code E89 Billing Grid cost, which thus is not used between Swedish
energy companies. An E66 message for billing of grid costs whould otherwise differ from an E66 message for billing of
energy on these two items, i.e. Reason for transaction would be E89 (Billing Grid cost) and Ancillary role could,
depending on the receiver, be DDM (Grid access provider).
3
The role is used by actors establishing and ensuring the quality [validating] of collected values, as well as storing the
history. It may, besides metered value for electricity and gas, also apply for district heating and meteorology. In such
cases, for example, a player such as SMHI may be Metered Data Responsible.
UTILTS-APERAK
Page 14 of 137
Ediel-guide
UTILTS & APERAK
Metered data aggregator (DEA)
Balance supplier (DDQ)
Party connected to grid (DEC)
Network owner
Supplier
Electricity/Gas user
Producer
Balance Responsible (DDK)

Issuer of Certificates (PQ)
Balance responsible
Issuer of energy
certificates (Energimyndigheten)
System operator
(Svenska Kraftnt)
Market Information
Aggregator [Swedish:
Statistikinsamlare]4
System operator (EZ)

Market Information Aggregator
(DER)
3.1.2
Reporting of aggregated time series and settlement information
To report aggregated time series and settlement information the following roles are used according to figures and table:
Enl. freskrifter/
Gasmarknadshandboken
Leverantr
E31
El
S01
Gas
Mtvrdes ansvarig
E66
Ntgare
aggregerar
Balansavr.ansvarig
E31
El
E31
E31
S05
Gas
S01
E31
Statistikinsamlare
S05
Balansansvarig
Figure 3. Flows of aggregated metered data for the imbalance settlement, incl. E66 from Metered Data Responsible.
Green arrows includes exchanges according to regulation, but may also include bilateral agreed exchanges, so-called free
time series.
This role is for example used for Statistics Sweden [Statistiska centralbyrn] or industry organisations like Swedenergy
[Svensk Energi] and Svensk Vindenergi.
UTILTS-APERAK
Page 15 of 137
Ediel-guide
UTILTS & APERAK
Enl. freskrifter/
Leverantr
S03
Ntgare
aggregerar
Balansavr.ansvarig
S03
El
Gas
S04
S03
Balansansvarig
Figure 4. Flowes of Preliminary load profile shares (electricity market) and Preliminary usage profile shares and monthly
average power (natural gas market).
Enl. freskrifter/
Mtvrdes ansvarig
E66
Ntgare
aggregerar
Leverantr
E31
Balansavr.ansvarig
E31
El
S05
Gas
S01
E31
Balansansvarig
Figure 5. Flowes of final load profile shares/usage profile shares for the reconciliation, incl. E66 from Metered Data
Responsible.
In the above cases (figures 3-5) there may also be a need of interal flows within an actor, like within a network owner or
between a balance responsibles different systems before the next external flow starts. Such flows of aggregated
information are not further described in this user guide.
ebIX role
Metered data aggregator (DEA)
Used by
Network owner reporting
aggregated time series,
including Svenska
kraftnt in this role
Reports to
Balance responsible
Supplier
Svenska kraftnt in the role Imbalance
Settlement Responsible
UTILTS-APERAK
Page 16 of 137
Ediel-guide
UTILTS & APERAK
Balance supplier (DDQ)
Balance responsible (DDK)
Imbalance Settlement
Responsible (DDX)
(DER)
Supplier
Balance responsible, including
Svenska kraftnt in this
role5
Svenska kraftnt

[Swedish:
Statistikinsamlare]
Supplier
Balance responsible
Network owner in the role Metered data
aggregator
-
3.1.3
Message types per phase
Current UTILTS message types are below listed per phase.
Planning
Message type
S02
S03
S04
Sender (responsible)
From network owner
(in the role
Metered Data
Responsible)
From network owner
(in the role
Metered data
aggregator)
Receiver
New supplier
From Svenska kraftnt

(in the role
Imbalance
Settlement
Responsible)
Balance responsible
Supplier
Balance responsible
Svenska kraftnt (in the role
Responsible)
Content
Consumption forecast per
object
Single values per object
Always SCH.
Preliminary load profile
shares/usage profile
shares/aggregated
monthly average power
Aggregated planning values
Always SCH.
Aggregated planning values
Always SCH (so far)
Request for UTILTS for planning (UTILTS-Request)

Message type
E73
Sender
Different parties
E74
Different parties
S06
Different parties
Receiver (responsible)
Network owner (in the role
Metered Data
Responsible)
Metered data
aggregator)
Responsible)
Content
Request missing validated
metered data (S02)
Request missing aggregated time
series (S03)
Request missing aggregated
settlement values (S04)
Reporting of metered values (E66, S07, E31 can also be used in the phase Settlement)
Message type
E30
Sender
(responsible)
From Metered Data
Collector
Receiver
Content

Metered Data
Collected data per object

Currently it is not a topic for Svenska kraftnt to use UTILTS in this role.
UTILTS-APERAK
Page 17 of 137
Ediel-guide
UTILTS & APERAK
E66
S07
E31
From network owner

(in the role
Metered Data
Responsible)
Is used in other
markets than
electricity and
gas for those
responsible for
the metered
values, e.g. the
one responsible
for metered
values for
district heating
From supplier
From network owner

(in the role
Metered data
aggregator)
Responsible)
Supplier
Metered Data
Responsible)
Producer
Svenska kraftnt (in the
roles System Operator
and Metered Data
Aggregator)
Energimyndigheten (in the
role Issuer of
Certificates)
TIM or SCH
Validated metered data per object
TIM or SCH.
Supplier
Producer
Balance responsible
Responsible)
Balance responsible
Supplier
Metered Data
Aggregator)6
Time series per object

TIM or SCH
Aggregated metered data, incl.
final load profile shares/usage
profile shares
Aggregated values
TIM or SCH
Request for UTILTS for report of metered values (UTILTS-Request)

Message type
E72
E73
Sender
Network owner (in
the role Metered
Data Responsible)
Different parties
E74
Different parties
Metered Data Collector
Content
Request missing collected data
(E30)

Metered Data
Responsible)
Metered data
aggregator)
Request missing validated

metered data (E66)
Request missing aggregated time
series (E31)
Settlement
Message type
S01
Sender (responsible)
From Svenska kraftnt (in
the role Imbalance
Settlement Responsible)
S05
From Balance responsible
Receiver
Network owner (in the
role Metered data
aggregator)
Balance responsible
Supplier
Content
Aggregated values for settlement
TIM or SCH (in the latter case
only to Balance responsible)
Aggregated values for settlement
TIM or SCH
Not used after July 1st 2009 according to regulations, is therefore used either by bilateral agreement or for the
transmission of metered data concerning the period prior to July 1st 2009.
UTILTS-APERAK
Page 18 of 137
Ediel-guide
UTILTS & APERAK
Request for UTILTS for Settlement (UTILTS-Request)

Message type
S06
Sender
Different parties
Responsible)
Content
Request missing aggregated
settlement values (S01)
For receivers marked with green you can find examples in the collection of examples.
3.1.4
EDIFACT version
All UTILTS message types are based on Message Handbook for ebIX - Implementation guide for Utility
Time Series Message (UTILTS), current version is specified in the UNH segment.
For current APERAK-versions, see chapter 5 APERAK.
3.2
UTILTS models
An UTILTS message is structured in the same way as other Ediel messages, the general information comes first, and then
the separate time series sent in different transactions. First is a general figure showing what is sent in a message header,
except for the transaction part that instead is described per different types of UTILTS messages. Detailed description of
what is to be sent in the different message type, is found in chapter 3.7 UTILTS attributes. Models for UTILTS-Request
and UTILTS-ERR can be found in the next chapter.7
Figure 6. The following information is generally included in a UTILTS header. 8
0..1 in the figures means zero or one occurrence. 0..* means zero or more occurrencies, and 1..* means one or more
occurrencies, etc.
8
Reason for transaction is not sent in the message header, but in the model it is located in the header since the information
is valid for the whole message.
UTILTS-APERAK
Page 19 of 137
Ediel-guide
UTILTS & APERAK
3.2.1
UTILTS S02 (consumption forecast per object)
Figure 7. The following information is included in an S02-transaction.
UTILTS-APERAK
Page 20 of 137
Ediel-guide
UTILTS & APERAK
3.2.2
UTILTS S03 and S04 (preliminary load profile shares/usage profile shares/aggregated monthly average power)
Figure 8. Since S03- and S04-messages are almost identical they can be described with the same figure. The difference is
that S03 is sent from a Network owner (Metered data aggregator), while S04 is sent from Svenska kraftnt. S04 also
lacks some information that (may) be present in S03, such as Balance Supplier.
UTILTS-APERAK
Page 21 of 137
Ediel-guide
UTILTS & APERAK
3.2.3
UTILTS E30 (collected data per object)
The message E30, like E72 request for E30, is only sent after bilateral aggrement between the metered data collector and
the network owner.
The information that differes between reporting from the metered data collector to network owner (Metered Data
Responsible) and the reporting from network owner to other actors is:
- Type of Metering Point (not sent by the metered data collector)
- Reference to PRODAT transaction (not sent by the metered data collector)
- Product code (not sent by the metered data collector)
- Unit measurement (not sent by the metered data collector)
- Meter reading quality (sent when needed also for meter readings from metered data collector)
- Energy volumes is not required, only meter readings can be sent
- Notice that the delivery period only is sent if there is a period.
- The resolution is only sent if energy values is sent
In the field Register id either the code from meter type list from Svenska kraftnts code list is used or a bilaterally agreed
code.
Figure 9. The information included in transactions (messages) when reporting metered values from metered data
collectors to network owners (Metered Data Responsible), i.e. E30.
UTILTS-APERAK
Page 22 of 137
Ediel-guide
UTILTS & APERAK
3.2.4
UTILTS E66 (validated metered data per object)
E66 messages with maximum power values, see figure 13, are only sent after bilateral agreement.
For E66 four figures [Class diagrams] are following.
Figure 10. Shows what is included in transactions (messages) for reporting of metered values from network owners
(Metered Data Responsible) with non-hourly metered facilities.
UTILTS-APERAK
Page 23 of 137
Ediel-guide
UTILTS & APERAK
Figure 11. Shows what is included in transactions (messages) for reporting of metered values from network owners
(Metered Data Responsible) with hourly-metered facilities
Notice the difference with the previous figure; the register with meter readings must not be present and that a meter
number isnt required for hourly-metered values. According to the regulations meter stands, and therefore also meter
number, should be sent for profiled settled installations. E66 with hourly values can also be used to report metered values
for regulating objects [station groups].
UTILTS-APERAK
Page 24 of 137
Ediel-guide
UTILTS & APERAK
Figure 12. Shows what is included in transactions with first meter registrations (only used in the gas market). Then no
volume is sent and only one meter reading, not two as in previous figures. Contract start date is sent after change of
supplier and Registration date is sent after Change of meter.
Transaktion
Transaktionsid
Anlggningsid
Ntomrdesid [1..2]
Avtal startdatum [0..1]
Registreringstidpunkt [0..1]
Anledning till transaktionen
Typ av anlggning
Referens till PRODA T-rende [0..1]
1
Produkt
Produkt id
Enhet
1..*
Register
RegisterId,
(rkneverkskod)
Mtarnr
1
Mtarstllning
Observationsnr
Mtarstllning
Datum fr mtarstllning
Mtaravlsare (k val)
Figure 13. Shows what is included in transactions with maximum power values from network owners (Metered Data
Responsible), only sent after bilateral agreement. If point in time for power value is specified one or more maximum
power values in the period may be sent, otherwise the maximum power value is valid for the whole delivery period.
UTILTS-APERAK
Page 25 of 137
Ediel-guide
UTILTS & APERAK
3.2.5
UTILTS S07 (time series per object)
S07 messages are sent from suppliers to other parties after bilateral agreement. The strucuture of the message is the same
as in E66 with energy volumes with the exception of the data element Transaction reference number [Reference to
PRODAT].
Figure 14. The following information is included in an S07 transaction
Transaktion
Transaktionsid
Anlggningsid
Ntomrdesid [1..2]
Leveransperiod
Upplsning
Registreringstidpunkt
Typ av anlggning
1
Produkt
Produkt id
Enhet
0..*
1..*
Energimngd
Observationsnr
Uppndd periodisk kvantitet
Kvantitetskvalitet [0..1]
Register
RegisterId
Mtarnr [0..1]
2..*
Mtarstllningar
Observationsnr
Mtarstllning
Mtaravlsare (kval)
3.2.6
UTILTS E31 (aggregated metered data, incl. final load profile shares/final usage profile shares)
Figure 15. The following information is included in an E31-transaction
UTILTS-APERAK
Page 26 of 137
Ediel-guide
UTILTS & APERAK
3.2.7
UTILTS S01 and S05 (aggregated settlement values)
Figure 16. Since S01- and S05-messages are almost identical they can be described using the same figure. The difference
is that S01 is sent from Svenska kraftnt while S05 is sent from Balance Responsible parties, and that Svenska kraftnt
never aggregates per Balance Supplier. Each observation consists either of energy volume, price or amount or
combinations of those items. What is sent depends on current time series product.
Note that a time series with amounts or prices may have several prices and/or amounts in separate currencies.
3.3
UTILTS-REQUEST (request missing time series)
The message is used after bilateral agreement.

When a party misses validated metered data for a specific delivery period and object, a request can be sent to the network
owner in the role Metered Data Responsible. This is done using UTILTS Request, message type E73. In the same way a
party that misses aggregated time series can send a request to the network owner in the role Metered Data Aggregator.
This is done using UTILTS-Request, message type E74. Likewise a network owner (Metered data responsible) can send a
request to the Metered data collector, this is done using UTILTS-Request, message type E72.
An actor missing aggregated settlement values from Svenska kraftnt in the role Imbalance Settlement Responsible, can
request them using UTILTS Request with the message type S06.
In an UTILTS Request only one type of message may be requested, you may not, e.g., in the same message request both
E66 and S02, but in each transaction (in SG6/RFF) through the whole message it is specified that you request the same
message type. You may also not request both hourly-metered values and non-hourly metered values in the same UTILTS
Request. Notice that UTILTS Request can be used by every actor that receive the requested message type, e.g. a request
for validated metered data per object can be sent both from network owners, balance suppliers, electricity/gas users and
Svenska kraftnt.
Metered values per object
UTILTS Request of the type E73 (request missing validated metered data per object) corresponding with E66 or S02, and
UTILTS Request of the type E72 (request missing collected metetered data per object), corresponding with E30 is used.
Aggregated time series
Request missing validated metered data for aggregated time series (E74), i.e. request of E31 or S03.
Request missing aggregated settlement values (S06) from Svenska kraftnt, i.e. request of S01 or S04.
UTILTS-APERAK
Page 27 of 137
Ediel-guide
UTILTS & APERAK
In an UTILTS-Request for aggregated values a Time series product must be specified. In addition to that network area(s),
balance responsible and supplier are specified when needed according to current Time series product.
For examples of E72-, E73-, E74 and S06-messages, see Appendix 3 and 5.
An answer to a UTILTS Request should be sent irrespective of exactly the same information already has been sent to the
receivier. APERAK and UTILTS ERR is sent in the same way as for other UTILTS messages.
3.3.1
UTILTS E72 and E73 (request missing collected/validated metered data per object)
Figure 17. The following is included in an E72- and E73-transaction respectively. Either Metering Point Id
(Anlggningsid) or Station group Id (Reglerobjectsid) is sent in E73.
3.3.2
UTILTS E74 and S06 (Request missing aggregated time series / aggregated settlement values)
Figure 18. The following is included in an E74- and S06-transaction respecitively.
UTILTS-APERAK
Page 28 of 137
Ediel-guide
UTILTS & APERAK
3.4
Negative UTILTS UTILTS-ERR (rejection)
UTILTS-ERR is a message type making it possible to reject a received original UTILTS message. The rejection is on a
process and functional level of the message (cfr APERAK that validates at technical level of this guide). I.e. the UTILTSERR message is, following ebIX-terminology, a Processability error report, while a negative APERAK is a Model error
report and a positive APERAK is an Acknowledgement of acceptance. Also notice that a negative CONTRL is a Syntax
error report while a positive CONTRL is an Acknowledgement of receipt, see further www.ebix.org.
UTILTS-ERR can be used for rejection of every other type of UTILTS messages, but not UTILTS ERR itself, i.e. also as
a rejection of an UTILTS-Request.
The rules how the original UTILTS message should be validated and what errors being a reason for rejection is described
in Appendix 2 Rules for UTILTS ERR Processability validation.
For example of an UTILTS-ERR message, see Collection of examples in Appendix 4 and 6.
General rules for UTILTS-ERR
Only erroneous UTILTS transactions are sent back in an UTILTS-ERR (i.e. do not send correct transactions), see
figure 19 for the relation between UTILTS and UTILTS-ERR.
UTILTS-ERR should be sent within 30 minutes from when the original message was placed at the receivers disposal.
APERAK should be requested in UTILTS-ERR.
UTILTS-ERR may not be sent as an answer to another UTILTS-ERR-message.
Only one UTILTS message may be rejected in a UTILTS-ERR-message, if several transactions are rejected the same
reference to the original message id must be specified in each UTILTS-ERR transaction.
You ought not to send several transactions in an UTILTS-ERR as answer to one transaction in a received message.
For a reference between original UTILTS and UTILTS-ERR, see UTILTS segment description.
Transaction/facility no 2 in UTILTS contains a processability error,

resulting in an UTILTS-ERR for trans/facility 2
UNB+
UNH+UTILTS
trans/facility 1
trans/facility 2
trans/facility 3
UNT+
UNZ+
UNB+
UNH+UTILTSERR
trans/facility 2
proc.error e
UNT+
UNZ+
Figure 19 Relations between UTILTS and UTILTS-ERR
UTILTS-APERAK
Page 29 of 137
Ediel-guide
UTILTS & APERAK
3.4.1
Model for negative UTILTS (UTILTS ERR) as answer to messages with metered values for single facilities
UTILTS-APERAK
Page 30 of 137
Ediel-guide
UTILTS & APERAK
3.4.2
Model for negative UTILTS (UTILTS ERR) as answers to messages with aggregated time series / settlement
information
UTILTS-APERAK
Page 31 of 137
Ediel-guide
UTILTS & APERAK
3.5
Some fields and terms in UTILTS
Below are some fields and terms used in UTILTS messages explained.
Message types and Ancillary role

As a rule in Ediel- (and ebIX-) messages one of the parties exchanging the message is the responsible one. E.g. the
network owner is responsible for his own metering information that he sends to balance suppliers, other network owners
etc. In this case the recipients have the ancillary role.
For example it is Svenska kraftnt that is responsible for settlement messages of the type S01, while Balance responsible
parties are responsible for settlement messages of the type S05. A balance responsible company, a balance supplier or a
network owner can never be responsible of a message type that a system operator is indicated as responsible for.
The other party in a message exchange has an ancillary [secondary] role. E.g. the Balance supplier in an UTILTS E66
with metered values for invoicing has an ancillary role, while the network owner has the responsible role, the same applies
for UTILTS E73, request of E66, it is once again the network owner having the responsible role and the supplier having
the ancillary role.
In the UTILTS messages the exchanged message type gives the role of the responsible. In the field ancillary role,
therefore the role of the other party is specified. E.g. a responsible network owner can send load profile shares both to
Balance suppliers, Balance responsible parties and Svenska kraftnt who all has an ancillary role in the message
exchange. In chapter 3.1 it is specified which party that is responsible for a certain message type, the other actor in the
exchange has the ancillary role.
When receiving metered values for regulating objects Svenska kraftnt has the role EZ System operator. For other E66
messages sent to Svenska kraftnt the role DEA Metered data aggregator (to Svenska kraftnt as Network owner) should
be used unless something else has been agreed upon between the parties.
Aggregating on companies
In an UTILTS message it is specified explicitly who is Balance responsible, who is Balance supplier etc. For time series
regarding exchange between two companies, typically one buying from the other, the codes for Buyer and Seller, are used.
9
3.5.1
Time series product
A Time series product describes what type of time related values (time series) that is used at exchange or presentation of
data. Example of a time series product is Hydro power production per network area and Balance responsible, reported
by the network owner. Another example is Balance power, production per constraint area and Balance responsible,
calculated and distributed by Svenska kraftnt.
Most Time series products concerns hourly values, but they can also describe data for a certain period of time, e.g. during
10 minutes, one month or during one year. A time series product can also refer to linked values, like a quantity, an amount
and a price, values then specified together for the same delivery period.
It is the time series product in combination with one or more identifers (e.g. network area and Balance responsible) that
becomes the time series reported, called Time series identity. A list of time series products can be found, per market, at
the Ediel portal.
Every Time series product is classified with 5 keys which are specified in the PIA segment. The keys (codes) are having
three characters.
ProductCharacteristic (code PC in data element 7143), a main group, e.g. production, consumption, supportive
power, (natural) gas etc.
ProductType (code PT), refers to another group within the main group, e.g. wind-power production, hydropower
production, metered losses, etc. These codes are not unique, in the electricity market, in the sense that they may
relate to different things depending on the ProductCharacteristic of the time series product. E.g. PC=Z01
(Production) + PD=Z02 refers to Wind Production (without information about number of metering points)
while PC=Z02 (exchange) + PD=Z02 refers to Export.
9
There may be exceptions, see current code list of Time series products.
UTILTS-APERAK
Page 32 of 137
Ediel-guide
UTILTS & APERAK
IdentityType (code OT), specifies which parameters that must be specified so that a specific time series of that
time series product could be defined. Five parameters are possible to specify
o object type
o area type 1
o area type 2
o actor type 1
o actor type 2.
The identity type also defines of which classification type (object-, area- or actortype) the parameters will have.
Examples of classification types are
o Object types: Metering points, Regulating objects [station groups]
o Area types: Network areas, Constraint areas, Control areas
o Actor types: Network owner, Balance responsible, Supplier, System operator
The parameters are used so that the identifiers correspond with:
o Object: the object identity if it is needed to specify the referred time series identity. E.g. metering point
id or regulating object id [station group id]
o Area 1: the area the time series refers to and from which perspective the values should be seen, i.e.
positive values means a flow into area 1.
o Area 2: used for exchange of flows.
o Actor 1: the actor that the time series refers to, and/or from which perspective the values should be seen,
i.e. positive values means a flow to actor 1.
o Actor 2: is used for exchages between actors and when the time series is referred to another actor (e.g. at
the relation between balance responsible and supplier).
LevelOfDetails (code LOD), refers to time resolution for the delivery period of the value. The most common is
hourly time series, which means that the type of time resolution is fixed hour (code Z55).
BusinessActivityPhase (code BAP), refers to the phase when the time series (data) is created or needs to be used.
The phase is used to make the time series unique depending on in which phase it is valid. A time series created in
the phase planning or metering/reporting, is then not the same time series as, given the same data, then is
created for e.g. resending, and is intended to be used in the phase settlement.
Normally a time series product only has one value per delivery period, but it may have several. If the Time series product
has several values and will be distributed with UTILTS it can normally only have one value per value type. E.g. one
quantity and one amount. There are also cases with several amounts in different currencies, but it is unusual.
Time series products are not used in the UTILTS-guide from ebIX but are a Swedish application. Therefore note that
LevelOfDetails (LOD) not is the same as the separate field Resolution (field 508). The LevelOfDetail is one key to define
the Time series products and making them unique, and has no immediate relation with the ebIX codes. The corresponding
applies for BusinessActivityPhase (BAP) and the separate field Phase (502). For example, time series with preliminary
load shares are always sent in the planning phase, but since the re-transmission of the corresponding time series from
Svenska kraftnt is needed first in the settlement, the phase in the time series product is "settlement", while the message is
sent in the planning phase.
When a Time series product is sent there is no separate identity of the time series itself.
For more information about Times series products, see the Ediel Portal, www.ediel.se.
Cfr examples in Appendix 6 APERAK and UTILTS ERR EDIFACT-examples for aggregated time series.
In each transaction there is also a genereic product code, often "Energy active". For time series including both an energy
volume and prices and/or amounts, the generic product code should specify the product valid for the "quantity", mostly
the energy volume. For prices the specified product code is the one for the item that the price is valid for, typically a
energy product when the price is "currency / energy". It is only when just amounts are sent in the transaction that the
generic product code for amounts can and should be used.
Read also in chapter 3.6.13 about Registration date/Latest update date.
3.5.1.1
Time series products in the natural gas market
The following differences apply in relation to the electricity market:
ProductCharacteristic (code PC in data element 7143). Here is only one code representing (natural) gas.
UTILTS-APERAK
Page 33 of 137
Ediel-guide
UTILTS & APERAK
ProductType (code PT). This code describes, in general what is sent. Examples: [in Swedish] "frbrukning
dygnsavlsta", "frbrukning mnadsavlsta", "inmatning till lager".
BusinessActivityPhase (code BAP). For the natural gas market mainly different codes are used compared with
the electricity market. The codes are as follows:
Z01
Planning/Trade [Planering/Handel]
Z06
Preliminary settlement [Preliminr avrkning] (in the electricity market the codes Z04
Metering/Reporting or Z05 Settlement are used)
Z07
Reconciliation [Slutavrkning] (in the electricity market the code Z05 Settlement is used)
For both daily read, monthly read and yearly read aggregated consumption, hourly values are sent, the same "LOD" code
(resolution) is then specified in the time series product. The different aggregation levels (e.g. per gas supplier or per
balance responsible) are separated with different OT-codes as in the electricity market. In the BAP code it is specified if
the values concern the preliminary or final settlement.
UTILTS-APERAK
Page 34 of 137
Ediel-guide
UTILTS & APERAK
3.6
UTILTS general rules
3.6.1
Summertime/Wintertime
Time zone is always specified in every UTILTS message. When sending Ediel-messages in Sweden always
Swedish standard time is used, i.e. UTC+1 all year round (the same rule as before in MSCONS).
3.6.1.1
Summer time/winter time in the natural gas market
The gas day always start at 06.00 the year around, expressed in current time, it means that when sending
messages during summer it will be 05.00 in the messages, i.e. 06.00 expressed in standard time (UTC+1). The
days of shifting (and the equivalent for longer periods of time) is handled in such away that during spring only
23 hourly values are sent, while in the autumn 25 hourly values are sent. The gas day of the last Saturday in
March thus includes, in the messages, the time period (Saturday) 06.00 until (Sunday) 05.00. While the gas day
of the last Saturday in October includes the time period (Saturday) 05.00 until (Sunday) 06.00.
3.6.2
Rules for date formats
Within Ediel and ebIX all time intervals are expressed using an inclusive start date/time and an exclusive end
date/time, cfr examples below.
Used date formats
Message date (field 205), Registration date (field 512), Latest update date (field 532), Processing date
[Tidpunkt fr effektvrde] (field 530b) and Meter reading date (field 530a)
Always specified as a point of time with time, example October 15, 2009 at 09.00 (am).
DTM+137:200910150900:203'
DTM+597:201012241455:203'
Delivery period (field 245) Examples

One year (resolution = year), e.g. January 15, 2010 up to and including January 17, 2011
DTM+324:201001150000201101180000:719'
A whole calendar month (resolution = month), e.g. January 2010:
DTM+324:201001010000201002010000:719'
A whole day and night (resolution = hour or day), e.g. the gas day January 2, 2010:
DTM+324:201001020600201001030600:719'
A whole day and night (resolution = hour), e.g. the day January 2, 2010:
DTM+324:20101020600201001030600:719'
A delivery period may never have the same end point as start point, e.g.
201012241500201012241500 is not allowed. When reporting UTILTS E30 and in some cases for the
natural gas market in E66 it is allowed to report a single meter reading, in such cases (where number
of observations is 1) no delivery period is sent.
Contract start date (field 210), is only used in the natural gas market after change of supplier when no
volumes are sent.
Always specified as a point in time with time stamp, example October 1st 2009, at 06.00
(am) (expressed as 05.00 in standard time).
DTM+92:200910010500:203'
Concerning allowed date formats in the different DTM-segments, see the segment description.
3.6.3
Sign direction
Rules for single metered values:
UTILTS-APERAK
Page 35 of 137
Ediel-guide
UTILTS & APERAK
The direction of energy in or out from a network area is concluded from what is decided as the source for the
exchange (netarea - source) and what is the recipient for the exchange (netarea - sink).
The source of the withdrawn energy (consumption) is always the grid, and the receiver (sink) is the
object (consumption facility), a metered value should be reported with positive sign.
The reported Network area (field 260a) then indirectly refers to source.
For input energy (production) the source is always the generator, and the receiver is the grid (sink),
metered values should be reported with positive sign.
The reported Network area (field 260a) then indirectly refers to sink.
For exchange points then it is the input grid for the energy that is the source, and the receiving grid
that is the sink, metered values should be reported with positive sign. Both Netareasource (field
260b) and Netareasink (field 260c) should be used. Two time series are reported in the electricity
market, one for each direction of the flow. For the natural gas market, see below.
Example 1: in an exchange point between grid A and grid B there are metered values for both energy
directions for a specific hour. The flow from A to B is 100 kWh and from B to A is 75 kWh. When
reporting one value is reported as AB = 100 and the other as BA = 75. Cfr also example in Appendix
3.
Example 2: in an exchange point between grid A and grid B there is only net metering. The flow for a
specific hour is from A to B 80 kWh, and therefore 0 kWh from B to A. During another hour the flow
from B to A is 20 kWh, and therefore 0 kWh from A to B.
Thus energy values always have positive sign, i.e. without sign. Other metered values for single facilities, like
temperature values, can on the other hand have both positive and negative sign.
Rules for aggregated metered values:
In to the grid source = positive = no sign

Out from the grid source = negative = negative sign
Example: Aggregated production values are always reported with + (no sign).
Aggregated consumption values, including load profile shares/usage profile shares and losses are always
reported with - (negative sign).
Aggregated exchange between settlement areas is reported with positive sign for input to the grid and with
negative sign for output (withdrawn) from the grid. The own network area is source the other one is sink.
Rules for settlement information:
The same rules apply as for aggregated metered values, with the addition that for bought energy
volumes (or similar) positive sign is used (no sign) and for sold, negative sign is used. And for
amounts expense negative sign is used, and for amounts income positive sign (no sign) is used.
This rule of sign means that if the actor specified as Buyer instead has sold the energy volume (or
similar) to the actor specified as Seller, the sign will be the opposite.
3.6.3.1
Sign direction, in the natural gas market
In the natural gas market the same rules apply as in the electricity market with the following difference.
In the electricity market two time series are reported with the flow in both directions at the exchange point
between grid areas. Since the gas actors are using reversing valves and the flow to day only goes in one
direction only one time series is sent between the gas actors with the flow to the following network. See
example 3b in the collection of examples, Appendix 3 UTILTS EDIFACT-examples per object. The values
are reported as hourly values in kWh(upper).
UTILTS-APERAK
Page 36 of 137
Ediel-guide
UTILTS & APERAK
3.6.4
Rules for number of decimals
The rules for number of decimals for energy values and meter stands (field 515, 516 and 517, see SG11/QTY) are as
follows:
- Energy for hourly-metered facilities should be reported in kWh with 0-3 decimals
- Energy for profile settled values (Resolution = year or month), like profile shares, should be reported in whole kWh
without decimals
- Aggregated energy values per hour should be reported in kWh with 0-3 decimals
- Meter stands for monthly (or yearly) read facilities should be reported as shown on the meters, without decimals, and in
whole kWh if the constant is 1.
- Meter stands for hourly read facilities should be reported with the resolution that the meter shows.
The rules applies on condition that bilateral agreements, business agreements, regulations or the Handbook say otherwise.
For the control of the difference between two meter stands and the energy volume, see Appendix 2 Rules for UTILTS
ERR Processability validation.
For percentages (usage profile shares) three decimals are used.
For prices at the most six decimals are used. Note that prices in messages are specified in for instance crowns per kWh
which means that prices with two decimals in re per kWh needs four decimals in Ediel messages, e.g. with the currency
Euro more decimals are needed.
For amounts at the most two decimals are used.
3.6.4.1
Rules for number of decimals in the natural gas market
In addition to the above rules the following applies for the natural gas market:
For usage profile shares, sent in percentages, it should be 0-3 decimals.
For volumes in cubic meter it should be 0-1 decimal.
For heating value it should be 0-3 decimals.
3.6.5
Quality control
The rules concerning report of corrected metered values are described in the Handbook (cfr item 2008:09 at
www.elmarknadsutveckling.se). The rules means in brief that the network owners always should notify updating of
metered values done after the reporting date according to the regulation (five weekdays), but also that corrections
regardless whether the quality get worse or is improved always should be able to be received and not rejected within
these five weekdays, unless it is a change of approved (first rate) metered values for single facilities, those should always
be notified.
The following rule is valid from October 1st 2013, see also item 2010:23 at www.elmarknadsutveckling.se:
Prerequisite: In cases where the sender, according to the Handbook, has an obligation to notify a correction of
(single or aggregated) values, typically revision of metered values considered as base values for charging, the
recipient should send a positive APERAK. This provided that Registration date / Last update date is newer
than the previously registred time and that no other errors are detected that causes negative acknowledgment.
This means that if the rules for notification are met, the recipient has no right to reject the UTILTS message
only because of that the notification did not arrive before the UTILTS message. See further the Handbook
regarding the rules about notifications. Note that a positive APERAK in this case doesnt mean that the
recipient has stored the meter readings. The receiver can wait to handle the new values until the notification
has arrived, but then no new acknowledgment should be sent, neither negative nor positive. Will there be errors
at this stage, the sender should be notified otherwise than through a negative Ediel acknowledgement.
3.6.6
The register of a meter has gone full circle
If a register of a meter has gone full circle this should not affect the volume beeing sent. Example:
A register of a meter has 6 digits. Previous meter reading is 999500. New meter reading is 000250. The energy
volume sent in the message is 750. No special status code (quality mark) is used in this situation.
3.6.7
Facilities with registers
Meter stands are reported in chronological order per register.
UTILTS-APERAK
Page 37 of 137
Ediel-guide
UTILTS & APERAK
If a facility has several registers (counters) all registers should be reported in the E30-, E66- or S07-messages,
i.e. if a facility has several registers the meter stands for one register is reported in chronological order, then
the meter stands for the next register, etc. Meter number is specified once per register.
See example 1c and 1d in the collection of examples per object. For a facility with registers metering high and
low load the meter type list codes 201 and 202 are used in the UTILTS transaction.
In E66- and S07-messages with metered values for non hourly facilities the meter type list codes from Svenska
kraftnt's code list is used as RegisterId.
For hourly metered facilities in E30, E66 and S07: RegisterId is only specified if meter stands are sent. Unless
other agreed upon bilaterally the meter type list code 901 is used from Svenska kraftnt's code list.
For non hourly facilities in E30 either the code from meter type list from Svenska kraftnt's code list is used,
cfr above, or a bilaterally agreed register id between the metered data collector and the network owner.
Note that the RegisterId sent in UTILTS E66 also is sent in the PRODAT message (Z04 and if necessary in
Z06 and Z10).
Note that the total energyvolume sent in the transaction must not be the same as the sum of the energy between
the meter stands (after considering the meter constant) since the energy in the separate registers doesn't need to
be independent parts of the total energy volume, but instead could overlap depending on the meter type list
codes.
When meter stands should be reported (may also occur for hourly metered facilities), but the meter stand is
missing, NULL should be specified as meter stand. The consumption (energy volume) will be estimated, and
the recipient will in this case not be able to compare the energy volume with the meter stands.
3.6.8
Grading [Quality]
All values being approved (first rate) should NOT have any status code for grading. So an absent status code
indicates that the value is correct. To be able specifying a worse quality than approved, like estimated
value, a status code for the estimated value is specified. Current status codes are as follows (see also the
SG11/STS segment): The codes below are given in a decreasing order of quality. If an energyvolume isnt
approved (i.e. there is a status code) depending on that the meter stand at the end of the period was estimated
(or missing) then also the next energy volume in the following period should have the same grading.
Single value
In S02 (Consumption forecast per object) no status code is specified for facilities where there are old metered
values used for the forecast. The status code 56 (estimated) is used in S02 when there are no historic values,
i.e. typically for new facilities.
In E66 (Validated metered data per object), as well as in S07 (time series per object) the field Origin of meter
stand is used for meter stands to specify if the meter stand is calculated or read by the network owner (or read
by the electricity/gas user). No status code is specified for meter stands in E66 or S07.
Status code
(according to ebIX)
No code is specified
125
56
21
46
Description
Approved (first rate) value
(Adjusted) Manually corrected value, only used in E30.
Estimated value
For quality flagging of meter stands in E66, se instead the field Origin of
meter stand (CCI/CAV).
For meter stands in E30 the code 56 can be used.
Temporary, the value has an uncertainty and will be replaced by a value
of better quality. Only used for hourly values in the imbalance
settlement.
See further comments below.
Missing value [Non existing value], used both for meter stands (in E30)
and energy values.
Notice that in this case the value field contains NULL.
UTILTS-APERAK
Page 38 of 137
Ediel-guide
UTILTS & APERAK
Aggregated metered value

No status codes are sent for load profile shares/usage profile shares. Regarding sending of aggregated hourly
values during the period weekday 1-5, see also below.
Status code
(according to ebIX)
No code is specified
56
21
113
46
Description
Approved (first rate) value. For load profile shares / usage profile shares
no status code is specified.
Estimated value, some underlying value has as worst this status or has
the code E28 (estimated by the network owner) in the field Origin of
meter stand.
Temporary, the value is uncertain and will be replaced by a value of
better quality; some underlying value has as worst this status.
Only used for aggregated time series in the imbalance settlement.
See further comments below.
Missing underlying value, some value is missing at the
aggregation. The code is a Swedish extension relative ebIX.
Missing value [Non existing value], if all underlying values
are missing.
Status 21, Temporary, is only used for hourly values in the imbalance settlement or for aggregated hourly
values in the imbalance settlement. Values with this status will always be replaced. For single hourly values the
following rules apply:
The status Temporary is used for uncertain and/or estimated hourly values that will be reported
again after collection of values. The value is preliminary and should always be updated and be
reported with better status when the metered values has been collected or established. This is done at
the latest weekday 5 after the measurement daty according to the regulation. I.e. the status is only used
in the period weekday 15 after the measurement day if the metered value was missing and was
replaced with the value from either a submeter or an estimated value. An hourly value first reported
with status Temporary, but not updated within 5 weekdays will not then automatically get the status
Estimated, it must first be replaced before it is sent with better status. See further the Handbook.
For status 56 Estimated the following rules apply for single metered values:
The status is used for stipulated metered valus not beeing actually read, i.e. if you did not succeed in
getting hold of a approved (first rate) metered value. A metered value reported with the status
Estimated should be an an equality with, and can be handled as, a metered value beeing reported as
Approved. For exampel, an Estimated metered value could be used in the billing the same way as
an Approved metered value. This means that the status Estimated never will be used for hourly
values that are preliminary and will be replaced. See further the Handbook.
For aggregated (summed) hourly metered values also applies the following rules:
During the period weekday 15 after the measurement day a new reporting can be made when there
are changes in the aggregation. The status of what is sent can then be better, the same or worse than
the previously sent values, this since the base for the aggregation may have been changed, e.g. it may
have been added an installation. During the period weekday 15 it is instead the values with the latest
update date that should be valid, a worse status during this period may not lead to a rejection of the
transaction. See also chapter 3.6.18.
The following table describes the codes separated into monthly-(yearly-) metered values and hourly metered
values:
UTILTS-APERAK
Page 39 of 137
Ediel-guide
UTILTS & APERAK
Grading (quality) for single metered values
Monthly-(yearly-) metered values
Hourly metered values
Order
Code Status
Order
Code Status
1
Approved
1
Approved
(First rate)
(First rate)
2
125
Manually
2
125
Manually
corrected
corrected
3
56
Estimated
3
56
Estimated
46
Missing
4
5
21
46
Temporary
Missing
Note
No code is specified.
Note: Only used in E30.
Estimated based on read meter stands or a
replacement meter.
See comments above.
Grading (quality) for aggregated metered values

Monthly-(yearly-) metered values
Hourly metered values
Order
Code Status
Order
Code Status
1
First rate
1
First rate
2
56
Estimated
2
56
Estimated
3
21
Temporary
113
Missing underlying value
113
Missing
underlying value
46
Missing
46
Missing
Note
No code in UTILTS.
One or more included measurements
have as worst this status.
have as worst this status.
have as worst this status, should not
occur since they according to the
regulation should be replaced before
sending.
All included measurements are
missing, should normally never occur
since they according to the regulation
should be replaced before sending.
Note that no grading is specified for prices or amounts, see chapter 3.2.7.
3.6.9
Change of meter
There are four types of change of meter; between two non hourly metered meters, between two hourly meters or between
these two types of meters. When changing from a non hourly meter the final meter stand should be sent to the supplier,
and then the following rule should be followed:
Previous meter stand, final meter stand and the volume in between should be sent in one transaction with Reason for
transaction = E88 = Billing Energy.
At change of meter in the electricity market the following rule for change to a non hourly meter is valid:
The following is sent: Start stand, meter stand at the next turn of month, the volume in between. This is sent in
one transaction with Reason for transaction = E88 = Billing Energy.
For both electricity and natural gas market the reference to the PRODAT transaction must be included in both
transactions, see further section 3.6.11.
At a change between two hourly meters the hourly metered values may be sent in the same transaction if the meter stands
isnt specified and at the same time no meter number is specified. Otherwise the metered values should be sent in separate
transactions according to the following rules:
At a change from an hourly meter the metered values in the UTILTS message from before the change should be
sent in a separate transaction. The field Reason for transaction is the normal at any other sending of metered
values for the installation, i.e. normally Billing Energy.
At a change to a hourly meter the metered values in the UTILTS message after the change should be sent in a
separate transaction. The field Reason for transaction is the normal at any other sending of hourly metered values
for the installation, i.e. normally Billing Energy.
At a change from a non hourly meter to a hourly meter or vice versa the transactions should be sent in separate messages.
The case when the PRODAT-message is sent after the UTILTS-transactions is described in The Handbook.
UTILTS-APERAK
Page 40 of 137
Ediel-guide
UTILTS & APERAK
3.6.9.1
Change of meter in the natural gas market
Specifically for the natural gas market, in addition to the above rules, the following rules apply:
At switch to a non hourly meter in the natural gas market one of the following two rules should be applied:
1) The following is sent: Start stand, no volume. This is sent in one transaction and not in the same message as the
final meter stand. Reason for transaction = E67 = Placement of meter. The field Registration date contains the
date of the change of meter. The message can be sent directly after the change of meter. This rule is only used for
yearly read metering points.
2) The following is sent: Start stand, meter stand at next turn of month, the volume in between. This is sent in one
transaction with Reason for transaction = E88 = Billing Energy.
Besides the final meter stand before the change of meter together with the volume is sent in another transaction, with
Reason for transaction = E88 = Billing Energy.
3.6.10 Reason for transaction
Each UTILTS message may only have one Reason for transation. E.g. you may not send both Periodic Meter Reading
and Billing Energy in the same message.
The field Reason for transaction is specified in every UTILTS message.
The following rules apply in different messages (for E30 and E66 se below).
E31: The code E44, Settlement, is used for messages in the balance settlement, code E43, Reconciliation, is used
for messages in the final settlement (load profile shares/usage profile shares).
S01: The code E44, Settlement, is used for messages in the balance settlement, code E43, Reconciliation, is used
for messages in the final settlement (load profile shares).
S02: The code Z01, Planning, is always used.
S05: The code E44, Settlement, is used for messages in the balance settlement, code E43, Reconciliation, is used
for messages in the final settlement (load profile shares).
S07: The code E23, Periodic meter Reading, is always used unless something else has been agreed upon between
the parties.
In UTILTS Request the following applies
The same code is used as the one that will be sent in the answer.
E72: See codes for E66 and E30 below.
E73: The code Z01 if UTILTS-S02 is requested, at request of UTILTS-E66 see below.
E74: The code E44 or E43 if UTILTS-E31 is requested, the code Z01 if UTILTS-S03 is requested.
S06: The code E44 or E43 if UTILTS-S01 is requested and the code Z01 if UTILTS-S04 is requested.
In UTILTS ERR the following applies
The same code is used as the one in the received message.
Rules for E66 and E30, and in E72 (request of E30) and in E73 (when E66 is requested)
A transaction only having one or more meter stands and no volumes is not used for billing. The Reason for transaction can
then not be Billing energy.
In the electricity market there are, for the moment, not sent any transactions in E66 without also an energy volume.
When sending E66s in the electricity market to electricity suppliers, to producers and to electricity users the code for
Reason for transaction should be E88 Billing energy unless something else has been agreed upon between the parties.
When sending E66s to other network owners (with metered values for exchange with other grid) the code for Reason for
transaction should be E44 Settlement, unless something else has been agreed upon between the parties.
When sending E66s to Balance responsible, to Issuer of Certificates and to System responsible the code for Reason for
transaction should be E23 Periodic Meter Reading unless something else has been agreed upon between the parties.
For E66 in the natural gas market, see the next sub chapter.
UTILTS-APERAK
Page 41 of 137
Ediel-guide
UTILTS & APERAK
For E30 the following rules apply both for the electricity and the natural gas market:
If energy volumes are sent the code for Reason for transaction should be E23 Periodic Meter Reading unless something
else has been agreed between the parties.
If only meter stands are sent, and no volumes, the following rules apply for Reason for transaction:
For end meter stand after change of supplier the code should be E20 End of supply.
For start meter stand after change of supplier the code should be E03 Change of Balance Supplier.
For end meter stand after change of meter the code should be E77 End of Metering.
For start meter stand after change of meter the code should be E67 Placement of Meter.
For meter stands after PRODAT Z06F giving two meter readings the codes in the two messages should be E24 Change of
meter characteristic (incl. meter change), last stand and E25 Change of meter characteristic (incl. meter change), first
stand respectively.
For a meter stand after a PRODAT Z06F giving one meter reading the code should be E64 Update of master data,
metering point, requiring meter reading.
The main rule if it is sent a volume is: if this volume is intended for billing then Reason for transaction should be Billing
Energy, in other cases the code Periodic Meter Reading is used. Are no volumes sent, but only single meter stands, then
specific codes are used according to the description above.
The codes in E72 (request of E30) and in E73 (request of E66) should be the same as the expected code in the answer
according to the rules above.
3.6.10.1
Reason for transaction, in the natural gas market
For UTILTS within the natural gas market the following rules apply for the field Reason for transaction.
Reason for transaction
Code Comments
E30 See 3.6.10 above
E31 Preliminary imbalance
Z02
For reporting at "Hour 10.30 After"
settlement
E31 Reconciliation
E43
For reporting at "Day 15 After"
E66 Billing Energy
E88
For normal reporting per exit point/entry point
E66 Settlement
E44
For reporting per exchange point (to another grid owner)
E66 Start meter stand after
E03
See comments below.
Change of Balance Supplier
E66 Start meter stand after change E67
If the meter stand is sent after the next turn of month the same rules as in
of meter (Placement of
the electricity market are used and no start meter stand is sent. For yearly
Meter)
read metering points on the other hand, start meter stands are sent, see
further chapter 3.6.9.
S01 Preliminary imbalance
Z02
For reporting at "Hour 12 After"
settlement
S01 Preliminary imbalance
Z02
For reporting of preliminary heating value "Day 25 Before"
settlement
S01 Reconciliation
E43
For reporting "Weekday 3 after" or later, i.e. even "Day 15 After"
S03 Planning
Z01
For reporting "Day 15 Before"
S04 Planning
Z01
For reporting "Day 25 Before" (except for preliminary heating value which
is sent in S01, see above.)
S05 The same rules as for S01
S07 Periodic meter Reading
E23
Used if nothing else is agreed upon between the parties.
Reporting of start meter stand after change of supplier
For yearly read metering points there will be two transactions after a change of supplier:
o One with the volume since last meter reading (Billing), sent directly after the meter reading.
o One with the start meter stand after the change of supplier (Change of Balance Supplier), without any volume.
It is sent directly after the meter reading. In this case the field Contract start date contain the date of the change of
supplier.
UTILTS-APERAK
Page 42 of 137
Ediel-guide
UTILTS & APERAK
For monthly read metering points the natural gas market follows the same routines as the electricity market. I.e. the first
message with the end meter reading is sent directly after the meter reading and the second message with the volume
between the change of supplier and the turn of the month is sent after the turn of month.
3.6.11 Reference to PRODAT transaction
For the recipient beeing able to store the information from the UTILTS transaction, sent as a consequence of a PRODAT
process, the PRODAT transaction need to be sent before the UTILTS transaction. In UTILTS E66 the field is required for
non hourly metered facilities when the UTILTS message can be linked to a PRODAT transaction. Even if the field in
some situations is required, no guide validation nor a processability validation should be done, i.e. no negative APERAK
is sent if the field is missing, no negative UTILTS (UTILTS-ERR) should be sent if the references doesnt match. In
UTILTS S02 the field may be used, but is not required.
If the transaction reference from the corresponding PRODAT process is known, that reference is specified in this field.
For example in the last UTILTS message for old meter or in the last UTILTS message to old supplier. If the transaction
reference is not known, the field must anyhow be filled in, then this a signal that the UTILTS transaction is linked to a
process where one or more PRODAT messages were sent to the recipient. In this case, the field contain the code P.
Examples of when then transaction reference may be missing in the senders system is at the first sending of metered values
a month after the change of supplier. The field will thus be filled in when the start- respectively the end date/time in an
delivery period (or a date/time for a single meter stand if no delivery period is sent) coinsides with Contract Start date,
Contract Stop date or Validity Start date in PRODAT, and when the UTILTS transaction is part of the same process, e.g.
after a change of meter and/or change of supplier. If the UTILTS transaction could be linked to two different concurrent
PRODAT transactions, e.g. both a change of meter and a change of supplier transaction, the code "P" should be used in
the field with the reference to the PRODAT transaction.
A UTILTS transaction, which is not linked to a PRODAT transaction may not contain the reference.
3.6.12 UTILTS after PRODAT Z06F
According to the Handbook and the PRODAT guide you should send UTILTS after a PRODAT Z06F where some of the
following has been changed:
1) Metering method [Measure method]
2) Settlement method [Method for balance settlement]
3) Constant
4) Number of digits, if the meter has gone full circle since the last meter reading
5) Counter codes [Meter time frame]
6) Installation status
UTILTS is only sent to the current supplier, not to possible future supplier(s).
In general the recommendation apply that after a meter reading, as a consequence of a PRODAT Z06F, the transaction is
sent a.s.a.p. with the energy volume between the previos meter stand (normally at the previous turn of month) and the
current meter stand. In every transaction where the previous or the latest meter stand is read as a consequence of
PRODAT Z06F a reference to the PRODAT transaction is sent for non hourly facilities.
The following recommendations apply for report of UTILTS after the different changes:
1) Change of Metering method
A change of metering method is normally done at turn of month, it implies a change from E66-T to E66-S or vice versa.
Two different messages must be sent according to the rules. If the change from E66-S to E66-T occurs in the middle of
the month, this means that the month isn't complete, i.e. the transaction in the first message will end at the change. If the
change from E66-T to E66-S is done in the middle of the month, the sending of hourly values will stop then. The first
E66-S message will then not comprise the whole month. In the E66-S message (current transaction) sent after the change
(to or from E66-S) there is a reference to the PRODAT transaction.
2) Change of Settlement method
A change of settlement method is not expressed in E66. You may not mix two settlement methods in one and the same
transaction. But you may send two different settlement methods in one and the same message as long as not two
different metering methods are used (either "E66-T" or "E66-S" is sent)
UTILTS-APERAK
Page 43 of 137
Ediel-guide
UTILTS & APERAK
Example 1: The settlement method is changed from non-profiled (hourly) to profiled. Hourly values are sent before and
after the change. Until the change, each day and night is sent in a separate transaction. After the change the transaction
may contain a whole month.
Example 2: The settlement method goes from profiled to non-profiled (hourly). Hourly values are sent before and after the
change. Until the change each month (or day and night) is sent in separate transactions. After the change each day and
night is sent in separate transactions.
If the settlement method is changed, and also the "resolution", see then case 1) Changed metering method.
No reference to the PRODAT transaction will be sent since hourly values are sent both before and after the change.
3) Change of Constant
The recommendation is to send a UTILTS transaction as soon as possible after the change, the first meter stand is
normally from the beginning of the month, the last (normally the second) meter stand is at the change. No constant is sent
in UTILTS messages. After the turn of month an UTILTS transaction is sent with the rest of the energy during the month
with the energy from the change until the turn of month. Both transactions have the reference to the PRODAT transaction
for non hourly facilities.
4) Change of Number of digits if the meter has gone full circle
The same recommendation apply as for change of Constant.
5) Change of Counter codes [Meter time frame]
The recommendation is to always send two transactions if the change occurs in the middle of the month. One with the
period before the change, the other with the period after the change. The recommendation is to send the first transaction as
soon as possible after the change, the second is sent after the next turn of month. Both transactions have the reference to
the PRODAT transaction for non hourly facilities.
Example: A change occurs May 11th, before the change the facility had two registers. After the change the facility only
have one register.
The first transaction covers the period May 1st to May 11th and has four meter stands plus one energy volume. I.e. as
example 1c in the collection of examples for the electricity market, appendix 3, but only for a part of the month.
The second transaction covers the period May 11th to June 1st and has two meter stands plus one energy volume. I.e. as
example 1b in the collection of examples for the electricity market, appendix 3, but only for a part of the month.
6) Change of Installation status
Meter readings are done at disconnections and reconnections. The recommendation is to send a UTILTS transaction after
each meter reading. In the examples it is assumed to be a electricity- or gas user and a supplier in the facility.
Example 1: A disconnection occurs April 27th and a reconnection April 29th results in three UTILTS transactions:
a) One with the meter readings April 1st and April 27th, sent as soon as possible after the meter reading.
b) One with the meter readings April 27th and April 29th, sent as soon as possible after the meter reading.
c) One with the meter readings April 29th and May 1st, sent as usual after turn of month.
Example 2: A disconnection occurs April 27th and a reconnection May 2nd results in four UTILTS transaction:
a) One with the meter readings April 1st and April 27th, sent as soon as possible after the meter reading.
b) One with the meter readings April 27th and May 1st, sent as usual after turn of month.
c) One with the meter readings May 1st and May 2nd, sent as soon as possible.
d) One with the meter readings May 2nd and June 1st, sent as usual after turn of month.
The transactions are of course sent in correct chronological order.
In every UTILTS transaction, where a meter reading linked to a PRODAT case are included, a reference to each
PRODAT transaction is sent for non hourly metered facilities.
In the above example 1 the first UTILTS transaction includes a reference to the PRODAT transaction with the
disconnection, the two latter UTILTS transactions includes the reference to the PRODAT transaction with the
reconnection. (Cfr case 2009:01 at www.elmarknadsutveckling.se.)
In the above example 2 the two first UTILTS transactions includes a reference to the PRODAT transaction with the
disconnection, the two latter UTILTS transactions includes the reference to the PRODAT transaction with the
reconnection.
UTILTS-APERAK
Page 44 of 137
Ediel-guide
UTILTS & APERAK
3.6.13 Changes/corrections and about registration dates/latest update date
Changes and corrections of master data are done using PRODAT.
Erroneous metered values are corrected through sending the corrected values.
For profile settled facilities only the corrected value is sent (normally only one value).
All transactions (messages) are labelled as original (BGM/1225=9). The code update (BGM/1225=5) is not in use,
but should be possible to receive.
All transactions are labelled with a Registration date or a latest update date.
The recipients system investigates the Registration date (or latest update date) in the transaction to decide if the
transaction concerns new or updated values.
In a correction or resending message the same Reason for transaction-code is specified as in the original message.
If a system creates a corrigendum transaction before the original transaction has been sent, the original transaction ought
to be removed in order to avoid the risk of handling them in the wrong order. If they would be sent in the same message,
the original transaction must come before the corrigendum transaction in the message.
More about registration dates and latest update dates
Registration date, or latest update date, is found both in the original messages as well as in corrections/updates. At
corrections a new registration date (latest update date) is sent telling when the new values arrived or were registered. The
recipient can then see on the registration date (latest update date) if it has arrived new values or not.
The difference between the fields Registration date and Latest update date is that the first only is specified in the
messages E30, E66 and S07. In other messages Latest update date is used. The two fields are having the same
functionality and when there is specified Registration date in this user guide this normally also applies for Latest
update date.
For metered values the registration date from the metering system is used, for example a meter stand from 11:34 has the
registration date 12:00.
If the value is missing, or when it was calculated (estimated/updated) the point in time when the estimated value was
registered in the Metered Data Responsibles database is used.
The current Registration date does not affect the date of the previous meter stand, that Registration date was sent in an
earlier message.10 If the previous meter stand will be changed a correction of the previous period will be sent and in that
correction message this updated meter stand will be the latest meterstand.
For aggregated values the latest registration date among the included values is used in the first place, in the second place
and for prognoses/preliminary load profile shares/usage profile shares it is the point in time when the aggregated value
was created (stored in the database) that is used. If the aggregated values has been changed, always a new (i.e. later) latest
updated date should be specified, regardless of whether the individual underlying values have changed or not (the change
may in the latter case depend on that the number of input data points have changed). 11
Consequently a new registration date (i.e. a latest update date) is registered in the database for corrected values.
When forwarding messages, e.g. by Svenska kraftnt to Balance responsible parties, the same registration date as for the
received values (aggregated or not) should be used, if possible.
In a time series with e.g. 24 aggregated metered values each value has on one hand a date and time that the value belongs
to. And on the other hand each metered value also has a date and time when the the value last was updated. This may be
the same for all included metered values, but also vary depending on the situation that one or sevaral underlying metered
values has been updated. It is the latest of these date and times when the aggregated metered values was updated that
should be specified in the field Latest update date, field 532.
One quality assurance that can be done before sending of the transaction is to check that the registration date/latest update
date always is the same or later as the end date and time of the transactions delivery period. This is however not valid for
preliminary load profile shares/usage profile shares/aggregated monthly average power (UTILTS S03, S04) nor the
10
For new facilities and for message to a new supplier where start meter stand, energy volume and end meter stand is sent
this means that no registration date for the start meter stand will be sent, other than the date the meter stand is valid for.
11
Concering the rules for registration date, see also case 2010:15 at www.elmarknadsutveckling.se.
UTILTS-APERAK
Page 45 of 137
Ediel-guide
UTILTS & APERAK
consumption forecast (UTILTS S02) where the delivery period is later than current date and therefore later than the latest
update date.
Corrections scenarios:
Daily reporting.
The first time one or more estimated/missing value(s) are reported. When better value(s) arrives the
following rule apply:
The whole day and night is resent in a separate transaction with a new registration date (earlier estimated/missing-flags are updated or removed). It is allowed to send several days in one message, but then each 24hour period should be put into separate transactions, i.e. the same as in the original messages. An E30
message without energy volumes may however comprise more than a day and night or single meter stands,
see further later section about transactions.
Monthly values missing value at turn of the month (one register).

By the first report (at the latest the fifth weekday or the tenth in the month according to rules in the
Mellan 20 jan och 15 maj

r mtvrdena otkomliga
eller mtaren (helt eller
delvis) frnkopplad
Mtvrde 1
20 jan
1 jan
Mtvrde
saknas sedan
den 20 jan
Trans 1
1 feb
Tr2
Null
1 mars
1 april
Mtvrde 2
15 maj
1 maj
Rapporteras senast 10/2
Tr 3 Null
Rapporteras senast 10/3
Tr 4 Null
Senast 10/4
Tr 5 Null
Mtvrde
har kommit
in den 15 maj
Tr2
Korr
1 juni
Tr 3 Korr
Tr 4 Korr
Tr 5 Korr
Rapportera en mnad
efter varje mnadsskifte
Senast 10/5
I juni rapporteras
Tr 6 med tre mtarstllningar: 1/5, 15/5 och 1/6
Tr 6
Figure 22 Example of reporting of missing metered values at turn of month

electricity market) there are two cases.
o There is no intermediate meter stand from within the period. Then the following is sent: the meter
stand at the previous turn of month and a missing meter stand at the latest turn of month (NULL
value). The energy is reported with a NULL value.
o There is an intermediate meter stand from within the period. Then the energy is separated into two
transactions. One transaction with the meter stand from the previous turn of month, the meter stand
from within the month, and the energy between these two meter stands. The next transaction
contains the meter stand from within the month, a missing meter stand at the latest turn of month
(NULL value). The energy in the period is reported with a NULL value.
If meter readings still are missing after subsequent turn of month(s) the reporting should be done as shown in
Figure 22. Which means that after each turn of month the latest month is reported, whether you have values
or not. Missing values means that meter stands (NULL) are specified both at the beginning and at the end of
the month together with the monthly energy (NULL).
When we later gets metered values the following three cases may occur:
o Case 1: The metered value for the 1st in the month is received, only the values for this month were
fully or partly missing. Now the remaining energy volume not sent in the previos sending is
UTILTS-APERAK
Page 46 of 137
Ediel-guide
UTILTS & APERAK
reported, i.e. the latest reported meter stand not beeing NULL and the meter stand at the latest
turn of month together with the energy in between (without status code, i.e. as approved).
o Case 2: A meter stand after the 1st of the month is received, only the energy for this month were
fully or partly missing. Then the meter stand at turn of month is interpolated and the following is
reported: The latest reported meter stand not beeing NULL, the interpolated meter stand at the
latest turn of month and the energy volume in between with the status code estimated. After the
next turn of month it is recommended that the meter stand from after the 1st of the month also is sent
besides the interpolated meter stand from the beginning of the month and the meter stand from the
end of the month. In this way the receiver will get both meter stands used in the interpolation.
o Case 3: Energy values for several months are missing. The first received meter stand is from a later
turn of month, i.e. more than a month has passed sinse the latest meter stand was received. Then
meter stand(s) are interpolated from the intermediate turn of month(s). The following is sent: The
latest reported meter stand not beeing NULL, the interpolated meter stand at the turn of the
following month, the energy in between with status code estimated. In separate transactions
estimated energy volumes and interpolated meter stands are reported for the remaining months. Se
example in figure 22.
A new registration date is specified in the transaction, this must be a registration date later than a previous
sent registration date for the same date for the meter stand, typically the date and time where this meter stand
was updated, or when this meter stand was interpolated12. See also example 1g, 1j and 1k in appendix 3.
Monthly values value from one register is missing (two registers).
In the first report there was missing a value from one of the two registers. This should be regarded as the
whole metered value is missing, NULL values are sent for both registers. When correcting the same rule
apply as in the scenario above.
Suppose that a meter stand at a turn of month is changed. This affects the energy both before and after the turn of month.
The energy values for both of the months are corrected and sent again in separated transactions. Subsequent metered
values and meter stands for the following months not being altered do not need to be resent. I.e. in general: at corrections
only months with affected metered values has to be corrected and resent.
Resending
Here is not described the resending of EDIFACT files, such can only be sent after an agreement. Instead the resending of
previously sent time series is described.
In practice the same rules apply here as for corrections.
At resending values for a longer period of time than has been reported in earlier message, the transactions in the new
message (the resending message) should contain the same period as the original transactions.
The transaction id in the resending message should be new, this since the acknowledgements uniquely should be possible
to link to correct sent transaction.
Example 1: During a period of time, it has daily been reported 24 hourly values. Now there is a resending of several of
these 24-hourly values in one single UTILTS message. Every such 24-hourly period must be sent in separate transactions
in the message (i.e. the same delivery period per transaction as in the original messages). The registration date (latest
update date) from the previous sendings is repeated in each transaction.
Example 2: During a period of time, it has monthly been reported monthly consumptions. Now there is a resending of
several of these monthly consumptions in one single UTILTS message. Every such month must be sent in separate
transactions in the message (i.e. the same delivery period per transaction as in the original messages). The registration date
(latest update date) from the previous sendings is repeated in each transaction.
12
The following example is therefore not allowed: At the first report (when the metered value was missing) the
registration date was of the fifth workday, when later a real metered value at the 1 st of month was received, the
registration date in the new transaction becomes the registration date of the metered value in the meter, i.e. the 1st of the
month.
In the latter sent transaction the registration date must be later than an earlier sent transaction, they may also not be
identical (e.g. in both cases, the 1st of the month).
UTILTS-APERAK
Page 47 of 137
Ediel-guide
UTILTS & APERAK
3.6.14 The reporting of metered values when interpolating and simultaneous change of supplier (if any)
The basic recommendation is to send the meter stands used in an interpolation, and that is from within the delivery period
sent. When the delivery period is sent, no meter stand may be outside this delivery period.
Example: The meter stand for October 1st is interpolated based on meter stands from September 29 th and October 3rd.
In the message, sent in the beginning of October, ther meter stands from September 1 st, September 29th and the
interpolated meter stand from October 1st (flagged with estimated by Network owner) are sent. The monthly energy
is sent as estimated (code 56). In the message sent in the beginning of November the interpolated meter stands from
October 1st, October 3rd and November 1st are sent, and the monthly volume is sent as estimated (code 56).
Note that there may be several meter stands within the same day and night, since an estimated meter stand very well can
be estimated based on a later reading the same day.
If a change of supplier occurs at the same time, the meter stands from the period before the switch is reported only to the
old supplier, and meter stands from after the switch is only reported to the new supplier.
Cfr also the preiovios chapter below Corrections scenarios and below under Transactions, delivery period
and resolution.
3.6.15 Representative
See the document Generell teknisk Ediel-anvisning [General technical Ediel user guide] at www.ediel.se.
3.6.16 Rules for UNB and addressing
See the document Generell teknisk Ediel-anvisning, which among other things describes rules for the UNB-segment and
rules about addressing.
3.6.17 Transactions, delivery period and resolution
An UTILTS message always contains one ore more transactions. Each transaction typically contains either meter stands,
energy volumes or both. When an (energy-)volume is sent the resolution of the volumes should be specified. The delivery
period should be specified if there is more than one observation in the transaction. The energy volume(s) comprises the
same time period as the delivery period, the resolution thereby specifies how the energy during the delivery period is
divided. This means that when the resolution covers the whole delivery period, only one energy value is sent, e.g. a
monthly value.
When both meter stands and energy volumes are sent, the energy volumes must be put into consecutive repetitions with no
interference of meter stands. I.e. it may not be sent some energy volumes, then a meter stand, then some other energy
volumes and there after another meter stand, in stead all energy volumes must be sent together. Energy volumes should
always be submitted in chronological order within the transaction. This also applies to meter stands for one or more
registers, see 3.6.7 above. The same meter stand with its meter reading date may not be sent several times within one and
the same transaction.
Resolution is not specified when only meter readings are sent. The delivery period may then comprise any period, such as
several months or several days. This is valid for E30 without energy volumes. Also for E66 (in the natural gas market)
with start meter stands no resolution is specified. When correcting E30 messages with only meter stands, single meter
stands can be reported even if an earlier E30 message did have several meter stands.
On the other hand when resolution is sent (i.e. when volumes is sent, which can occur also in E30) and when reason for
transaction is Periodic Meter Reading, Settlement, Reconciliation, Planning or Billing Energy the following
rules apply:
If settlement method is profiled and the delivery period is a month the resolution may be month, day, hour or
shorter. Example of this is a profiled settled exit point, where hourly values are reported monthly.
In other cases if settlement method isnt profiled:
o If Resolution is hour (or shorter) the delivery period should be at the most a day and night. Several
days may not be sent in the same transaction.
o If Resolution is day and night the delivery period should be day and night. Several days may not be
sent in the same transaction.
Further on the following rules apply for Resolution:
For Resolution year the transaction comprise an irregular period, i.e. the delivery period may include any number
of days (provided the rules in the Handbook and the regulation are followed).
UTILTS-APERAK
Page 48 of 137
Ediel-guide
UTILTS & APERAK
For Resolution month the transaction (the delivery period) covers a calendar month, only in connection with
moves, change of supplier, change of meter, meter reading after PRODAT Z06F or other readings in the middle
of the month when no read or estimated meter stand at the same time is sent at both turn of months (e.g. there is
no ordinary meter stand at the turn of month and no meter stand can be interpolated) then the transaction covers a
shorter period than a calendar month. See further chapter 3.6.13 for more cases whan a month isn't complete. The
resolution month is used for load profile shares/usage profile shares and for meters, read automatically and/or
when meter stands has been registrated or interpolated to 00:00 oclock (06:00 in the natural gas market) the 1st
in each month respectively.
For Resolution hour or day the transaction (the delivery period) covers a day and night, unless the time span
between possible meter stands is longer, then the transaction covers the same time period as the time span
between the meter stands, i.e. typically a calendar month (the frequency of reporting is month, but the metered
values sent are daily or hourly values). It is only if the meter is placed up or taken down in the middle of a day,
that the transaction covers a shorter period than a day and night. A transaction with hourly values without meter
stands then normally consists of 24 hourly values unless the reporting frequency following the Handbook may be
longer. This applies, for example, also for monthly reporting of hourly or daily values within the natural gas
market, e.g. if the Handbook specifies that daily values should be reported once a month the transaction may
include the whole month. A transaction with hourly values and meter stands consists of the number of hours
between the meter stands.
The resolution of the values is also, in a simplified form, found as a part of the field Application Reference. There -T is
used for hourly values and -S for monthly or yearly values. For daily values -T is used unless something else has been
agreed upon between the parties.
3.6.18 Number of transactions in a message, number of messages in an interchange etc.
It is allowed to
send several UTILTS-transactions in one single UTILTS-message (UNH-UNT).
send different settlement methods (hour or profile) in one UTILTS message, but only one type of
settlement method per UTILTS transaction.
send yearly and monthly resolutions in an UTILTS message, but only one resolution per UTILTS
transaction.
It is NOT allowed to
send different message types (BGM/1001) in one and the same UTILTS-message.
mix different phases (MKS/3496) in one and the same UTILTS-message.
send hourly-, and monthly/yearly resolution in one and the same UTILTS message (cfr Application
Reference in UNB).
send several different Reason for transaction in a message.
specify different facilities in one and the same UTILTS transaction, i.e. do only specify one facility
per UTILTS transaction. On the other hand several different facilities can be sent in the same
UTILTS message if they are sent in separate UTILTS transactions.
send several messages (UNH-UNT) in one and the same UTILTS exchange (EDIFACT envelope)
(UNB-UNZ).
specify different juridical recipients (NAD+MR) in one and the same UTILTS exchange (EDIFACT
envelope) (UNB-UNZ).
Since October 1st 2012 the rule is
you should always bundle transactions in only one message, that at a certain time is to be sent to a specific
recipient (juridical recipient in NAD), provided that for instance the rules are followed on the maximum
size of the message and the maximum number of transactions in a message.
3.6.19 Size limitations
The recommendation by Ediel is to restrict the size of an UTILTS-interchange (the whole interchange from
UNB to UNZ) to:
UTILTS-APERAK
Page 49 of 137
Ediel-guide
UTILTS & APERAK
maximum 1 Mbyte and

maximum 999 UTILTS-transactions (SG5/IDE).
The reason for restricting the number of UTILTS-transactions is to guarantee that the recipients system should
be able to work with, and validate all UTILTS transactions in an UTILTS message and send a corresponding
APERAK or a UTILTS ERR with references to all UTILTS transactions, within 30 minutes.
UTILTS for yearly metered facilities and when resending of information after July 1 st 2009, previously sent with
MSCONS
When UTILTS was put into service in 2009 it might happen that the message was used to report meter readings for
electricity facilities still read yearly. Similarly, UTILTS after July 1st 2009 was used to resend time series previously sent
with MSCONS, both meter stands and hourly time series.
3.6.20
For a yearly read facility there is as a rule, no automated system collecting values at the turn of month at 00.00. If a meter
stand must be established, interpolation is used where the energy is distributed proportionally over the period. In the field
resolution "year" is specified for all non-automatic read facilites, regardless of how long the total time period between the
meter readings are. It is only if the two meter stands (previous and latest) has been registrated or interpolated to 00.00
(06.00 in the natural gas market) at the first in each month, where it is allowed to use the resolution = "month". The
monthly volumes are sent in separate transactions.
At resending after July 1st 2009 of time series previosly sent with MSCONS, or at an earlier point in time when the
network owner has switched to sending all his time series with UTILTS the following rules apply:
- The E31-message is used between network owners (in the role Metered Data Aggregator) for
aggregated metered data between network areas. Is not sent according to the regulations for
metered data from after July 1st 2009, but could there after be used bilaterally.
- Registration date/latest update date, since the senders database not for certain has an
indication of registration date/latest update date before July 1 st 2009, the following transitional
rules applies for meter stands concerning dates before July 1 st 2009:
- follow in the first place, the rules for registration date in chapter 3.6.13.
- use in second place the latest known storage data / date of update among the sent metered
values in the transaction
- use in third place the time when the transaction was created (message date)
- use in the fourth place the latest time omong the included metered values, i.e. the end time in
the field Delivery period.
Note that Registration date/latest update date always is the same, or later than the end time in
the Delivery period.
- If the sender, when resending older metered values/settlement values (from before July 1st
2009), is missing the information about Number of Metering Points, and this according to the
rules should be sent, the value "0" is specified.
UTILTS-APERAK
Page 50 of 137
Ediel-guide
UTILTS & APERAK
3.7
UTILTS attributes
The tables below describe the information in each UTILTS message type.
The following status codes/classifications are used for specifying the usage in each message type:
R (Required)
- required information according to Ediel, the field should always be sent
D (Dependent) - conditional information, required in some circumstances, see terms in the column Notes.
O (Optional)
- optional information.
Field number and field name in the table are used as reference numbers in the segment description. The same numbers are also used in APERAK.
To get a clearer picture on how the different levels are repeated, read the table together with the segment description and the different examples in Appendix 3 and 5.
Notice that it doesnt matter in which order each observation comes, e.g. it doesnt matter if meter readings are reported before or after the energy volume as long as
meter stands always are sent together and not mixed with energy values.
3.7.1
Attributes in phase Planning
Current message types
S02, consumption forecast per object, sender = network owner (Metered Data Responsible)
S03, aggregated planning values, sender = network owner (Metered data aggregator)
S04, aggregated planning values, sender = Svenska kraftnt (Imbalance Settlement Responsible)
Field name English
Field name - Swedish
S02
S03
S04
Header information
311 Application Reference
Application Reference
312
Version
Dokumentnamn, kod
Dokument id
Meddelandefunktion
Kvittensbegran
R
R
R
R
R
R
R
R
202
203
204
313
Association assigned
code
Document name code
Document identifier
Message Function
Request for
Notes
EDIFACT-mapping
UNB/0026
For S02: should be 23-DDQ-S02-S

For S03: 23-DDQ-S03-S, 23-DDK-S03-S or 23-DDX203-S
For S04: 23-DDK-S04-S
For UTILTS in natural gas market the code starts with
27-.
Present version of the Ediel message.
R
R
R
R
UTILTS-message type: S02, S03, S04

Unique identity of the whole UTILTS message
Message function, see codes in BGM
Request for APERAK
BGM/C002/1001
UTILTS-APERAK
Page 51 of 137
UNH/S009/0057
BGM/C106/1004
BGM/1225
BGM/4343
Ediel-guide
UTILTS & APERAK
Field name English
205
Acknowledgement
Message date
206
501
502
207
S02
S03
S04
Notes
EDIFACT-mapping
Meddelandedatum
DTM+137/C507/2380
R
R
R
R
Date when the UTILTS-message was created in the

application, format according to DTM
Time zone is specified as an offset to UTC.
Electricty or Gas, see code in MKS
Current phase = planning, see code in MKS
Legal sender, Ediel-id
Time zone
Sector area
Phase/Domain
Sender
Tidzon
Marknad
Skede
Avsndare
R
R
R
R
R
R
R
R
208
Recipient
Mottagare
Legal receiver, Ediel-id
509
Ancillary Role
Underordnad roll
Code for the party not responsible for the message, in

these cases the role of the recipient, e.g. system
operator, balance responsible, etc.
Transaction level, repeated once or several times per

message (segment group 5)
505 Transaction id
Transaktionsnr
209
260a
Metering Point Id
Metering grid area
Anlggningsid
Ntomrdesid
R
R
R (see
note)
262
Balance Responsible
Balansansvarig
510
Balance Supplier
Leverantr
506
511
Product identification
Time series product
Produkt id
Tidsserieprodukt
R
-
R
R
R
R
The senders unique id of the transaction. Used for

referencing to a specific transaction.
Metering Point id, normally GS1-number
Network area id
S04: If/when it will be a question of sending aggregated
values with other things than load profile shares, the
field can be conditional depending on what is sent (the
time series product), alternatively a new message type
will be in use.
Balance responsible:
The condition if this field should be sent or not depends
on the current Time series product (OT).
Supplier:
The condition if this field should be sent or not depends
on the current Time series product (OT).
Generic product code, see codes in LIN
Time series product
Five codes are specified according to code list from
Svenska kraftnt, field 511a, 511b, 511c, 511d & 511e.
UTILTS-APERAK
Page 52 of 137
DTM+735/C507/2380
MKS/7293
MKS/C332/3496
SG2/NAD+MS/C082/303
9
SG2/NAD+MR/C082/303
9
SG2/NAD+role code
SG5/IDE+24/C206/7402
SG5/LOC+172/C517/3225
SG5/LOC+239/C517/3225
SG5/NAD+DDK//C082/30
39
SG5/NAD+DDQ//C082/30
39
SG5/LIN/C212/7140
SG5/PIA+1/C212/7140
(x5)
Ediel-guide
UTILTS & APERAK
Field name English
245
Delivery period
532
Latest update date
508
Resolution
223
264
226
Notes
EDIFACT-mapping
Current period of the transaction
Latest update date
SG5/DTM+324/C507/238
0
SG5/DTM+368/C507/238
0
SG5/DTM+354/C507/238
0
Unit measurement
Anledning till
transaktionen
Enhet
Resolution for the whole transaction,

e.g. month, format according to DTM
Reason for transaction = Planning
Specifies unit for the whole transaction.
Referens till PRODATrendereferens

Avrkningsmetod
254
Transaction reference
number
Settlement method
Can be used to link the UTILTS transaction with the

PRODAT transaction.
Profiled or Non-profiled
SG5/MEA+AAZ/C174/64
11
SG6/RFF+TN/C506/1154
513
Type of Metering Point
Typ av anlggning(ar)
507a
Number of Metering
Points
Antal mtpunkter
Observationsnr
[Position] Sequence number for each line, start always

at 1 and adjust upwards with 1 for each line
SG8/SEQ/C286/1050
Period Quantity
Planned
Meter reading quality
Planerad periodisk
kvantitet
Kvantitetskvalitet
SG11/QTY+135/C186/606
0
Diverging number of
Metering Points
Avvikande antal
mtpunkter
Planned energy volume (or load profile shares/usage

profile shares).
Required if the value in field 515 has lower quality than
approved. See codes in SG11/STS.
Specifies actual number of metering points for the
current observation. Only used if it diverge from field
507a above, the usage also depends on current time
series product (PC+PT). Used when reporting
aggregated time series. See further description in the
CAV-segment (SG12).
Observation
514 Observation id
515
520
507b
S02
S03
S04
Leveransperiod
Senaste uppdateringstidpunkt
Upplsning
Code for Consumption, Production or Exchange.

Is in UTILTS S03 always consumption.
Specify the default number of metering points.
Used when reporting aggregated time series, the usage
depends on current time series product (PC+PT). See
further description in the CAV-segment (SG7).
UTILTS-APERAK
Page 53 of 137
SG5/STS+7/C556/9013
SG7/CAV/C889/7111
below SG7/CCI+++E02
SG7/CAV/C889/7111
below SG7/CCI+++E12
SG7/CAV/C889/7110
below SG7/CCI+++Z01
SG11/STS+8/C555/4405
SG12/CAV/C889/7110
below SG12/CCI+++Z01
Ediel-guide
UTILTS & APERAK
3.7.2
Attributes phase Meter reading and Settlement
Single values
E30, collected metered data per object, sender = Metered Data Collector, phase = Meter reading.
E66, validated metered data per object, sender = network owner (Metered Data Responsible), phase = Meter reading
S07, time series per object, sender = supplier (Balance Supplier), phase = Settlement
Aggregated values
E31, aggregated metered data, sender = network owner (Metered data aggregator), phase = Meter reading and Settlement
S01, aggregated settlement values, sender = Svenska kraftnt (Imbalance Settlement Responsible), phase = Settlement
S05, aggregated settlement values, sender = Balance Responsible, phase = Settlement
Field name English
Field name Swedish
E30
E31
E66
S01
S05
S07
Header information
312
Version
Dokumentnamn, kod
202
code
Document name code
UTILTS-APERAK
Page 54 of 137
Notes
EDIFACT-mapping
For E30: should be 23-MDR-E30S or -T

For E31: 23-DDQ-E31-S or -T,
23-DDK-E31-S/-T, 23-DEA-E31T or 23-DDX-E31-S/-T
For E66: 23-DEA-E66-S or -T,
23-DDQ-E66-S/-T, 23-DEC-E66S/-T, 23-DDK-E66-S/-T, 23-PQE66-T or 23-EZ-E66-T
For S01: 23-DDK-S01-S or -T or
23-DEA-S01-T
For S05: 23-DDQ-S05-S or -T
For S07: 23-DDQ-S07-S or -T,
23-DEC-S07-S/-T or 23-DDKS07-S/-T
For UTILTS in natural gas market
the code starts with 27-.
Current version of the Edielmessage.
UTILTS-message type: E30, E31,
UNB/0026
UNH/S009/0057
BGM/C002/1001
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish
203
Document identifier
204
313
E30
E31
E66
S01
S05
S07
Dokument id
Message Function
Meddelandefunktion
Kvittensbegran
205
Request for
Acknowledgement
Message date
Meddelandedatum
206
Time zone
Tidzon
501
Sector area
Marknad
502
207
208
509
Phase/Domain
Sender
Recipient
Ancillary Role
Skede
Avsndare
Mottagare
Underordnad roll
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
Transaction level, repeated one or several times per

message (segment group 5)
505 Transaction id
Transaktionsnr
209
Metering Point Id
Anlggningsid
533
Station group Id
Reglerobjektsid
UTILTS-APERAK
Page 55 of 137
Notes
E66, S01, S05, S07
Unique identity of the whole
UTILTS message
Message function, see codes in
BGM
Request for APERAK
EDIFACT-mapping
BGM/C106/1004
BGM/1225
BGM/4343
Date when the UTILTS-message

was created in the application,
format according to DTM
Time zone is specified as an offset
to UTC.
Electricity or gas, see code in
MKS
Current phase, see code in MKS
Code for the party not responsible
for the message, in these cases the
role of the recipient, e.g. system
operator, balance responsible, etc.
DTM+137/C507/2380
The senders unique id of the

transaction. Used for referencing
to a specific transaction.
Metering Point id, normally GS1number. Used in E66 except when
metered values for Regulation
objects [Station groups] are sent.
Regulation objects [Station
groups]. Used in E66 when
metered values for Regulating
objects are sent. Used in S01
SG5/IDE+24/C206/7402
DTM+735/C507/2380
MKS/7293
MKS/C332/3496
SG2/NAD+MS/C082/3039
SG2/NAD+MR/C082/3039
SG2/NAD+role code
SG5/LOC+172/C517/3225
SG5/LOC+175/C517/3225
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish
E30
E31
E66
S01
S05
S07
260a
Metering grid area
Ntomrdesid
260b
Metering grid area

source
Ntomrde13
utmatning
260c
Metering grid area

sink
Ntomrde13
inmatning
262
Balance Responsible
Balansansvarig
510
Balance Supplier
Leverantr
524
Buyer
Kpare
13
Or another area like constraint area.

UTILTS-APERAK
Page 56 of 137
Notes
depending on the current Time
series product (i.e. when the time
series concerns a regulating
object).
Network area id (or other identity
of another area lika Constraint
area).
Optional in E30.
E66/E31/E30/S07: if fields 260b
and 260c are used (i.e. when field
513 = Exchange), then field 260a
should not be in use.
S01/S05: The usage depends on
the current Time series product
(OT).
Network area id for output.
Always sent together with 260c
Optional in E30
Else required if field 513 =
Exchange
Network area id for input.
Always sent together with 260b
Optional in E30
Else required if field 513 =
Exchange
Balance responsible
The usage depends on the current
Time series product (OT).
Supplier
Buyer
EDIFACT-mapping
SG5/LOC+239/C517/3225
SG5/LOC+232/C517/3225
SG5/LOC+233/C517/3225
SG5/NAD+BY//C082/3039
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish
E30
E31
E66
S01
S05
S07
525
Seller
Sljare
526
System operator
Systemansvarig
506
Produkt id
511
Time series product

not used within ebIX
Tidsserieprodukt
245
Delivery period
Leveransperiod
512
Registration date
532
Latest update date
508
Resolution
Senaste
uppdateringstidpunkt
Upplsning
210
Contract start date
Avtal, startdatum
UTILTS-APERAK
Page 57 of 137
Notes
Seller
System operator
Generic product code, see codes in
LIN
Time series product
Five codes are specified according
to code list from Svenska kraftnt,
field 511a, 511b, 511c, 511d and
511e.
Current period of the transaction.
Is specified in E30 and E66 if
number of observations > 1, i.e.
when more than single meter stand
is sent.
Registration date for the reported
values
Always specified in E66 unless a
start meter stand is sent after
change of supplier, then the
Contract start date is specified.
Latest update date for reported
values.
Resolution for the whole
transaction, e.g. month, format
according to DTM.
Is specified in E30 and E66 when
energy volumes are sent.
Date for start of supplying, only
EDIFACT-mapping
SG5/NAD+SE//C082/3039
SG5/NAD+EZ//C082/3039
SG5/LIN/C212/7140
SG5/PIA+1/C212/7140
SG5/DTM+324/C507/2380
SG5/DTM+597/C507/2380
SG5/DTM+368/C507/2380
SG5/DTM+354/C507/2380
SG5/DTM+92/C507/2380
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish
E30
E31
E66
S01
S05
S07
223
Anledning till
transaktionen
264
Unit measurement
Enhet
226
Transaction reference
number
254
Settlement method
Avrkningsmetod
507a
Number of Metering
Points
Antal mtpunkter
513
Observationsnr
Observation
514 Observation id
UTILTS-APERAK
Page 58 of 137
Notes
sent for start meter stands in
natural gas market after change of
supplier.
E30, E66, S07: see codes in
SG5/STS
E31, S01, S05: Settlement if
Settlement method = Nonprofiled and Reconciliation if
Settlement method = Profiled.
Specify unit for the whole
transaction. Not used in S01 or
S05 if only amounts are sent, the
usage depends on current Time
series product.
Is filled in when the transaction
belongs to a PRODAT transaction
for non hourly metered facilities.
See further section 3.6.11.
Profiled or Non-profiled, the
usage in S01 and S05 depends on
current Time series product.
Specify the default number of
metering points.
Used when reporting aggregated
time series, the usage depends on
current Time series product
(PC+PT). See further description
in the CAV-segment (SG7).
Consumption, Production or
Exchange
[Position] Sequence number for
each line, start always at 1 and
adjust upwards with 1 for each line
EDIFACT-mapping
SG5/STS+7/C556/9013
SG5/MEA+AAZ/C174/6411
SG6/RFF+TN/C506/1154
SG7/CAV/C889/7111
below SG7/CCI+++E02
SG7/CAV/C889/7110 below
SG7/CCI+++Z01
SG7/CAV/C889/7111
below SG7/CCI+++E12
SG8/SEQ/C286/1050
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish
527
Register id
224
E30
E31
E66
S01
S05
S07
RegisterId
Meter No
Mtarnummer
522
Monetary amount
Belopp
269a
Currency
Valuta
523
Price amount
Pris
269b
Currency
Valuta
UTILTS-APERAK
Page 59 of 137
Notes
EDIFACT-mapping
Register id
For meter stands in E66 for non
hourly metered facility the meter
type code from meter type-list
from Svenska kraftnt is used
(www.svk.se > Drift och marknad
> Verktyg fr branschaktrer >
Ediel > Anvisningar). For other
cases see SG8/RFF in section 3.9.
Is specified in E30, E66 and S07
when meter stands are sent.
Only specified once per register
(counter). Is then specified for the
first observation with meter stands.
Always specified in E30 and E66
when meter stands are sent.
Optional in S07. Is not used in E66
with maximum power value
(Normally a GIAI-number, see
appendix 7).
Amount, The usage depends on the
current Time series product. Note
that several amounts (with
different currencies) are possible
to send for one and the same time
series.
Currency code for field 522,
according to ISO
Price, the usage depends on the
current Time series product. Note
that several prices (with different
currencies) are possible to send for
one and the same time series.
Currency code for field 523,
SG8/RFF+AES/C506/1154
SG8/RFF+MG alt SE/

C506/1154
SG8/MOA+9/C516/5004
SG8/MOA+9/C516/6345
SG10/PRI/C509/5118
SG10/CUX+2/6345
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish
E30
E31
E66
S01
S05
S07
Notes
EDIFACT-mapping
according to ISO
Here each time series continues, separeted in single and
aggregated time series respectively
Time series for single metered values (E30, E66, S07)
Meter stands
517
Field name
English
Meter Reading
Field name
Swedish
Mtarstllning
530a
Meter reading date
520
Meter reading
quality
309
Origin of meter
stand
E30
E66
S07
Kvantitetskvalitet
Mtaravlsare
E30
E66
S07
Notes
EDIFACT-mapping
Meter stand, if meter stand is missing, NULL is

specified in the field. Used if meter stands are sent.
Date for meter reading.
Used if meter stands are sent.
Meter reading quality.
Required if meter reading value (field 517) has lower
quality than approved. See codes in SG11/STS.
Origin of meter stand [the reader of the meter]
Is specified if meter stands are sent. See codes in
SG12/CAV
SG11/QTY+220/C186/606
0
Notes
EDIFACT-mapping
Reached energy volume.

Is used if energy volumes are sent.
Required if the value in field 516 has lower quality than
SG11/QTY+136/C186/60
60
SG11/DTM+597/C507/23
80
SG11/STS+8/C555/4405
SG12/CAV/C889/7111
below SG12/CCI+++E22
Energimngd
516
520
Field name
English
Period Quantity
Reached
Meter reading
quality
Field name
Swedish
Uppndd periodisk
kvantitet
Kvantitetskvalitet
UTILTS-APERAK
Page 60 of 137
SG11/STS+8/C555/4405
Ediel-guide
UTILTS & APERAK
Maximum power value

Field name
English
Maximum Supplied
Quantity
Processing date
Field name
Swedish
Maxeffektvrde
520
259
521
530b
E30
E66
S07
Tidpunkt fr
effektvrde
Meter reading
quality
Kvantitetskvalitet
Meter Time Frame
Tidsintervall
Notes
EDIFACT-mapping
Maximum power value (in kilowatt)

Used if maximum power values are sent.
Used when the power value refers to a specific point in
time. Not in use if the power value is expressed as the
maximum power value for the whole delivery period.
Requierid if the value in field 521 has lower quality than
Meter time frame, specifying thet the power value is a
maximum-value. Valid code: E12 (Peak)
Used if maximum power values are sent.
SG11/QTY+42/C186/606
0
Time series for aggregated metered values (E31, S01, S05)

Energy volume aggregated values
The following group is reported for one or more time periods (segment group 11)
The group is not used when reporting prices or amounts. The status codes (R, D) are only valid for reporting of energy volumes.
516
520
507b
Field name English
Field name Swedish
Periodic quantity
reached
Meter reading quality
Uppndd periodisk
kvantitet
Kvantitetskvalitet
Diverging number of
Metering Points
(different from default)
Avvikande antal
mtpunkter
E31
S01
S05
Notes
Quantity
SG11/QTY+136/C186/6
060
SG11/STS+8/C555/440
5
Required if the value in field 516

has lower quality than approved.
Not used for load profile
shares/usage profile shares. See
codes in SG11/STS.
Specifies the actual number of
metering points, specified if the
number of metering points differ
from the default-number at the
transaction level (field 507a). Not
UTILTS-APERAK
Page 61 of 137
EDIFACTmapping
SG12/CAV/C889/7110
below
SG12/CCI+++Z01
SG11/DTM+597/C507/23
80
SG11/STS+8/C555/4405
SG12/CAV/C889/7111
below SG12/CCI+++E07
Ediel-guide
UTILTS & APERAK
used for aggregated hourly values.
The usage also depends on the
current Time series product (PC
and PT).
3.7.3
Attributes for UTILTS Request
E72
Request missing single collected meter values (E30) from Metered Data Collector.
E73
Request missing single validated metered values (E66 and S02) from network owner (Metered Data Responsible).
E74
Request missing aggregated time series (E31 and S03) from network owner (Metered data aggregator).
S06
Request missing aggregated settlement values (S01 and S04) from Svenska kraftnt (Imbalance Settlement Responsible).
Field name English
Field name Swedish

Requested
message type:
E72
E73
E74
S06
E30
E66
S02
E31
S03
S01
S04
Notes
EDIFACT-mapping
UNB/0026
BGM/C002/1001
Header information
312
Version
Dokumentnamn, kod
Dokument id
Meddelandefunktion
Kvittensbegran
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
UTILTS-message type: E72, E73, E74 or S06

Message function, see codes in BGM
Request for APERAK
205
code
Document name code
Document identifier
Message Function
Request for
acknowledgement
Message date
Should be the code valid for the requested

message, see chapter 3.7.1 and 3.7.2 above.
Current version of the Ediel message.
Meddelandedatum
206
501
502
207
208
509
Time zone
Sector area
Phase/Domain
Sender
Recipient
Ancillary Role
Tidzon
Marknad
Skede
Avsndare
Mottagare
Underordnad roll
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
202
203
204
313
UTILTS-APERAK
Date when the UTILTS-message was created in the

R
R
Electricity or Gas, see code in MKS
R
Current phase, see code in MKS
R
R
R
Code for the party not responsible for the
requested message, for UTILTS Request that
Page 62 of 137
UNH/S009/0057
BGM/C106/1004
BGM/1225
BGM/4343
DTM+137/C507/2380
DTM+735/C507/2380
MKS/7293
MKS/C332/3496
SG2/NAD/3035
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish

Requested
message type:
E72
E73
E74
S06
E30
E66
S02
E31
S03
S01
S04
Notes
EDIFACT-mapping
would be the senders role, e.g. balance supplier,

balance responsible, etc.
Transaction level, repeated one or several times per message (segment group 5)
505 Transaction id
Transaktionsnr
R
R
R
209
Metering Point Id
Anlggningsid
533
Station group Id
Reglerobjektsid
260a
Metering grid area
Ntomrdesid
260b
Metering grid area

source
Ntomrde utmatning
The senders unique id of the transaction. Used for

referencing to a specific transaction.
Metering Point id, network owners id or GS1
(GSRN).
Always specified in E73 unless you request
metered values (E66) for a regulating object.
Regulating object.
Used in E73 and S06 if you request metered values
(E66 and S01 respectively) for a certain regulating
object.
Network area id
In E72 field 260a or 260b+260c is optional to use.
Field 260a is always used in E74 if S03 is
requested.
Field 260a or 260b+260c is used in E74 when an
E31 is requested depending on current Time series
product (OT).
Field 260a is used in S06 if S04 is requested.
Field 260a is used in E73 if S02 is requested.
Field 260a or 260b+260c is used in E73 if E66 is
requested.
Field 260a or 260b+260c is used in S06 if S01 is
requested depending on current Time series
product (OT).
Network area id for output
Always sent together with 260c
Required in E74 if 513 = Exchange
Not suitable in S06 if S04 is requested.
Not suitable in E73 if S02 is requested.
UTILTS-APERAK
Page 63 of 137
SG5/IDE+24/C206/7402
SG5/LOC+172/C517/3225
SG5/LOC+175/C517/3225
SG5/LOC+239/C517/3225
SG5/LOC+232/C517/3225
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish

Requested
message type:
E72
E73
E74
S06
E30
E66
S02
E31
S03
S01
S04
260c
Metering grid area

sink
Ntomrde inmatning
262
Balance Responsible
Balansansvarig
510
Balance Supplier
Leverantr
524
Buyer
Kpare
525
Seller
Sljare
526
System operator
Systemansvarig
506
511
Time series product
Produkt id
Tidsserieprodukt
R
-
245
223
Delivery period
R
R
R
R
R
R
R
R
503
Reference function
code not used within
Leveransperiod
Anledning till
transaktionen
Referens till
meddelandetyp
Notes

Network area id for input
Always sent together with 260b
Required in E74 if 513 = Exchange
Not suitable in S06 if S04 is requested.
Balance responsible
The usage depends on the current Time series
product (OT).
Supplier
product (OT).
Buyer
product (OT).
Seller
product (OT).
System operator
product (OT).
Generic product code, see codes in LIN
Time series product
Five codes are specified according to code list
from Svenska kraftnt, field 511a, 511b, 511c,
511d and 511e.
Requested time period for requested values
Reason for transaction = what to be sent in the
requested message
Reference to UTILTS-message type, E30, E31,
E66, S01, S02, S03, S04
UTILTS-APERAK
Page 64 of 137
EDIFACT-mapping
SG5/LOC+233/C517/3225
SG5/NAD+BY//C082/3039
SG5/NAD+SE//C082/3039
SG5/NAD+EZ//C082/3039
SG5/LIN/C212/7140
SG5/PIA+1/C212/7140 (x5)
SG5/DTM+324/C507/2380
SG5/STS+7/C556/9013
SG6/RFF/1153
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish

Requested
message type:
E72
E73
E74
S06
E30
E66
S02
E31
S03
S01
S04
Notes
EDIFACT-mapping
SG7/CAV/C889/7111
below SG7/CCI+++E02
SG7/CAV/C889/7111
below SG7/CCI+++E12
254
ebIX
Settlement method
Avrkningsmetod
Profiled or Non-profiled
513
Typ av anlggningar
Consumption, Production or Exchange
3.7.4
Attributes for UTILTS-ERR

Field name English
Header information
311
312
Association assigned code
202
Document name code
203
Document identifier
204
Message Function
313
Request for
acknowledgement
205
Message date
Field name Swedish
ERR
Version
Dokumentnamn, kod
Dokument id
Meddelandefunktion
Kvittensbegran
Notes
EDIFACT-mapping
R
R
R
R
R
R
Same as in the message acknowledged

Current version of the Ediel message.
UTILTS-message type: ERR
Message function, see code in BGM
Request for APERAK
UNB/0026
Meddelandedatum
Date when the UTILTS-message was created in the application, format

according to DTM
Electricity or Gas, see code in MKS (Same as in the message
acknowledged)
Current phase, see code in MKS (Same as in the message acknowledged)
Code for the party not responsible for the message, for UTILTS ERR that
would be the senders role, e.g. balance supplier, balance responsible, etc,
taken from the received message.
DTM+137/C507/2380
The senders unique id of the UTILTS-ERR-transaction. Used in an
SG5/IDE+24/C206/7402
206
501
Time zone
Sector area
Tidzon
Marknad
R
R
502
207
208
509
Phase/Domain
Sender
Recipient
Ancillary Role
Skede
Avsndare
Mottagare
Underordnad roll
R
R
R
R
505
Transaction id
Transaktionsnr
UTILTS-APERAK
Page 65 of 137
UNH/S009/0057
BGM/C002/1001
BGM/C106/1004
BGM/1225
BGM/4343
DTM+735/C507/2380
MKS/7293
MKS/C332/3496
SG2/NAD/3035
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish
ERR
209
Metering Point Id
Anlggningsid
533
Station group Id
Reglerobjektsid
260a
Metering grid area
Ntomrdesid
260b
Metering grid area

source
Ntomrde utmatning
260c
Metering grid area sink
Ntomrde inmatning
262
Balance Responsible
Balansansvarig
510
Balance Supplier
Leverantr
524
Buyer
Kpare
525
Seller
Sljare
526
System operator
Systemansvarig
Notes
APERAK answer for referencing to a specific transaction.
Metering Point id from received transaction. Should be specified in ERR
as answers to UTILTS with single facilities (not regulating objects).
Regulating object id from received transaction. Should be specified in ERR
as answers to UTILTS with regulating objects (answers to E66 or S01).
Network area id, same as in the received transaction.
Used in ERR if it can be found in the received transaction and the error
didnt occur earlier and made it impossible to specify the Network area id
in the response.
Network area id for output, same as in the received transaction.
in the response.
Network area id for input, same as in the received transaction.
in the response.
Same as in the received transaction.
didnt occur earlier and made it impossible to specify the Balance
Responsible in the response.
didnt occur earlier and made it impossible to specify the Balance Supplier
in the response.
didnt occur earlier and made it impossible to specify the Buyer in the
response.
didnt occur earlier and made it impossible to specify the Seller in the
response.
UTILTS-APERAK
Page 66 of 137
EDIFACT-mapping
SG5/LOC+172/C517/3225
SG5/LOC+175/C517/3225
SG5/LOC+239/C517/3225
SG5/LOC+232/C517/3225
SG5/LOC+233/C517/3225
SG5/NAD+BY//C082/3039
SG5/NAD+SE//C082/3039
SG5/NAD+EZ//C082/3039
Ediel-guide
UTILTS & APERAK
Field name English
Field name Swedish
ERR
Notes
EDIFACT-mapping
511
Time series product
Tidsserieprodukt
245
Delivery period
Leveransperiod
223
Anledning till
transaktionen
528
Transaction Response
Status code
Business Document
Acceptance Status code
Reference function code
Svarskod
didnt occur earlier and made it impossible to specify the System operator
in the response.
didnt occur earlier and made it impossible to specify the Time series
product in the response.
didnt occur earlier and made it impossible to specify the Delivery period
in the response.
didnt occur earlier and made it impossible to specify the Reason for
transaction in the response.
Always code 41 (rejected)
Avvisningsorsak
Reason for rejection
SG5/STS+41/C556/9013
Referens till
meddelandetyp
Referens till
meddelandeid
Referens till
transaktionsnr
Reference to UTILTS-message type, taken from BGM/C106/1001 in the

received message
Reference to original UTILTS message id (from UTILTS
BGM/C106/1004).
Reference to transaction number in received transaction from
IDE/C206/7402
SG6/RFF/1153
531
503
504
529
Reference to original
message
Reference to Business
Document
R
R
UTILTS-APERAK
Page 67 of 137
SG5/PIA+1/C212/7140 (x5)
SG5/DTM+324/C507/2380
SG5/STS+7/C556/9013
SG5/STS/C555/4405
SG6/RFF/1154
SG6/RFF+TN/1154
Ediel-guide
UTILTS & APERAK
3.8
UTILTS message diagram
The Message diagram below shows the whole standard EDIFACT message. Segments NOT in use in the Swedish guide
and/or in the ebIX Message Implementation Guide (MIG) are marked in yellow. Segments in use in the Swedish guide,
but not in ebIX MIG, are marked in green. Otherwise the Swedish guide follows ebIX unless something different is
specified in the segment description. The number of repetitions of the segments in the figure specifies the number that is
possible according to standard EDIFACT. The number of repetitions according to Swedish rules is specified in the next
chapter.
UNH
M 1
BGM
M 1
CNT
C 9
DTM
M 9
MKS
C 9
PRC
C 9
SG. 1
C 9
RFF
SG. 2
C 99
NAD
SG. 4
C 99
CUX
M 1
M 1
M 1
UNT
M 1
SG. 5
C 99999
DTM
RFF
SG. 3
DTM
STS
C 9
C 1
C 9
CTA
C 9
C 9
M 1
COM
C 9
SG. 5
C 99999
IDE
M 1
LOC
C 9
NAD
C 9
ALI
C 9
LIN
C 9
PIA
C 9
IMD
DTM
PRC
STS
AGR
MEA
FTX
SG. 6
SG. 7
C 9
C 9
C 9
C 9
C 9
C 9
C 9
C 99
RFF
C 99
CCI
M 1
M 1
DTM
CAV
C 9
C 99
SG. 8
C 999
SEQ
M 1
DTM
C 9
RFF
MOA
PCD
SG. 9
C 9
C 9
C 9
C 99
CCI
M 1
CAV
C 99
SG. 10 SG. 11
C 99
C 9
PRI
M 1
QTY
M 1
CUX
C 1
DTM
C 9
STS
C 9
SG. 12 SG. 13
C 99 C 9
CCI
M 1
PRI
M 1
CAV
C 99
CUX
C 1
Figure 23 Message diagram for the Swedish UTILTS
UTILTS-APERAK
Page 68 of 137
Ediel-guide
UTILTS & APERAK
3.9
UTILTS segment description
Below the segments in the UTILTS message are described segment by segment, from UNH up to UNT. The segments are
described in the order they occur in the message (according to the message diagram). The description of the UNB and
UNZ segments can be found in the documents Generell teknisk Ediel-anvisning and ebIX Common rules and
recommendations (www.ebix.org).
To know which segments/fields being required in each message type, and to get a clear picture on how the different
segments are repeated for different message types, read the description below together with the figures in chapter 3.2, the
list in chapter 3.7 UTILTS attributes and the different examples in appendices.
Explanations and abbreviations
In the Description column a connection is made to the current field number in the UTILTS table in chapter 3.7 UTILTS
attributes.
Status codes/classifications
M and R
= mandatory/required (must always be sent)
D
= dependent (see specific terms)
X and N
= not used (not sent)
Other abbreviations
DE
= Data element
Notice that the segment descriptions may end before the last not used data elements. For example the MKS segment
has an ending data element 1229 not included below. More not used data elements can for instance be found in the IDE,
NAD and LOC segments. At implementation of the UTILTS message in an EDI converter the complete message
according to UN/Cefact must be described to make a correct syntax control.
UTILTS-APERAK
Page 69 of 137
Ediel-guide
UTILTS & APERAK
UNH
Message Header
Data element
Type
Description
0062
an..14
Message reference
an..6
an..3
an..3
an..2
an..6
UTILTS
D
02B
UN
E5SE1B, field 312
M
M
M
M
M
R
S009
0065
0052
0054
0051
0057
MESSAGE REFERENCE
NUMBER
MESSAGE IDENTIFIER
Message type
Message version number
Message release number
Controlling agency
Example: UNH+1+UTILTS:D:02B:UN:E5SE1B'
Notes
0062: This message reference is set by the senders EDI system and can be seen as a technical message number. The
functional message number is sent in the BGM segment.
0057: Generic version number with the format Exyyzz, where x indicates the ebIX version, yy indicates ISO 2 letter
country code and zz indicates a national implementation guide version number. The Swedish implementation guide
version number indicates the year and revision of introduction where the revision could be either A (spring) or B
(autumn).
Example: guide version number 1B indicates year of introduction = 2011 and revision = B (autumn), i.e. the guide
is valid from autumn 2011.
UTILTS-APERAK
Page 70 of 137
Ediel-guide
UTILTS & APERAK
BGM
Beginning of Message
Data element
C002
DOCUMENT/MESSAGE
NAME
1001 Document name code
Type
Description
an..3
1131 Code list identification code

3055 Code list responsible agency
code
1000 Document name
C106
DOCUMENT/MESSAGE
IDENTIFICATION
1004 Document identifier
an..17
an..3
UTILTS Message type, field 202

R
E30 collected data per object
E31 aggregated metered data
E66 validated metered data per object
E72 request missing collected metetered data
per object
E73 request missing validated metered data
per object
E74 request missing aggregated time series
S01 aggregated settlement values
S02 consumption forecast per object
S03 aggregated planning values (preliminary
load profile shares/usage profile
shares/aggregated monthly average
power)
S04 aggregated planning values
S05 aggregated settlement values
S06 request missing aggregated settlement
values
S07 Time series per object
ERR negative UTILTS, rejection of received
UTILTS
SVK
Svenska kraftnt
D
260 ebIX
R
an..35
1056 Version identifier

1060 Revision identifier
1225
MESSAGE FUNCTION
CODE
an..9
an..6
an..3
4343
an..3
RESPONSE TYPE CODE
an..35
Document id, unique message number for the

UTILTS message, field 203.
Specified by the sender.
Function, field 204

5
Replace (Update) message
9
Original message.
Kvittensbegran, flt 313
AB
Message acknowledgement is
required
NA
No acknowledgement needed
N
N
R
Example: BGM+S02:SVK:260+SSA1234+9+AB', BGM+ERR::260+SV1234+9+AB'

Notes
1131: Code SVK is used for S01-S07.
1004: Document id should be unique over time for every application at the sender, sending UTILTS messages.
UTILTS-APERAK
Page 71 of 137
Ediel-guide
UTILTS & APERAK
1225: Always use the code 9 (original). The code 5 (replacement/update) should be possible to receive, but is not
sent in Sweden. A message with the code 5 may not be rejected.
4343: Since APERAK is required after an UTILTS, APERAK should always be requested and the code AB
always be specified in 4343. The code NA should however be possible to receive, a message with the code NA
may not be rejected.
UTILTS-APERAK
Page 72 of 137
Ediel-guide
UTILTS & APERAK
DTM
Date/time/period
Data element
C507
Type
DATE/TIME/PERIOD
2005 Date or time or period function an..3
code qualifier
2380 Date or time or period text
an..35
2379 Date or time or period format

code
an..3
Description
137
735
Message date
Offset from Co-ordinated Universal
Time (UTC)
Message date, field 205 (137)
Time zone, field 206 (735)
203
CCYYMMDDHHMM (137)
406
ZHHMM (735)
M
M
R
R
Examples:
DTM+137:201001011515:203'
DTM+735:?+0100:406'
Notes
Message date (137): For each message there must be a message date with the date when the message was created in
the sending application.
Time zone (735): Time zone (offset from UTC) for each dates/times in the message. Only one UTC-value per
message. In Sweden we use +0100. The UTC-value is specified in hours and minutes with preceeding plus (+) or
minus (-) sign. Notice: syntax rules require that plus signs (+) that not is a segment separator, must be preceded by
the release character (?).
UTILTS-APERAK
Page 73 of 137
Ediel-guide
UTILTS & APERAK
MKS
Market/sales channel information
Data element
Type
Description
7293
an..3
Sector area, field 501

23
Electricity supply industry
27
Gas supply industry
C332
SECTOR AREA
IDENTIFICATION CODE
QUALIFIER
SALES CHANNEL
IDENTIFICATION
3496 Sales channel identifier

code
M
an..17
an..17
an..3
Phase, field 502

E02
Meter reading phase
E03
Settlement phase
E04
Planning phase
260
ebIX
N
R
Example:
MKS+23+E02::260'
Noteringar
Phase specifies when the time series in the message are used, not when they may have been created.
3496:
For each message type the following codes are used:
E30
code E02 (meter reading phase)
E31
code E02 (meter reading phase) or code E03 (settlement phase)
E66
code E02 (meter reading phase) or code E03 (settlement phase)
E72
code E02 (meter reading phase) (=the code valid for E30)
E73
the code valid for the requested message
E74
S01
code E03 (settlement phase)
S02
code E04 (planning phase)
S03
S04
S05
S06
S07
ERR
the same code as in the original UTILTS
UTILTS-APERAK
Page 74 of 137
Ediel-guide
UTILTS & APERAK
SG2
NAD-RFF-SG3
NAD
Name and Address
Data element
Type
Description
3035
PARTY FUNCTION CODE

QUALIFIER
an..3
C082
PARTY IDENTIFICATION
DETAILS
3039 Party identifier
MR
Message recipient
M
MS
Document/message issuer/sender
Codes for ancillary role (field 509):
DDK
Balance responsible ([Swedish:]
balansansvarig)
DDQ
Balance supplier ([Swedish:]
leverantr)
DDX
Imbalance Settlement Responsible
(responsible for balance settlement Svenska
kraftnt)
DEA
Meter Data Aggregator (network
owner aggregated values)
DEC
Party connected to grid, i.e.
electricty/gas user or producer
DER
Market information aggregator
EZ
System operator ([Swedish:]
systemansvarig)
MDR
Metered data responsible (network
owner single values)
PQ
Issuer of Certificates (issuer of energy
certificates)
D
an..35
Ediel id or other identity for sender, field 207

M
(MS)
Ediel id or other identity for recipient, field 208
(MR)
SVK
Svenska kraftnt
D
260
ebIX
R
9
EAN (International Article
Numbering association) (GLN from GS1)
305
ETSO/EIC (ETSO Identification
Code)

code
an..17
an..3
Examples:
NAD+MR+11111:SVK:260'
NAD+MS+22222:SVK:260'
NAD+DDQ'
Notes
3035: Sender and recipient refer to the legal Ediel actor. Senders and recipients within the Swedish power industry
should be specified with an Ediel-id, if nothing else has been agreed bilaterally. Possible representative for messages
sent within the power industry may NOT be specified in this segment; instead it is specified in the UNB-segment as
sender and recipient of the whole interchange. For id:s of actors outside the Swedish power industry, like
electricity/gas users or foreign energy companies, GLN-numbers (GS1) are used in the first place. In the second
UTILTS-APERAK
Page 75 of 137
Ediel-guide
UTILTS & APERAK
place it is recommended that the receiver uses a representative which receives an Ediel-id that is specified both in
the NAD and UNB-segments.
C082 should be used for sender and recipient, but not for ancillary role.
3039: GLN-number (13 digit location number) from GS1 (EAN) or EIC-number according to ETSO can be used
after bilateral aggreement. If Ediel-id is used SVK should be specified in 1131 and 260 in 3055.
1131: Used if 260 is specified in 3055.
Segment should exist three times, one each for sender, recipient and ancillary role.
UTILTS-APERAK
Page 76 of 137
Ediel-guide
UTILTS & APERAK
SG5
IDE
IDE-LOC-NAD-ALI-LIN-PIA-IMDDTM-PRC-STS-AGR-MEA-FTXSG6-SG7-SG8
999
Identity
Data element
Type
Description
7495
an..3
24
C206
OBJECT TYPE CODE

QUALIFIER
IDENTIFICATION NUMBER
7402 Object identifier
an..35
Transaction identification
Transaction id, field 505
R
M
Example:
IDE+24+MD200205832134'
Notes
The segment group is sent 999 times in the message at the most, see furhter section3.6.19.
7402: Transaction id should be a unique id for the transaction from the senders application, independent of
application at the sender, used to link a response/rejection to the original UTILTS-transaction. The transaction id
should be returned in the response/rejection (in both APERAK and a possible UTILTS-ERR).
UTILTS-APERAK
Page 77 of 137
Ediel-guide
UTILTS & APERAK
SG5
LOC
999
Place/location identification
Data element
Type
Description
3227
an..3
172
175
239
232
233
C517
LOCATION FUNCTION
CODE QUALIFIER
LOCATION
IDENTIFICATION
3225 Location name code

code
Metering point ID
Station group Id
Metering grid area
Metering grid area source
Metering grid area sink
R
an..35
Metering Point id, field 209 (172)

Regulating object id, field 533 (175)
Network area id, field 260a, b, c (239, 232,
233)
an..17
an..3
SVK
9
89
260
D
R
Svenska kraftnt
GS1 (EAN), GSRN
Assigned by distributor (net-owner)
Ediel
Examples:
LOC+172+735999133300121655::9' alternatively LOC+172+ANLID33333::89'
LOC+239+TES:SVK:260'
Notes
The segment is always used in E30, E66, E72, E73, S02, S03, S04 and S07. In addition it is used in E74 when
requesting an S03. Further more it is used in E74 if it is relevant for the specified time series product in requested
E31. The segment can also be used in ERR, see rules in section 3.7.4.
In E31, S01 and S05 the segment is used only if it is relevant for the specified time series product (see code OT).
3225:
LOC+172: Metering point id according to GSRN (Global Service Relation Number), GS1 (EAN)-number, or with
the network owners own metering point id. Notice that a metering point id with GSRN-number should have 18
figures (i.e. the first four AI-figures, e.g. 8018, should not be sent). For more information about GSRN, see
Appendix 7 EAN-numbers for electricity meters and facilities..
The same metering point id sent in PRODAT Z04 is to be found in this field.
The field Metering point id could also, after bilaterally agreement, be used for an identity of metering points. E.g.
when agreed to report metered values for a metering point, that together with other metering points are included in
a facility, such as a facility for which PRODAT messages are sent.
LOC+175: Regulating objects are identified in a similar way as metering points, i.e. either with GS1 (EAN)number or with the network owners (or Svenska kraftnts) own identity.
LOC+232, 233, 239: Network area id is specified using three-character/-digit codes from Svenska kraftnt.
1131: required when 3227 = 232, 233 or 239
3055: The same code specified in PRODAT is used in UTILTS.
If metering point id/regulating object id is identified with GSRN, use code 9.
If metering point id/regulating object id is identified with the network owners (or Svenska kraftnts) own id, use
UTILTS-APERAK
Page 78 of 137
Ediel-guide
UTILTS & APERAK
code 89.
For Network area id, use code 260.
UTILTS-APERAK
Page 79 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
NAD
Name and Address
Data element
Type
Description
3035
PARTY FUNCTION CODE

QUALIFIER
an..3
DDK
Balance responsible [Swedish:]
balansansvarig)
DDQ
leverantr)
BY
Buyer ([Swedish:] kpare)
SE
Seller ([Swedish:] sljare)
EZ
systemansvarig)
C082
DETAILS

code
R
an..35
an..17
an..3
Ediel id for balance responsible, field 262

(DDK)
Ediel id for supplier, field 510 (DDQ)
Ediel id for buyer, field 524 (BY)
Ediel id for seller, field 525 (SE)
Ediel id for system operator, field 526 (EZ)
SVK
Svenska kraftnt
260
ebIX
R
R
Examples:
NAD+DDK+11111:SVK:260'
NAD+DDQ+22222:SVK:260'
NAD+BY+33333:SVK:260'
NAD+EZ+10000:SVK:260'
Notes
The segment is used depending on the aggregation criteria for current transaction. I.e. the time series product for the
transaction. The segment is then only used for aggregated time series and not for single series (the segment is not
used in E30, E66, E72, E73, S02, S07). If e.g. the network owner sends aggregated time series per supplier and
balance responsible the segment should occur twice.
Buyer and Seller are always specified together, the segment should then occur twice. The Buyer specifies who has
bought (or received) the energy volume (or similar) from the Seller.
System operator is specified as an alternative to balance responsible and/or supplier.
UTILTS-APERAK
Page 80 of 137
Ediel-guide
UTILTS & APERAK
SG5
LIN
999
Line item
Data element
Type
1082
1229
n..6
an..3
C212
7140
7143
1131
3055
LINE ITEM IDENTIFIER

ACTION
REQUEST/NOTIFICATION
DESCRIPTION CODE
ITEM NUMBER
IDENTIFICATION
Item identifier
Item type identification code
Code list identification code
Code list responsible agency
code
Description
N
N
R
an..35
an..3
an..17
an..3
GS1 (EAN) product id, field 506
GS1 (EAN)
R
N
N
R
Example:
LIN+++8716867000030:::9'
Notes
The segment is used for identifying products/services (generic code).
It is used for every message type, except in UTILTS E30, E72, E74, S06 and UTILTS-ERR.
7140: the following codes are valid:
8716867000016 (power active)
8716867000023 (power reactive)
8716867000030 (energy active)
8716867000047 (energy reactive)
8716867000054 (connection capacity)
8716867000061 (connection use)
8716867000078 (transport capacity)
8716867000085 (transport use)
8716867000139 (energy reactive capacitive)
8716867000146 (energy reactive inductive)
5410000100016 (natural gas)
7331507000013 (time) [tid]
7331507000020 (amount) [belopp]
7331507000105 (heating value) [vrmevrde]
UTILTS-APERAK
Page 81 of 137
Ediel-guide
UTILTS & APERAK
SG5
PIA
999
Additional Product Id
Data element
Type
Description
4347
PRODUCT IDENTIFIER
CODE QUALIFIER
an..3
C212
ITEM NUMBER IDENTIFICATION
an..35
an..3
an..17
an..3
Product Characteristic, field 511a

PC
SVK
Svenska kraftnt
260
ebIX
an..35
an..3
an..17
an..3
Product Type, field 511b

PT
SVK
Svenska kraftnt
260
ebIX
an..35
an..3
an..17
an..3
Identity Type, field 511c

OT
SVK
Svenska kraftnt
260
ebIX
an..35
an..3
an..17
an..3
Level of Details, field 511d

LOD
SVK
Svenska kraftnt
260
ebIX
an..35
an..3
an..17
an..3
BusinessActivityPhase, field 511e

BAP
SVK
Svenska kraftnt
260
ebIX
7140
7143
1131
3055
Item identifier
7140
7143
1131
3055
Item identifier
7140
7143
1131
3055
Item identifier
7140
7143
1131
3055
Item identifier
7140
7143
1131
3055
Item identifier
C212
C212
C212
C212
Code list responsible agency code




Additional identification
M
M
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
Example:
PIA+1+Z04:PC:SVK:260+Z78:PT:SVK:260+Z04:OT:SVK:260+Z55:LOD:SVK:260+Z04:BAP:SVK:260'
Notes
The segment is not used in UTILTS for single time series (E30, E66, E72, E73, S02 and S07), but only in
UTILTS-messages with aggregated time series, then it is required, including UTILTS-Request (E74 and S06). It
may also be used in UTILTS-ERR, see further rules in section 3.7.4. In the segment the time series product is
specified. All five parts of the time series product should be completed. See further the Ediel portal, www.ediel.se,
for more information. Identity Type was earlier called Object Type, thence the code OT.
The segment is not used in the UTILTS-guide from ebIX, but is a Swedish application.
UTILTS-APERAK
Page 82 of 137
Ediel-guide
UTILTS & APERAK
SG5
DTM
999
Date/time/period
Data element
C507
Type
DATE/TIME/PERIOD
code qualifier
an..35

code
an..3
Description
92
Contract start date
324
Processing period
368
Latest update date
354
Observation length (default)
597
Registration date
Contract start date, field 210 (92)
Delivery period, field 245 (324)
Resolution, field 508 (354)
Registration date, field 512 (597)
Latest update date, field 532 (368)
203
CCYYMMDDHHmm (92, 368, 597)
719
CCYYMMDDHHmmCCYYMMDDHHmm
(324)
801
number of years (354)
802
number of months (354)
804
number of days (354)
806
number of minutes (354)
M
M
Examples:
DTM+324:201001010000201002010000:719'
DTM+354:1:802'
DTM+354:60:806'
DTM+597:201012241455:203'
Notes
The segment is used in every UTILTS message, except for UTILTS ERR where the delivery period is used only if
it is present in the orgiginal message and the error didnt occur earlier and made it impossible to specify the
delivery period in the response.
Delivery period (324): Specifies the delivery period of the whole transaction. The from-date should be the earliest
existing date, and the to-date should be the latest date in the time series/observations within the transaction.
If you in an E30-message from the Metered data Collector to the Metered Data Responsible (Network owner) only
sends a single meter stand in a certain transaction no delivery period is specified.
Resolution (354): Always used for message types UTILTS-E31, S01, S02, S03, S04, S05 and S07.
Used in UTILTS-E30 and E66 when volumes are sent, cfr chapter 3.2.
Notice! Per hour is specified as per 60 minutes (since a format code for hour is missing in ebIX).
Registration date (597): Is specified in UTILTS_E30, S07 and E66, but not in UTILTS-E66 after change of
supplier in the natural gas market when only a start meter stand is sent and no volume.
Latest update date (368): Is specified in all other messages than those Registration date is specified in, but not in
UTILTS-Request nor in UTILTS-ERR.
Contract start date (92): Only used in the natural gas market in UTILTS E66 after change of supplier, when only
start meter stand is sent and no volume.
UTILTS-APERAK
Page 83 of 137
Ediel-guide
UTILTS & APERAK
SG5
STS
999
Status
Data element
C601
STATUS CATEGORY
9015 Status category code
code
C555
C556
Type
Description
an..3
7
E01

Answer
260
ebIX
an..17
an..3
STATUS
4405 Status description code
an..3
Response code, field 528 (E01)

41
Rejected
STATUS REASON
9013 Status reason description code
an..3
Reason for transaction, field 223 (7)

Reason for rejection, field 531 (E01)
SVK
260
ebIX

code
an..17
an..3
R
M
X
D
D
M
R
M
D
R
Examples:
STS+7++E23::260'
STS+E01::260+41+E50::260'
Notes
The segment is used for all message types.
9015: code 7 is used in all UTILTS transactions.
In UTILTS ERR both code 7 and code E01 are used, the segment is then repeated twice.
C601/3055: only used if 9015 = E01
4405: The repsonce code should in UTILTS-ERR always be 41 (Rejected). Response code is only used if 9015 =
E01.
9013 Reason for transaction (7):
Notice that you may not send different Reason for transaction within the same UTILTS-message.
Current codes for Reason for Transaction are:
- E23
Periodic Meter Reading
- E03
Change of Supplier
- E20
End of supply (only used in message type E30)
- E24
Change of meter characteristic (incl. meter change), last stand (only used in message type E30)
- E25
Change of meter characteristic (incl. meter change), first stand (only used in message type E30)
- E43
Reconciliation
- E44
Settlement
- E64
Update of master data, metering point, requiring meter reading (only used in message type E30)
- E67
Placement of meter
- E77
End of metering (only used in message type E30)
- E88
Billing Energy
UTILTS-APERAK
Page 84 of 137
Ediel-guide
UTILTS & APERAK
- Z01
Planning (used for the message types S02, S03 and S04)
- Z02
Preliminary imbalance settlement (only used in the natural gas market, and then only in message types
E31 and S01)
For detailed information about when different codes are used, see chapter 3.6.10.
9013 Reason for rejection (E01), is only used if 9015 = E01 and 4405 = 41:
For use of and current reasons for rejections, se Appendix 2 Rules for UTILTS ERR Processability validation
C556/1131:
Used if the code in 9013 is Z01 or Z02.
UTILTS-APERAK
Page 85 of 137
Ediel-guide
UTILTS & APERAK
SG5
MEA
999
Measurements
Data element
Type
Description
6311
MEASUREMENT PURPOSE
CODE QUALIFIER
an..3
AAZ
C502
MEASUREMENT DETAILS
C174
VALUE/RANGE
6411 Measurement unit code
Handling unit measurement
an..3
Unit, field 264

KWH
Kilowatt Hour
KVR
kvar (Kilovar)
KVA
KVA (kilo Volt Ampere)
KWT
kW (Kilowatt)
MAW MW (Megawatt)
3B
MJ (Megajoule )
GWH
GWh (Gigawatt-hour)
K3
kVArh (KiloVoltAmpere reactive
hour) - (also to be used for kVArh/h)
MWH MWh (Megawatt-hour)
E08
MW/Hz
MQH
Cubic meter per hour
MTQ
Cubic metre
E46
kWh/m3
D90
Cubic meter (net)
P1
Percent
SEC
Seconds
CEL
Degrees Celsius
R
M
Example:
MEA+AAZ++KWH'
Notes
The segment is used for all message types, except in UTILTS-E30, UTILTS-ERR and UTILTS-Request and also
not in UTILTS S01 or S05 if only amounts are sent, the usage depends on the current Time series product.
UTILTS-APERAK
Page 86 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG6
RFF-DTM
References
RFF
Data element
C506
REFERENCE
1153 Reference code qualifier
1154 Reference identifier
Type
Description
an..3
TN
an..70
Transaction reference number
M
M
Reference to original/missing/incorrect message

type, field 503
S01
UTILTS S01
S02
UTILTS S02
S03
UTILTS S03
S04
UTILTS S04
S05
UTILTS S05 (in UTILTS ERR)
S06
S07
E30
UTILTS E30
E31
UTILTS E31
E66
UTILTS E66
E72
UTILTS E72 (in UTILTS ERR)
E73
E74
Reference to PRODAT-transaction, field 226
D
(TN)
Reference to business document [transaction
number], field 529 (TN)
Reference to original message id [number],
field 504 (other codes)
Example:
RFF+TN:890123'
RFF+E66'
RFF+E31:205436160319'
Notes
The segment may occur in UTILTS-Request, (E72, E73, E74 and S06), UTILTS ERR, UTILTS E66 and in
UTILTS S02. In UTILTS-ERR the segment is repeated twice with reference both to message and to transaction.
1153: For references to a PRODAT-transaction or a reference to a transaction TN is specified. In other cases the
rejected (UTILTS-ERR) or requested (UTILTS-Request) message type is specified.
1154: Reference to PRODAT-transaction (TN). Should be filled in for non hourly metered facilities in E66 linked to
a PRODAT transaction, either with the transaction number from the PRODAT transaction, or with the code P. See
further section 3.6.11. In UTILTS S02 the line item reference number [transaction number] from the PRODATtransaction may be sent in this field. The field is not used in ebIX.
UTILTS-APERAK
Page 87 of 137
Ediel-guide
UTILTS & APERAK
1154: The code TN in 1153 is also used in UTILTS-ERR, but then for the reference to the transaction number (field
529), i.e. the reference to the original (rejected) UTILTS transaction. The reference number comes from the original
UTILTS IDE-segment.
1154: Reference to original message id (field 504). Required in UTILTS-ERR. Specify original UTILTS message
id, received from BGM/C106/1004 in the original rejected UTILTS message.
UTILTS-APERAK
Page 88 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG7
CCI-CAV
Characteristic/class ID
CCI
Data element
Type
Description
7059
CLASS TYPE CODE
C502
MEASUREMENT DETAILS
C240
CHARACTERISTIC
DESCRIPTION
7037 Characteristic description code an..17

code
an..17
an..3
R
E02
Settlement method ([Swedish:]
avrkningsmetod)
E12
Metering point type ([Swedish:] Typ
av anlggning)
Z01
Number of Metering Points
([Swedish:] Antal mtpunkter)
SVK
Svenska kraftnt
260
Ediel
D
R
Examples:
CCI+++E02::260'
CCI+++Z01:SVK:260'
Notes
This segment is always used together with the next segment (CAV) where the specific code or value for each
characteristic is specified.
The segment group is always used in UTILTS S01, S03, S05, S07, E31, E66, E73 and E74. It may also be used in
S04.
1131: Code SVK is used for Z01 (Number of Metering Points)
UTILTS-APERAK
Page 89 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG7
CCI-CAV
Characteristic value
CAV
Data element
C889
CHARACTERISTIC VALUE
7111 Characteristic value
description code
Type
Description
an..3
Settlement method, field 254

E01
profiled
E02
non-profiled
M
D
Type of Metering point(s), field 513

E17
consumption
E18
production
E19
combined
E20
exchange
code
description
an..17
an..3
260
an..35
Number of Metering points, field 507a
ebIX
N
D
D
Examples:
CAV+E01::260'
CAV+:::384'
Notes
Specifies the value for the characteristic according to the code in the preceding CCI-segment.
7111: Is used apart from for Number of Metering points.
E01 is used for final settlement, E02 for balance settlement
E17 is used for exit points (consumption facilities)
E18 is used for entry points (production facilities)
E19 is only used after agreement, used for facilities with both production and consumption where the time serias
are not separated.
E20 is used for exchange points.
3055: Is only used if 7111 is in use.
7110: Only used for Number of metering points. Specifies the default number according to structure information.
Only specified for aggregated time series. If the same facility belongs to one and the same supplier during two or
more separate periods during the month, the facility should anyway only be counted once. If the field is used or not
depends on the current time series product, e.g. not used when losses are included in the aggregated time series, e.g.
for consumption profiles. Used by net owners and for some time series products and recipients when Svenska
kraftnt reports back aggregated information, how ever not for total preliminary or total final load profile shares per
network area that Svenska kraftnt sends to Balance responsible parties.
UTILTS-APERAK
Page 90 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
SEQ-DTM-RFF-MOA-PCD-SG9-SG10SG11
99999
Sequence details
SEQ
Data element
Type
1229
an..3
C286
ACTION
REQUEST/NOTIFICATION
DESCRIPTION CODE
SEQUENCE INFORMATION
1050 Sequence position identifier
an..10
Description
N
Observation id, field 514
R
M
Example:
SEQ++1'
Notes
The segment is used in all UTILTS-messages, except in UTILTS-ERR and UTILTS-Request (E72, E73, E74, S06).
1050: Sequence number for each line, always start at 1 and adjust upwards with 1 for each line.
UTILTS-APERAK
Page 91 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
References
RFF
Data element
C506
Type
REFERENCE
an..3
an..70
Description
M
MG
Meter Unit number (if not GS1/EAN) M
SE
Meter Serial number (GS1/EAN)
AES
Register id
Meter number, field 224 (MG/SE)
R
Register Id, field 527 (AES)
Examples:
RFF+SE:123456789012345678' alternatively RFF+MG:M-133333'
RFF+AES:101'
Notes
Register Id (AES). For non hourly metered facilities in E66 and S07 the meter type list codes from from Svenska
kraftnts code list is specified, the meter type list can be found at www.svk.se > Drift och marknad > Verktyg fr
branschaktrer > Ediel > Anvisningar.
For hourly facilities in E30, E66 and S07: Register Id is specified only if meter stands are sent. Unless other agreed
upon the meter type list code (code 901) from Svenska kraftnts code list is used.
For non hourly metered facilities in E30 either a meter type list code according to the code list from Svenska
kraftnt is used, cfr above, or a bilaterally agreed register id between the metered data collector and the network
owner.
1153: For meter number, use either qualifier SE or MG.
SE should be used when the meter is identified according to GIAI (Global Individual Asset Identifier).
For more information about GIAI, see Appendix 7 EAN-numbers for electricity meters and facilities.
MG is used if other meter number than GIAI is used.
UTILTS-APERAK
Page 92 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
Monetary amount
MOA
Data element
C516
MONETARY AMOUNT
5025 Monetary amount type code
qualifier
5004 Monetary amount
6345 Currency identification code
6343 Currency type code qualifier

Type
Description
an..3
n..35
an..3
Amount, field 522

Currency code according to ISO 4217, field
269a, e.g.
SEK
Swedish crowns
NOK
Norwegian crowns
DKK
Danish crowns
EUR
Euro
Amount due/amount payable
an..3
an..3
M
M
R
R
N
N
Example:
MOA+9:456:SEK'
Notes
The segment is not used in the UTILTS-guide from ebIX.
Amounts can only be sent in message types S01 and S05 (settlement messages).
The use depends on the Time series product valid for the transaction.
Notice that more than one amount (different currencies) may be sent in one and the same transaction.
UTILTS-APERAK
Page 93 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
SG10
PRI-CUX
Price details
PRI
Data element
PRICE INFORMATION
5125 Price code qualifier
5118 Price amount
5375 Price type code
5387 Price specification code
5284 Unit price basis quantity
Example:
PRI+CAL:129'
Type
Description
an..3
n..15
an..3
an..3
n..9
an..3
CAL
Calculation price
Price, field 523
C509
R
M
R
N
N
N
N
Notes
Prices can only be sent in message type S01 and S05 (settlement messages).
The use depends on the Time series product valid for the transaction.
Notice that more than one price (with different currencies) may be sent in one and the same transaction.
UTILTS-APERAK
Page 94 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
SG10
PRI-CUX
Currencies
CUX
Data element
C504
Type
Description
CURRENCY DETAILS
6347 Currency usage code qualifier
6345 Currency identification code
an..3
an..3
2
Reference currency
Currency code according to ISO 4217, field
269b, e.g.
SEK
Swedish crowns
NOK
Norwegian crowns
DKK
Danish crowns
EUR
Euro
6343 Currency type code qualifier

6348 Currency rate
an..3
n..4
R
M
R
N
N
Example:
CUX+2:SEK'
Notes
The segment should always be sent after a PRI-segment.
UTILTS-APERAK
Page 95 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
SG11
QTY-DTM-STS-SG12-SG13
99
Quantity
QTY
Data element
C186
Type
Description
QUANTITY DETAILS
6063 Quantity type code qualifier
an..3
6060 Quantity
an..35
135
Period quantity planned
136
Period quantity reached
220
Meter Reading
42
Maximum supplied quantity
Reached energy volume, field 516 (136)
Planned energy volume, field 515 (135)
Meter reading, field 517 (220)
Maximum power value, field 521 (42)
an..3
M
M
Examples:
QTY+136:400'
QTY+220:45001'
Notes
The QTY-segment shall occur in the UTILTS messages E30, E31, E66, S02, S03, S04, S07, but not in UTILTSERR nor UTILTS-Request (E72, E73, E74, S06). In UTILTS S01 and S05 the usage depends on the current Time
series product, i.e. when only prices or amounts are sent in a transaction the QTY segment is not used.
6060: Rules for number of decimals, see section 3.6.4.
6060: Rules for direction/sign, see chapter 3.6.3 UTILTS general rules.
6060: Meter stand, if meter stand is missing the value NULL should be specified. For E30 then the code 46
(=missing value) is sent in the following SG11/STS-segment.
6060: Energy value, if energy values is missing (e.g. for a certain hour in a E30 message) the value NULL should
be specified and the code 46 (=missing value) be sent in the following SG11/STS-segment.
UTILTS-APERAK
Page 96 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
SG11
99
Date/time/period
DTM
Data element
C507
Type
DATE/TIME/PERIOD
code qualifier
an..35
code
an..3
Description
597
Registration date
M
M
Point in time for power value, field 530b (597) R

Point in time for meter reading, field 530a (597)
203
CCYYMMDDHHmm (597)
R
Example:
DTM+597:201005250000:203'
Notes
The segment is only used in E66 when meter stands are sent (field 530a) or in E66 with maximum power values when
the power value refers to a specific point in time (field 530b).
UTILTS-APERAK
Page 97 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
SG11
99
Status
STS
Data element
C601
Description
STATUS CATEGORY
9015 Status category code
code
C555
Type
STATUS
R
an..3
an..17
an..3
an..3
(Meter reading) quality
Meter reading quality, field 520

125 Adjusted (manually corrected)
56 Estimated ([Swedish:] berknat)
21 Temporary (temporary/uncertain)
113 Incomplete data ([Swedish:] saknat
underliggande vrde [i.e.] missing
underlying value)
46 Non existent ([Swedish:] saknas)
M
X
X
R
M
Example:
STS+8+113'
Notes
The segment specifies the quality of the value in the preceding SG11/QTY, field 6060, and it shall only be sent
when the quality of the value isnt read or exact, i.e. is not approved. See further Grading in chapter 3.6.8,
especially rules concerning aggregated values.
For meter stands the segment is only used in E30 (collected metered data per object), not in E66 (validated metered
data per object) nor in S07 (time series per object). For E66 and S07 a possible quality flag is specified for the
meter stand in the field Origin of meter stand, see below (CCI/CAV)
4405:
- code 125 (manually corrected value) may only be used in E30
- code 56 (estimated value) e.g. used in S02 when there is missing historical values or in E30/E66/S07 when for
example interpolated energy volumes are sent
- code 21 (temporary value) used for uncertain or non complete energy values (hourly values in the imbalance
settlement)
- code 113 (missing underlying value) used when a value is missing at aggregation. Not used within ebIX.
- code 46 (missing value) used when meter reading/energy value is missing (NULL in previous SG11/QTY+220)
UTILTS-APERAK
Page 98 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
SG11
99
SG12
CCI-CAV
Characteristic/class ID
CCI
Data element
Type
Description
7059
CLASS TYPE CODE
C502
MEASUREMENT DETAILS
C240
CHARACTERISTIC
DESCRIPTION
7037 Characteristic description code an..17

code
an..17
an..3
R
E07
Meter time frame, field 259
E22
Origin of meter stand, field 309
Z01
Number of Metering Points
([Swedish:] Antal mtpunkter), field 507b
SVK
Svenska kraftnt
260
Ediel
D
R
Example:
CCI+++E07::260'
CCI+++Z01:SVK:260'
Notes
Meter Time frame: Used only for Maximum power value
Origin of meter stand: Used to specify who has read the meter stand or if it is estimated.
Number of metering points: Only specified if the actual value used for the aggregated value differs from the one
specified in SG7 (the default value), and if the information may be specified according to the current time series
product (PC+PT).
1131: Code SVK is used for Z01 (Number of Metering Points)
This segment is always used together with the next segment (CAV) where the specific code or value for each
characteristic is specified.
UTILTS-APERAK
Page 99 of 137
Ediel-guide
UTILTS & APERAK
SG5
999
SG8
99999
SG11
99
SG12
CCI-CAV
Characteristic value
CAV
Data element
C889
CHARACTERISTIC VALUE
description code
Type
Description
an..3
Meter time frame, field 259

E12
Peak
M
D
Origin of meter stand, field 309

E26
Read by party connected to grid
E27
Read by Network owner (Metered
Data Collector)
E28
Estimated by Network owner
(Metered Data Responsible)
code
description
an..17
an..3
an..35
260
Ediel
Diverging number of Metering points, field

507b
N
D
D
Examples:
CAV+E27::260'
CAV+E12::260'
CAV+:::382'
Notes
Meter time frame: Used only for Maximum power value
Origin of meter stand [Swedish: Mtaravlsare]: Is always specified when meter stands are sent. The code E26 is
used only for non automatically read meter stands when the electricity/gas user (producer) has read the meter them
selves. The code E28 is used when the meter stands has to be calculated and it wasnt possible to read, typically
when interpolating. If the metered value is "NULL" the code E27 is used.
Diverging number of metering points: Only used if it is specified a default value for number of metering points in
SG7 and if it for current aggregation, when the value in SG11 was created, was used values from a diverging
number if metering points, then here the actual number of metering points is specified if it diverges from field 507a.
The usage depends on current time series product (PC and PT) and is for the present only specified for load profile
shares/usage profile shares.
UTILTS-APERAK
Page 100 of 137
Ediel-guide
UTILTS & APERAK
UNT
Message trailer
Data element
Type
Description
0074
n..6
Total number of segments in the message, from

UNH to UNT (UNH and UNT included)
Message reference, the same number as the
message reference in the previous UNHsegment.
0062
NUMBER OF SEGMENTS
IN THE MESSAGE
MESSAGE REFERENCE
NUMBER
an..14
M
M
Notes
This segment is mandatory according to UN/Cefact.
UTILTS-APERAK
Page 101 of 137
Ediel-guide
UTILTS & APERAK
4 Acknowledgements and error handling

As from UTILTS is introduced there will be several changes in the acknowledgements and error handling
compared to corresponding handling of MSCONS, DELFOR and other Ediel messages for reporting of
metered values. The changes only apply to UTILTS described in this document. For other Ediel messages, see
their separate guides. Read also the document Generell teknisk Ediel-anvisning and chapter 17 in
Elmarknadshandboken [1] [chapter 10 in the English translation of the Handbook note however that the
English translation is not up-to-date] for general rules about communication.
An UTILTS-message may have different types of errors and shall be validated by the receivers application at
different levels. If an error is found different types of acknowledgement messages / error reports are sent back
to the sender. The UTILTS message flow including the different acknowledgements, are described in figure
24.
Each transaction in the received UTILTS message should be acknowledged. If error was found, some
transactions will be acknowledged by negative APERAK, others with negative UTILTS (UTILTS ERR). Most
transactions, without errors, will be acknowledged with positive APERAK. The only case when a transaction is
not acknowledged is when there is a serious error in the received message so that no transaction can be dealt
with. In short the following applies for the various response messages.
1. EDIFACT syntax report (CONTRL) (required)
The CONTRL message should be created in the recipients EDI system and be automatically sent back to
the sender. The CONTRL message is a syntax validation at EDIFACT level and should be sent after
having received an EDIFACT message (exception: CONTRL should not be sent as answer to another
CONTRL). When the sender gets back a CONTRL he knows that the original sent message is the recipient
to hand.
2.
Application acknowledge (APERAK) and negative UTILTS (UTILTS ERR) (either response is required)
If an error is found in the header of a received UTILTS message, a negative APERAK is sent back as
answer to the whole UTILTS message.
If no errors are found then each transaction is checked in the UTILTS message. For each transaction three
things can happen:
a) Error is found when comparing with the guide, then a negative APERAK is created for that transaction.
b) Error is found when comparing with the Handbook or when storing into the database, then a UTILTSERR is created for that transaction.
c) No errors are found, then a positive APERAK is created for that transactions.
In both negative APERAK and in UTILTS-ERR it is allowed to acknowledge one or more transactions.
The recommendation is to stick together acknowledgements of the same type in a message to keep down
the number of messages sent, i.e. the acknowledgements created according to a), b) and c) above are sent
when all transactions have been processed. According to the recommendation we will get a maximum of
three acknowledgement messages (besides CONTRL) as an answer to one UTILTS message, regardless of
the number of transactions in the original message: maximum one positive APERAK, maximum one
negative APERAK and maximum one UTILTS ERR. See also case 2009:18 at
www.elmarknadsutveckling.se.
APERAK and possible UTILTS-ERR should be sent back to the sender within 30 minutes (from when the
original UTILTS-message was the recipient to hand).
Acknowledgements should always be requested, but negative response messages (negative APERAK, negative
UTILTS) should be sent when error occur regardless wheater the sender has requested acknowledgements or
not.
Rules for checking recevied UTILTS and creating APERAK and UTILTS ERR can be found in appendix 1
and 2 respectively.
UTILTS-APERAK
Page 102 of 137
Ediel-guide
UTILTS & APERAK
The receiver of the acknowledgements should check that every transaction from the original UTILTS message
is acknowledged. Either you receive one or several positive APERAK for the transactions or you receive
negative APERAK for some and UTILTS-ERR for other transactions. Notice that it isnt certain that it will be
sent APERAKs for all transactions.
UTILTS-APERAK
Page 103 of 137
Ediel-guide
UTILTS & APERAK
Figure 24 UTILTS message flow each transaction is acknowledged
UTILTS-APERAK
Page 104 of 137
Ediel-guide
UTILTS & APERAK
Explanation of figure 24, the sender sends an UTILTS-message.
1. The receivers EDI-system validates the received UTILTS message and sends back a CONTRL message. If the
CONTRL message is correct (positive) the received UTILTS message is sent on to the receivers application for
further validation and loading.
2.
If the CONTRL message reports an error (negative CONTRL) when it comes back to the sender, or if
it is missing within 30 minutes these error situations must be handled.
3.
When the UTILTS message has arrived to the receivers application (item 4-7):
4.
Negative APERAK is sent if error(s) are found in the header.
5.
The application deals with each transaction in the received UTILTS message on the basis of rules in
Appendix 1 Rules for APERAK Guide validation. For those transactions in which errors are
discovered one or more APERAK messages are sent back (one APERAK with response to all
erroneous transactions, or one APERAK per incorrect transaction). APERAK should be sent within
30 minutes.
6.
For those transactions where no errors were discovered in the guide validation the processability
validation is made on the basis of rules in Appendix 2 Rules for UTILTS ERR Processability
validation. For those transactions where errors are discovered there will be sent one or more negative
UTILTS, UTILTS-ERR messages, in return (one UTILTS-ERR with answers to all erroneous
transactions, or one UTILTS-ERR per erroneous transaction). UTILTS-ERR should be sent within 30
minutes. A UTILTS-ERR message may contain multiple transactions (negative UTILTS).
7.
If no errors are discovered in any transaction a positive APERAK will be returned. Either an
APERAK message with reply to all transactions, or an APERAK message per received transaction.
The recommendation is to follow the first option, in accordance with the figure, in order to keep down
the number of messages.
8.
The recipient of acknowledgements should ensure that all sent transactions in the sent UTILTS
message are acknowledged. If the APERAK messages reports errors or an UTILTS-ERR-message is
received, or if acknowledgements are missing after 30 minutes, this situation must be handled.
Notice that CONTRL also should be sent as an acknowledgement to APERAK- and UTILTS-ERR-messages, as well as
CONTRL and APERAK as answers to UTILTS-ERR-messages, however not included in figure 24. Nor is the answer to a
possible UTILTS Request include in the figure.Concerning rules for CONTRL see Generell teknisk Ediel-anvisning,
chapter 17 Kommunikation in Elmarknadshandboken [1] [chapter 10 in the English translation of the Handbook].
APERAK will also be sent in response to UTILTS-ERR. In the figure the two questions are made: "Asked for
CONTRL?" and "Asked for APERAK?", the request must be made. If the sender, for whatever reasons, hasnt asked for
an APERAK, the receiver anyhow ought to send that acknowledgement in return.
Regarding rules for APERAK, see the next chapter.
UTILTS-APERAK
Page 105 of 137
Ediel-guide
UTILTS & APERAK
5 APERAK
5.1
APERAK models
There are two versions of APERAK positive and negative APERAK. The following models show what is included in
each version of APERAK.
5.1.1
Positive APERAK
UTILTS-APERAK
Page 106 of 137
Ediel-guide
UTILTS & APERAK
5.1.2
Negative APERAK
UTILTS-APERAK
Page 107 of 137
Ediel-guide
UTILTS & APERAK
5.2
APERAK general rules
An UTILTS- interchange (UNB-UNZ) shall be replied at transaction level, unless it was an error in the header before the
first transaction, then one APERAK is sent as answer to the whole message In a positive APERAK all acknowledged
transactions (one or more) must be acknowledged with "OK". In a negative APERAK all acknowledged transactions (one
or more) must be acknowledged with an error code. An APERAK message may contain acknowledgements to all, some or
only one UTILTS-transaction. See further rules in Chapter 4.
Alt 1 All three transactions in UTILTS are correct, resulting in one or more APERAKs
UNB+
UNH+APERAK312
UTILTS-ref id24
ok
- ref-trans id1
ok
- ref-trans id2
ok
- ref-trans id3
UNT+
UNZ+
UNB+
UNH+UTILTS
id24
trans id1
resulterar i ett positivt
APERAK
trans id2
trans id3
UNT+
UNZ+
The top arrow shows how UTILTS and APERAK are linked together at message level.
(EDIFACT segment: BGM/1004 in UTILTS corresponds with SG1/DOC/1004 in APERAK).
The bottom arrow shows how UTILTS and APERAK are linked together at transaction level.
(EDIFACT segment: IDE/7402 in UTILTS corresponds with SG5/RFF+ACW/1154 in APERAK).
Alt 2 Transaction no 2 in UTILTS contains two errors, in this case resulting in two or three APERAKs
UNB+
UNH+UTILTS
id25
trans id4
trans id5
trans id6
UNT+
UNZ+
UNB+
UNH+APERAK313
UTILTS-ref id25
error x in field y
- ref-trans id5
error z in field a
- ref-trans id5
UNT+
UNZ+
UNB+
UNH+APERAK312
UTILTS-ref id25
ok
- ref-trans id4
ok
- ref-trans id6
UNT+
UNZ+
Figure 27 Relation between UTILTS and APERAK
UTILTS-APERAK
Page 108 of 137
Ediel-guide
UTILTS & APERAK
Negative APERAK may be created in a pre-system if such a system exists.
Every UTILTS transaction in an UTILTS-message shall be validated in two levels.
1. Guide validation [Model validation]
Validate that the rules in the technical guide (this document) are followed (required fields and correct codes). Description
of the Guide validation is found in Appendix 1 Rules for APERAK Guide validation.
The Guide validation shall primarily be made at message level. If one or more errors are discovered a negative APERAK
is sent back as answer to the whole UTILTS messege where erroneous fields are listed. No further checks are done. If the
validation of the message header is OK the validation goes further for every UTILTS transaction. The UTILTS
transaction is marked as correct or incorrect. Correct UTILTS transactions (correct according to the Guide validation)
shall go further to the processability validation. Erroneous UTILTS transactions are reported in APERAK with current
error code(s), and telling the field(s) having the error(s), see segment description.
2. Processability validation
Make sure to follow The Handbook regarding process and functional demands. Description of the Processability
validation is found in Appendix 2 Rules for UTILTS ERR Processability validation.
The Processability validation should be made for each UTILTS transaction that has passed the Guide validation. Correct
UTILTS transactions (correct according to the Processability validation) should be reported in APERAK as OK.
Erroneous UTILTS transactions are reported in UTILTS-ERR with appropriate reason for rejection, see further appendix
2.
Other APERAK rules:
A positive APERAK acknowledge that each referred UTILTS transaction has entered and been stored in the
recipients application.
When errors are found in the message header the whole received UTILTS message is acknowledged with a negative
APERAK message. Otherwise each transaction is acknowledged, either with a positive APERAK for UTILTS
transactions stored into the application, with negative APERAK after errors found in the guide validation or with
negative UTILTS (UTILTS ERR) after errors found in the processability validation. For each such type of
acknowledgement the transactions can be acknowledged separately or together per type, the recommendation is the
latter in order to keep down the number of messages sent.
For a reference between the original UTILTS message/transaction and APERAK, see APERAK segment description.
An APERAK may not contain references to both correct UTILTS transaction and erroneous UTILTS transactions.
Those must be separated into positive and negative APERAKs respectively.
An APERAK may not be replied with another APERAK
If UTILTS messages concerning the same time series are received in wrong order (e.g. due to problems in a mail
server) the transactions arrived after a later send, but earlier received transaction, may not be rejected. Instead, if no
other errors are found, positive APERAK should be sent and the recipient can choose whether he wants to save those
old values. By examining the field Registration date (512) or Latest update date (532), you can see when the sender
did his latest update of the values in the current transaction.
See also chapter 3.6.5, regarding the recipient sending positive APERAK when the rules for notifying are fulfilled.
UTILTS-APERAK
Page 109 of 137
Ediel-guide
UTILTS & APERAK
5.3
APERAK attributes
The table below describes the information in an APERAK message.

The following status codes/classifications are used for specifying the usage:
R (Required)
- required information, the field should always be sent
D (Dependent) - conditional information, required in some circumstances, see terms in the column Notes.
O (Optional)
- optional information.
Field number and field name in the table are used as reference numbers in the segment description. The same number and names are also used in UTILTS, but without
A preceding the field number. In order to get a clearer picture on how the different levels are repeated, read the table together with the segment description and the
different examples in the appendices.
In Appendix 1 Rules for APERAK Guide validation, rules for allowed values and terms for all the fields are described. If allowed values and terms are not fulfilled
according to the appendix, the transaction is rejected in the APERAK message, but if all terms are fulfilled and with correct values the next control-step should be
performed, see description in Appendix 2 Rules for UTILTS ERR Processability validation.
Field
A311
A312
A202
A203
A204
A205
Field name English

Document name code
Document identifier
Message Function
Message date

Version
Dokumentnamn, kod
Dokument id
Meddelandefunktion
Meddelandedatum
A206
A503
Time zone
Reference function code
Tidzon
UTILTSmeddelandetyp
R
D
A504
message
UTILTS
meddelandenummer
A207
A208
Sender
Recipient
Avsndare
Mottagare
R
R
APERAK
R
R
R
R
R
R
Notes
Same as in received message
Current version of the Ediel APERAK message
BGM-message type: 312, 313
Unique identity of the whole APERAK message
Message function, see code in BGM
Date when the APERAK-message was created in the
Reference to original UTILTS- message type (from
UTILTS BGM/1001). The field should be specified if
the information is found in the received message.
Reference to original UTILTS message id (from
UTILTS BGM/1004). The field should be specified if
the information is found in the received message.
UTILTS-APERAK
Page 110 of 137
EDIFACT mapping
UNB/0026
UNH/S009/0057
BGM/C002/1001
BGM/C106/1004
BGM/1225
DTM+137/C507/2380
DTM+735/C507/2380
SG1/DOC/C002/1001
SG1/DOC/C503/1004
Ediel-guide
UTILTS & APERAK
Field
A509
Field name English

Ancillary Role

Underordnad roll
A902
Acceptance Status Code
Acceptanskod
A904
[Reference to fieldnumber]
Referens till fltnr
A905
A906
Reason Description
Business Document Data
R
R
A505
business document
Beskrivning
Transaktionsnr fr
APERAK
Referens till UTILTStransaktion
APERAK
D
Notes
Code for the party not responsible for the message, is
found in the received message if the field is there.
Acceptance code specifying if the UTILTStransaction/facility is OK or wrong,
for codes, see the ERC-segment
Field number according to UTILTS table in chapter
3.7 UTILTS attributes. Sent if the Acceptance Status
Code isnt 100 (=OK).
Description, see FTX.
Unique transaction id for the APERAK-transaction
(set by the APERAK-sender)
Reference to original UTILTS transaction id (from
UTILTS SG5/IDE/7402) The field should be
specified if the information is found in the received
transaction, i.e. not used when negative APERAK is
sent due to error(s) in the header of the message. Is
always sent in a positive APERAK.
UTILTS-APERAK
Page 111 of 137
EDIFACT mapping
SG3/NAD+role code
SG4/ERC/C901/9321
SG4/FTX+AAO/C107/4441
SG4/FTX+AAO/C108/4440
SG5/RFF+DM/C506/1154
SG5/RFF+ACW/C506/1154
Ediel-guide
UTILTS & APERAK
5.4
APERAK message diagram
The Message diagram shows the whole EDIFACT message. Segments not used in the Swedish guide are marked
in yellow.
UNH
M 1
BGM
M 1
UNT
M 1
DTM
C 9
FTX
C 9
CNT
C 9
SG. 1
C 99
DOC
M 1
SG. 2
C 9
RFF
M 1
SG. 3
C 9
NAD
M 1
DTM
C 99
DTM
C 9
CTA
C 9
SG. 4
C 99999
ERC
M 1
COM
C 9
FTX
C 1
SG. 5
C 9
RFF
M 1
FTX
C 9
Figure 28 Message diagram for the Swedish APERAK
UTILTS-APERAK
Page 112 of 137
Ediel-guide
UTILTS & APERAK
5.5
APERAK segment description
Below the APERAK message is described segment by segment, from UNH up to UNT. The segments are described in the
order they occur in the message (according to the message diagram). The description of the UNB and UNZ segments can
be found in the documents Generell teknisk Ediel-anvisning and ebIX Common rules and recommendations
(www.ebix.org).
To know which segments/fields being required in each message type, and to get a clear picture on how the different
segments are repeated for different message types, read the description below together with the list in chapter 5.3
APERAK attributes and the different examples in the appendices. For rules on how a received UTILTS message should
be validated, see Appendix 1 Rules for APERAK Guide validation se also Appendix 2 Rules for UTILTS ERR
Processability validation.
Explanations and abbreviations
In the Description column a connection is made to the current field number in APERAK table in chapter 5.3 APERAK
attributes.
Status codes/classifications
M and R
= mandatory/required (must always be sent)
D
= dependent (see specific terms)
X and N
= not used (may not be sent)
other abbreviations
DE
= Data element
Note that the segment descriptions may end before the last not used data elements. For example the NAD segment and
the RFF segments have more data elements towards the end of the segment not described below. When implementing the
APERAK message in an EDI-converter the total message according to UN/Cefact must be described, in order to make a
correct syntax check.
UTILTS-APERAK
Page 113 of 137
Ediel-guide
UTILTS & APERAK
UNH
Message Header
Data element
Type
Description
0062
an..14
Message reference
an..6
an..3
an..3
an..2
an..6
APERAK
D
04A
UN
E5SE1B
M
M
M
M
M
R
S009
0065
0052
0054
0051
0057
MESSAGE REFERENCE
NUMBER
MESSAGE IDENTIFIER
Message type
Message version number
Message release number
Controlling agency
Example: UNH+1+APERAK:D:04A:UN:E5SE1B'
Notes
0062: This message reference is set by the senders EDI system and can be seen as a technical message number. The
functional message number is sent in the BGM segment.
0057: Generic version number with the format Exyyzz, where x indicates the ebIX version, yy indicates ISO 2 letter
country code and zz indicates a national implementation guide version number. The Swedish implementation guide
version number indicates the year and revision of introduction where the revision could be either A (April) or B
(October).
Example: guide version number 1B indicates year of introduction = 2011 and revision = B (autumn), i.e. the guide
is valid from autumn 2011.
UTILTS-APERAK
Page 114 of 137
Ediel-guide
UTILTS & APERAK
BGM
Beginning of Message
Data element
C002
DOCUMENT/MESSAGE
NAME
Type
Description
R
an..3
Document name, field A202

312 Acknowledgement message (positive)
313 Application error message (negative)

code
1000 Document name
C106
DOCUMENT/MESSAGE
IDENTIFICATION
an..17
an..3
N
N
an..35

1225
MESSAGE FUNCTION
CODE
4343
RESPONSE TYPE CODE
an..9
an..6
an..3
an..35
an..3
Unique document id for the APERAK

Message, field A203.
Specified by the sender.
Message function, field A204

9
Original
N
N
R
N
Example: BGM+313+1234+9'
Notes
1001:
Code 312 is used for positive APERAK, i.e. only when the referenced UTILTS transactions are OK in the received
UTILTS.
Code 313 is used for negative APERAK, i.e. when it was an error in the header of the received UTILTS, or when
the referenced UTILTS-transactions isnt OK in the received UTILTS.
1004: The document id should be unique over time for all of the sender's applications that sends APERAK as
answer to UTILTS.
UTILTS-APERAK
Page 115 of 137
Ediel-guide
UTILTS & APERAK
DTM
Date/time/period
Data element
C507
Type
DATE/TIME/PERIOD
code qualifier
an..35

code
an..3
Description
137
735
Message date
Offset from Co-ordinated Universal
Time (UTC)
Message date, field A205
Time zone, field A206
203
CCYYMMDDHHMM (137)
406
ZHHMM (735)
M
M
R
R
Examples:
DTM+137:200501011515:203'
DTM+735:?+0100:406'
Notes
Message date (137), i.e. date/time when the APERAK message was created.
Time zone (735), offset from UTC for each dates/times in the message. Only one UTC-value per message. In
Sweden we use +0100. The UTC-value is specified in hours and minutes with preceeding plus (+) or minus (-) sign.
Notice: syntax rules require that plus signs (+) that not is a segment separator, must be preceded by the release
character (?).
UTILTS-APERAK
Page 116 of 137
Ediel-guide
UTILTS & APERAK
SG1
DOC
DOC-DTM
Document/message
Data element
C002
DOCUMENT/MESSAGE
NAME

code
1000 Document name
C503
DOCUMENT/MESSAGE
DETAILS
1373 Document status code
1366 Document source description
3453 Language name coded
3153
COMMUNICATION
MEDIUM TYPE CODE
1220
DOCUMENT COPIES
REQUIRED QUANTITY
1218
DOCUMENT ORIGINALS
REQUIRED QUANTITY
Type
Description
R
an..3
an..17
an..3
UTILTS message type, field A503

E30
UTILTS-E30
E31
UTILTS-E31
E66
UTILTS-E66
E72
UTILTS-E72
E73
UTILTS-E73
E74
UTILTS-E74
S01
UTILTS-S01
S02
UTILTS-S02
S03
UTILTS-S03
S04
UTILTS-S04
S05
UTILTS-S05
S06
UTILTS-S06
S07
UTILTS-S07
ERR
UTILTS-ERR
SVK
Svenska kraftnt
260
Ediel
an..35
an..35
an..3
an..70
an..3
an..9
an..6
an..3
D
R
N
D
UTILTS message reference, field A504
R
N
N
N
N
N
N
n..2
n..2
Example: DOC+E66::260+12345', DOC+S01:SVK:260+MEDD2001235'

Notes
The Segment should always be sent if message type and/or message reference is found in the received message.
1001 specify current UTILTS message type, received from UTILTS BGM/1001 and is specified if it is included
in the received UTILTS message.
1131: Used if 1001 is S01-S07.
1004 specify the reference to current UTILTS message, received from UTILTS BGM/1004. Specified if
BGM/1004 is included in the received UTILTS message.
UTILTS-APERAK
Page 117 of 137
Ediel-guide
UTILTS & APERAK
SG3
NAD
NAD-CTA-COM
Name and Address
Data element
Type
Description
3035
PARTY FUNCTION CODE

QUALIFIER
an..3
MR
Message recipient
M
MS
Document/message issuer/sender
Codes for ancillary role (field A509):
DDK
Balance responsible ([Swedish:]
balansansvarig)
DDQ
leverantr)
DDX
Imbalance Settlement Responsible
(responsible for balance settlement Svenska
kraftnt)
DEA
Meter Data Aggregator (network
owner aggregated values)
DEC
Party connected to grid, i.e.
electricty/gas user or producer
DER
Market information aggregator
EZ
systemansvarig)
MDR
Metered data responsible (network
owner single values)
PQ
Issuer of Certificates (issuer of energy
certificates)
C082
DETAILS
code
D
an..35
an..17
an..3
The senders Ediel id, field A207

The recipients Ediel id, field A208
SVK
Svenska kraftnt
260
ebIX
9
EAN (International Article
Numbering association) (GS1)
305
ETSO/EIC (ETSO Identification
Code)
M
D
R
Examples:
NAD+MR+11111:SVK:260'
NAD+MS+22222:SVK:260'
Notes
3035: Sender and recipient refer to the legal Ediel actor. Possible representative is only specified in the UNBsegment as sender and recipient of the whole interchange.
C082 should be used for sender and recipient, but not for ancillary role.
3039: If GS1-number (GLN) or EIC-number has been used in the UTILTS message (may be used after bilateral
aggreement) then this number is also used in the response. If Ediel-id is used SVK should be specified in 1131
and 260 in 3055.
1131: Used if 260 is specified in 3055.
Ancillary role is specified if the field can be found in the received UTILTS-meddelande.
UTILTS-APERAK
Page 118 of 137
Ediel-guide
UTILTS & APERAK
SG4
ERC
ERC-FTX-SG5
99999
Application Error Information
Data element
C901
APPLICATION ERROR
DETAIL
9321 Application error code
code
Type
Description
M
an..8
an..17
an..3
Acceptance code, field A902

260
Ediel
M
N
R
Example:
ERC+100::260'
Notes
At least on ERC- with adherent FTX-segment should be present in the message.
9321: Valid acceptance codes:
Transaction = approved
100
The object is approved (the present time series, i.e. the facility [Metering point] in an UTILTS
transaction)
The same code is also used for aggregated time series, where the object is more complex.
Transaction = erroneous or error in the header of the message
Guide validation-codes:
41
Required data missing
Used when a field in UTILTS, required according to the rules in UTILTS list of attributes, is missing.
Point out the current field in the following FTX segment.
42
Error in content of a data element

Used when a field is erroneous (e.g. a field does not have a predefined code).
Point out the current field in the following FTX segment.
UTILTS-APERAK
Page 119 of 137
Ediel-guide
UTILTS & APERAK
SG4
FTX
ERC-FTX-SG5
99999
Free Text
Data element
Type
Description
4451
TEXT SUBJECT CODE

an..3
AAO
Error description
QUALIFIER
4453
FREE TEXT FUNCTION
an..3
CODE
C107
TEXT REFERENCE
4441 Free text description code
an..17
Reference to field number, field A904
an..17
an..3
260
Ediel
code
C108
TEXT LITERAL
4440 Free Text
an..512
Description, field A905
4440 Free Text
an..512
4440 Free Text
an..512
4440 Free Text
an..512
4440 Free Text
an..512
3453
LANGUAGE NAME CODE
an..3
4447
FREE TEXT FORMAT
an..3
CODE
Examples 2 alternatives depending on acceptance code in preceding ERC:
M
X
D
M
X
R
R
M
X
X
X
X
X
X
Transaction = approved:
FTX+AAO+++OK'
Transaction = erroneous according to the Guide validation:
FTX+AAO++209::260+MANDATORY FIELD MISSING'
FTX+AAO++509::260+INCORRECT DATA BY'
(field 209 missing)

(field 509 having wrong code)
Notes
Note that an APERAK message may not have references to both approved and rejected transactions.
4441: Required if acceptance code in preceding ERC-segment isnt 100. The data element should contain a
reference to the field number for the erroneous field. Field number according to UTILTS list of attributes.
4440: If acceptance code in preceding ERC segment is:
100
then description should always be OK
41
then description should always be MANDATORY FIELD MISSING
42
then description should always be INCORRECT DATA XXX where XXX correspond with the content
of the erroneous field.
UTILTS-APERAK
Page 120 of 137
Ediel-guide
UTILTS & APERAK
SG4
ERC-FTX-SG5
99999
SG5
RFF-FTX
References
RFF
Data element
C506
Type
Description
REFERENCE
an..3
DM
ACW
an..70
M
Document number
M
Reference number to previous
message
APERAK transaction id, field A906 (DM)
R
Reference to UTILTS transaction id, field A505
(ACW)
Examples:
RFF+DM:APETR001'
RFF+ACW:UTLTR003'
Notes
1154:
- APERAK transaction id (DM), the sender should specify a unique APERAK transaction id that identifies the
current transaction in the APERAK message.
- Reference to UTILTS transaction id (ACW), specify a reference to the UTILTS transaction acknowledged in the
APERAK transaction, UTILTS transaction id is found in SG5/IDE/7402 from received UTILTS. Is not sent if the
APERAK is a negative APERAK due to errors in the header of the message.
UTILTS-APERAK
Page 121 of 137
Ediel-guide
UTILTS & APERAK
UNT
Message trailer
Data element
Type
Description
0074
n..6
Total number of segments in the message, from

UNH to UNT (UNH and UNT included)
Message reference, the same number as the
message reference in the previous UNHsegment.
0062
NUMBER OF SEGMENTS
IN THE MESSAGE
MESSAGE REFERENCE
NUMBER
an..14
M
M
Notes
This segment is mandatory according to UN/Cefact.
UTILTS-APERAK
Page 122 of 137
Ediel-guide
UTILTS & APERAK
Appendix 1 Rules for APERAK Guide validation

The main validations in the Guide validation of received UTILTS:
Required fields
o Validate that every required field are included for the current message type according to the UTILTS table in chapter 3.7.
o Validate that every required EDIFACT data element are included, according to the UTILTS segment description in chapter 3.9.
If a required field/data element is missing specify Acceptance code (field A902) = 41 (required data missing) in SG4/ERC/C901/9321.
Error in content
o Check valid codes for each segments/data elements according to the table below with valid codes.
If a data element has wrong predefined code specify Acceptance code (field A902) = 42 (error in content of a data element) in SG4/ERC/C901/9321.
In SG4/FTX/C107/4441 (field A904) a reference to the erroneous data element is specified as a field number, for more information about field numbers see UTILTS
list of attributes in chapter 3.7. If it says if possible after the field number it is recommended that you in the first place specifies the field number, but if it isnt
possible or if a field number is missing for the erroneous field, the EDIFACT segment/data element, e.g. DTM/2005 or SG5/DTM+324/2005 should, if possible,
be specified in SG4/FTX/C107/4441. Note that the field has a maximum length of 17 characters; the recommendation is therefore to omit composite data elements
(e.g./C507 in DTM), otherwise see the first column in the table below for information about the EDIFACT segment/data element.
Correct UTILTS transactions (no errors according to the following guide validation) should go further to the next level of validation, processability validation (see
appendix 2). Erroneous UTILTS transactions (erroneous according to the Guide validation) are reported as erroneous transaction in the APERAK message, i.e. no
processability validation is made on those transactions.
Field numbers in Italic specifies that the field doesnt have this number, but when error occurs for the current code, e.g. a code list responsible; the error should be
specified as if it was an error for the specified field number.
EDIFACT-segment/
data element
Fieldnumber
Field name Swedish
Check of valid codes in UTILTS
UNB/0026
311
UNH/S009/0065
Valid codes for Application Reference, see Ediels generella

tekniska anvisning [the general technical Ediel user guide].
UTILTS
D
02B
UNH/S009/0052
UNH/S009/0054
UTILTS-APERAK
Page 123 of 137
Notes
Ediel-guide
UTILTS & APERAK
EDIFACT-segment/
data element
Fieldnumber
Field name Swedish
UNH/S009/0051
UNH/S009/0057
312
Version
UN
E5SE1B
BGM/C002/1001
202
Dokumentnamn, kod
BGM/C002/1131
202
202
203
Dokument id
204
313
Meddelandefunktion
Kvittensbegran
BGM/C002/3055
BGM/C106/1004
BGM/1225
BGM/4343
DTM+137/C507/2005
DTM+137/C507/2380
205 (if
possible)
205
DTM+137/C507/2379
205
DTM+735/C507/2005
DTM+735/C507/2380
206 (if
possible)
206
DTM+735/C507/2379
206
MKS/7293
501
502
502
MKS/C332/3496
MKS/C332/3055
E30, E31, E66, E72, E73, E74, S01, S02, S03, S04, S05, S06,
S07, ERR
SVK
260
Not empty
Verify that the document id is unique over time
Notes
Current and previous

versions (during a
transitional period of two
weeks) are allowed.
Error code 42 is used if the

document id not is unique
over time.
5, 9
AB, NA
137
Meddelandedatum
Date according to format 203 (CCYYMMDDHHmm)

No future dates
203
735
Tidzon
+0100
406
Marknad
Skede
23, 27
E02, E03, E04
260
UTILTS-APERAK
Page 124 of 137
+0100 only valid for the

same time zone as Sweden,
if UTILTS comes from
another time zone the value
should correspond with that
time zone (offset to UTC).
Ediel-guide
UTILTS & APERAK
EDIFACT-segment/
data element
Fieldnumber
SG2/NAD/3035
207 or 208 (if

possible)
207 or 208
SG2/NAD/C082/3039
SG2/NAD/C082/1131
Field name Swedish

MS, MR
Avsndare eller Mottagare
If 1131=SVK: Check five digit (Ediel-id)

If 3055=9 or 305: validate check digit.
SG2/NAD/C082/3055
207 or 208
207 or 208
SG2/NAD/3035
509
Underordnad roll
DDK, DDQ, DDX, DEA, DEC, DER, EZ, MDR, PQ
SG5/IDE/7495
505
505
Transaktionsnr
24
Not empty
Verify that the transaction id is unique over time
SG5/IDE+24/C206/7402
SG5/LOC+172/3227
SG5/LOC+172/C517/3225
SG5/LOC+172/C517/3055
209
9, 89
SG5/LOC+175/3227
175
SG5/LOC+175/C517/3225
533 (if
possible)
533
SG5/LOC+175/C517/3055
533
9, 89
SG5/LOC+232, 233,
239/3227
260a, 260b,
260c (if
possible)
260a, 260b,
260c
232, 233, 239
SG5/LOC+232, 233,
260a, 260b,
* Algorithm for check of

GS1 check digit, see at the
end of this appendix.
SVK if 3055=260
260, 9, 305
209 (if
possible)
209
SG5/LOC+232, 233,
239/C517/3225
Notes
Error code 42 is used if the

transaction id not is unique
over time.
172
Anlggningsid
Reglerobjektsid
Ntomrdesid, Ntomrde
utmatning, Ntomrde
inmatning
Not empty
If GS1-no, validate GS1 check digit
Not empty
If GS1-no, validate GS1 check digit
Not empty, always three characters.
SVK
UTILTS-APERAK
Page 125 of 137


Ediel-guide
UTILTS & APERAK
EDIFACT-segment/
data element
Fieldnumber
239/C517/1131
260c
260a, 260b,
260c
SG5/LOC+232, 233,
239/C517/3055
SG5/NAD/3035
SG5/NAD/C082/3039
SG5/NAD/C082/1131
SG5/NAD/C082/3055
262, 510, 524,

525, 526 (if
possible)
262, 510, 524,
525, 526
506
SG5/LIN/C212/3055
506
SG5/PIA/4347
511
511a, 511b,
511c, 511d,
511e
260
DDK, DDQ, BY, SE, EZ
Balansansvarig, Leverantr,
Kpare, Sljare,
Systemansvarig
262, 510, 524,

525, 526
262, 510, 524,
525, 526
SG5/LIN/C212/7140
SG5/PIA/C212/7140
Field name Swedish
Check five digit (Ediel-id)
SVK
260
Produkt id
Tidsserieprodukt
8716867000016 (power active)

8716867000023 (power reactive)
8716867000030 (energy active)
8716867000047 (energy reactive)
8716867000054 (connection capacity)
8716867000061 (connection use)
8716867000078 (transport capacity)
8716867000085 (transport use)
8716867000139 (energy reactive capacitive)
8716867000146 (energy reactive inductive)
5410000100016 (natural gas)
7331507000013 (time) [tid]
7331507000020 (amount) [belopp]
9
1
Not empty
UTILTS-APERAK
Page 126 of 137
Notes
Ediel-guide
UTILTS & APERAK
Field name Swedish
EDIFACT-segment/
data element
Fieldnumber
SG5/PIS/C212/7143
511a, 511b,
511c, 511d,
511e
511a, 511b,
511c, 511d,
511e
511a, 511b,
511c, 511d,
511e
PC, PT, OT, LOD, BAP
324
SG5/DTM+324/C507/2380
245 (if
possible)
245
SG5/DTM+324/C507/2379
245
SG5/DTM+354/C507/2005
SG5/DTM+354/C507/2380
508 (if
possible)
508
SG5/DTM+354/C507/2379
508
SG5/DTM+597/C507/2005
SG5/DTM+597/C507/2380
512 (if
possible)
512
SG5/DTM+597/C507/2379
512
SG5/PIA/C212/1131
SG5/PIA/C212/3055
SG5/DTM+324/C507/2005
14
SVK
260
Leveransperiod
Date according to format 719

(CCYYMMDDHHmmCCYYMMDDHHmm)
If message type = E30, E31, E66, S01, S05 or S07 check that it
isnt a future date, for preliminary profile shares/usage profile
shares/aggregated monthly average power (S03, S04) and
consumption forecasts (S02) it is allowed with future dates.
719
354
Upplsning
1 if 2379 = 801, 802, 804

1514, 60 if 2379 = 806
801, 802, 804, 806
597

Check that it isnt a future date
203
For quarterly values

UTILTS-APERAK
Page 127 of 137
Notes
Ediel-guide
UTILTS & APERAK
EDIFACT-segment/
data element
Fieldnumber
SG5/DTM+368/C507/2005
SG5/DTM+368/C507/2380
532 (if
possible)
532
SG5/DTM+368/C507/2379
532
SG5/DTM+324/C507/2005
SG5/DTM+324/C507/2380
210 (if
possible)
210
SG5/DTM+324/C507/2379
210
SG5/STS+7/C601/9015
223 (if
possible)
223
223
223
SG5/STS+7/C556/9013
SG5/STS+E01/C556/1131
SG5/STS+E01/C556/3055
SG5/STS+E01/C601/9015
Field name Swedish
368
Senaste uppdateringstidpunkt
Date according to 203 (CCYYMMDDHHmm)

203
92
Avtal, startdatum

203
7
SG5/STS+E01/C555/4405
528 (if
possible)
528
528
Svarskod
SG5/STS+E01/C556/9013
531
Avvisningsorsak
SG5/STS+E01/C556/3055
531
SG5/MEA/6311
SG5/MEA/C174/6411
264
264
Enhet
SG6/RFF/C506/1153
503
Referens till meddelandetyp
SG5/STS+E01/C601/3055
E03, E20, E23, E24, E25, E43, E44, E64, E67, E77, E88, Z01
SVK if 9013=Z01
260
E01
260
41
E10, E14, E16, E18, E19, E29, E47, E49, E50, E51, E55, E61,
E62, E73, E87, E90, E97, E98
260
AAZ
KWH, KVR, KVA, KWT, MAW, 3B, GWH, K3, MWH, E08,
MQH, MTQ, E46, D90, P1
E30, E31, E66, E72, E73, E74, S01, S02, S03, S04, S05, S06,
S07
UTILTS-APERAK
Page 128 of 137
Notes
Ediel-guide
UTILTS & APERAK
EDIFACT-segment/
data element
Fieldnumber
Field name Swedish
SG6/RFF/C506/1154
504
Referens till meddelandeid
If BGM/C002/1001=ERR: Not empty
SG6/RFF/C506/1153
SG6/RFF/C506/1154
529
529
Referens till transaktionsnr
TN
Not empty
SG6/RFF/C506/1153
226
SG6/RFF/C506/1154
226
SG7/CCI/C240/7037
507a (if
possible)
507a
507a (if
possible)
SG7/CCI/C240/1131
SG7/CCI/C240/3055
SG7/CAV/C889/7111
The field should contain TN, but dont reject the transaction
if the code is wrong.
No validations are made, see chapter 3.6.11.
E02, E12, Z01

SVK if 7037=Z01
260
Avrkningsmetod
SG7/CAV/C889/7110
254
513
254 eller 513
507a
Antal mtpunkter
E01, E02 if CCI/C240/7037 = E02

E17, E18, E19, E20 if CCI/C240/7037 = E12
260 if CCI/C240/7037 = E02 or E12
Integer >= 0 if CCI/C240/7037 = Z01
SG8/SEQ/C286/1050
514
Observationsnr
Not empty
SG8/RFF/C506/1153
224 (if
possible)
224
SG7/CAV/C889/3055
SG8/RFF/C506/1154
SG8/RFF/C506/1153
SG8/RFF/C506/1154
527 (if
possible)
527
Notes
MG, SE
Mtarnummer
If 1153=SE, meter number should be an GS1-number, validate

check digit
AES
RegisterId
Not empty
The specified code is checked against master data, that check
is done in Processability validation, see below.
UTILTS-APERAK
Page 129 of 137

check digit, see at the end
of this appendix.
Ediel-guide
UTILTS & APERAK
EDIFACT-segment/
data element
Fieldnumber
Field name Swedish
SG8/MOA/C516/5025
522
522
269a
Belopp
Valuta
9
Numerical
Three letters (A-Z)
SG8/MOA/C516/5004
SG8/MOA/C516/6345
SG10/PRI/C509/5125
SG10/PRI/C509/5118
SG10/CUX/C504/6347
SG10/CUX/C504/6345
SG11/QTY/C186/6063
SG11/QTY/C186/6060
SG11/DTM/C507/2005
523
523
269b
269b
516, 515, 517
or 521 (if
possible)
516, 515, 517
eller 521
SG11/DTM/C507/2380
530a, 530b
530a, 530b
SG11/DTM/C507/2379
530a, 530b
SG11/STS/C601/9015
520
520
SG11/STS/C555/4405
SG12/CCI/C240/7037
SG12/CCI/C240/3055
SG12/CAV/C889/7111
SG12/CAV/C889/3055
Pris
Valuta
135, 136, 220, 42
Uppndd periodisk kvantitet,

Planerad periodisk kvantitet,
Mtarstllning eller
Maxeffektvrde
Datum fr mtarstllning,
Tidpunkt fr effektvrde
Kvantitetskvalitet
259 (if
possible)
259
259
259
CAL
Numerical
2
Three letters (A-Z)
Numerical or NULL
597
203
8
21, 46, 56, 113, 125
E07
260
Tidsintervall
E12
260
UTILTS-APERAK
Page 130 of 137
Notes
Ediel-guide
UTILTS & APERAK
EDIFACT-segment/
data element
Fieldnumber
SG12/CCI/C240/7037
309 (if
possible)
309
SG12/CCI/C240/3055
SG12/CAV/C889/7111
SG12/CAV/C889/3055
SG12/CCI/C240/7037
309
309
SG12/CCI/C240/3055
507b (if
possible)
507b
507b
SG12/CAV/C889/7110
507b
SG12/CCI/C240/1131
Field name Swedish
Notes
E22
260
Mtaravlsare
E26, E27, E28

260
Z01
SVK if 7037=Z01
260
Avvikande antal mtpunkter
Integer >=0
* Algorithm for calculating the check digit of the GS1 number.

The following description is collected from the GS1 home page (www.gs1.se), [and translated into English], for additional questions about GS1 numbers, please
contact GS1.
The number 730001100001 is an example.
730001100001 C
The check digit is calculated the following way;
Start to sum every second figure from the right. 1+0+ 0+1+0+3=5
Multiply the result with number 3. 5 X 3 = 15
Then sum all other figures. 0+0+1+0+0+7=8
Add the result to the preceding calculation. 15+8=23
Subtract the total from the next higher multiple of ten, in this case 30, and we get the check digit 30-23=7
The GS1 number then becomes:
730001100001 7
Notice: If the sum that should be withdrawn from the next higher multiple of ten, in it self is an even ten, the check digit = 0.
The procedure calculating the check digit is identical for all articles and coding systems within the GS1-system.
For information about GS1 numbers for electricity meters and facilities, see Appendix 7 EAN-numbers for electricity meters and facilities.
UTILTS-APERAK
Page 131 of 137
Ediel-guide
UTILTS & APERAK
Appendix 2 Rules for UTILTS ERR Processability validation

Validate received UTILTS transactions, having passed the Guide validation without errors, according to the list below.
The validations below and other validations according to the Handbook that cause the recipient not being able to store the
information from a field (from a UTILTS-transaction) in his application, should result the UTILTS transaction being
reported as erroneous.
Each transaction is checked, for those transactions where errors are found an UTILTS ERR is sent in return to the sender.
Either these are collected in one UTILTS ERR-message, or there is sent one UTILTS ERR-message per errouneous
transaction. Cfr figures in section 3.4. The code for Reason for rejection is specified in field 531 in SG5/STS.
After the guide validation and the processability validation there will remain a number of transactions without errors, they
should be reported back in one APERAK message or in one APERAK message each as approved transactions. See further
chapter 5.
EDIFACTValidation
segment/data element
Validation at UTILTS header level (against information in the transaction)
Sender (field 207)
Validate that the sender is valid in relation with network
area, facility and master data
Code E55 is used for erroneous network owners.
Code E16 is used for erroneous supplier.
Code E18 is used for erroneous balance responsible.
Typically these codes are used in UTILTS ERR-answers
to UTILTS-request, i.e. when someone not authorised
requests time series.
Validations at UTILTS transaction and observation level
Metering point id (field 209)
Validate that the facility/regulating object is known and
SG5/LOC+172/C517/3225
valid in relation to network area id.
Regulating object id (field
533)
SG5/LOC+175/C517/3225
UTILTS ERR
E55
Unauthorised metered data
collector
E16
Unauthorised Balance
supplier
E18
Unauthorised Balance
responsible party
E10
Metering point not
identifiable
Network area id (field 260a,

260b, 260c)
SG5/LOC+232, 233,
239/C517/3225
Validate that the network area id is valid in relation to

master data.
E49
Metering grid area not
identifiable
Product identification (field

506)
SG5/LIN/C212/7140
Time Series Product (field
511)
SG5/PIA+1/C212/7140
together with field 262
(Balance responsible), field
510 (Balance supplier), field
260a-c (Metering grid ids),
field 524 (Buyer), field 525
(Seller), field 526 (System
operator) and field 533
(Station group id)
Validate that the product id correspond with master data.
E29
Product code unknown or
not related to metering
point
Validate the instance of the Time series product against

structure / master data and that the Time series product
corresponds with what is sent in the message. I.e. the
codes of the Time series product are the expected and
that the fields defining the instance of the time series
product can be found in the structure. For example, if
the Time series product concerns a Balance responsibles
activities within a metering grid area the fields 262 and
260a should be present in the transaction and the content
of these fields should correspond with the stored
structure (i.e. the time series is the expected one). At the
same time the field 510 (supplier) should not be present
in the transaction, since then the Time series product is
not corresponding with the specified aggregation
criteria.
UTILTS-APERAK
Page 132 of 137
Ediel-guide
UTILTS & APERAK
EDIFACTsegment/data element
Validation
UTILTS ERR
Delivery period (field 245)

SG5/DTM+324/C507/2380
Time period at observation
level (field 530a, 530b)
SG11/DTM+597/C507/2380
Validate the following, the period:

o may not be negative
(end date should not be before start date)
o should coincide with the time span between
possible first and last meter stands for each
register, if meter stands are sent
o When resolution is sent (i.e. when volumes are
sent) the delivery period should coincide with the
resolution if reason for transaction is Periodic
Meter Reading, Settlement, Reconciliation,
Planning or Billing Energy. In those cases
the following rules applies:
If the delivery period is a month and the
settlement method is profiled the resolution
may be month, day, hour (or shorter)
otherwise the following applies
If Resolution is hour (or shorter) the
period should be a day and night at the
most.
If Resolution is day and night the period
should at least be a day and night and at
the most a whole calendar month.
If Resolution is month the period should be
a whole calendar month at the most.
If Resolution is year the period may
comprise any number of days (provided the
rules in the Handbook and regulation are
followed)
For load profile shares/usage profile shares
the delivery period should cover a whole
calender month
For consumption forecast per object
(UTILTS S02) the delivery period should
cover twelve future calender months.
o The end date/time in the period may not be later
than the Registration date/Latest update date of
the transaction, unless the message is sent in the
phase Planning.
o For metered values and corresponding aggregated
values the delivery period may not be from the
future, which on the other hand should be the
case for messages sent in the phase Planning
(preliminary load profile shares/usage profile
shares and the consumption forecast).
o The error code is also used for the case that the
installation is known, but the period is wrong.
This error code is also used when values has been sent
to late according to rules in the Handbook.
E50
Invalid period
Contract start date (field 210)

SG5/DTM+324/C507/2380
Validate if there is a change of supplier process at the

specified date
E47
No ongoing switch for
metering point
UTILTS-APERAK
Page 133 of 137
Ediel-guide
UTILTS & APERAK
Validation
UTILTS ERR
Unit (field 264)

SG5/MEA/C174/6411
Validate that the unit correspond with master data
E73
Incorrect measure unit
Meter number (field 224)

SG8/RFF+MG alt SE/C506/
1154
Validate that the meter number correspond with master

data
E61
Meter not identifiable
Register id (field 527)

SG8/RFF+AES/C506/1154
Validate that the Register id correspond with master data

For a code list of meter type codes, see www.svk.se >
Drift och marknad > Verktyg fr branschaktrer > Ediel
> Anvisningar.
The Error code is also used for the case where there is
missing a register in the UTILTS transaction, or are
more registers than expected. Example:
- In the PRODAT message it is specified that there is
one register, but the UTILTS transaction contains two.
- In the PRODAT message it is specified that there are
two registers, but in the UTILTS transaction only one is
sent.
I.e. expected numbers of registers does not correspond
with the numbers sent.
E62
Register not identifiable
Quantity (field 515, 516,

517)
SG11/QTY/C186/6060
Validate decimal rules:

Energy for hourly metered facilities should
normally be reported in kWh with 0-3 decimals
Aggregated energy values per hour should normally
be reported in kWh with 0-3 decimals
Energy for profile settled values (Resolution = year
or month) should be reported in kWh without
decimals
Meter stands, check the constant against master
data,
o Meter stands for monthly read facilitis are
reported with no decimals (and if the
constant is 1 the meter stand is reported in
whole kWh).
o Meter stands for hourly read facilities are
reported with the resolution of the meter.
For meter stands, see further below.
E51
Invalid number of decimals
Meter stand (field 517)

SG11/QTY+220/C186/6060
Validate meter stand against energy volumes according

to:
if stop-stand < start-stand check register rollover
if status code not is 21: check energy volume
against meter stand (consider the meter constant
and what is sent in different registers according to
the register id). Since meter stands and energy
volumes may have different accuracy a certain
tolerance of variance should be allowed. See
description and example at the end of the appendix.
The validation is not done if one or more values (meter
stand and energy volume) have been reported as NULL.
E19
Meter stand not within
limits
UTILTS-APERAK
Page 134 of 137
Ediel-guide
UTILTS & APERAK
Validation
UTILTS ERR
Energy volume (field 515,

516)
SG11/QTY+135,136/C186/
6060
Validate that all values are included that should be there

according to the period and resolution. E.g. that every
hourly value for a day and night are included.
E87
Number of observations
does not fit observation
period/resolution

516)
SG11/QTY+135,136/C186/
6060
Maximum power value (field
521)
SG11/QTY+42/C186/
6060
Validate the reasonableness of the energy volume and

maximum power value. If the value may not be zero this
error code is used.
E97
Measurement should not
be zero

516)
SG11/QTY+135,136/C186/
6060
Validate sign of energy volume.
E98
Measurement has a wrong
sign

516)
SG11/QTY+135,136/C186/
6060
Maximum power value (field
521)
SG11/QTY+42/C186/
6060
Validate the size (reasonableness) of the energy volume

and Maximum power value respectively.
E90
Measurement beyond
plausible limits
Other validation at storage into the database that doesnt

fit into one of the checks above. I.e. another error that
makes inte impossible to store the values into the
database. The error code should be avoided as much as
possible.
E14
Other reason
Check of meter stand against Energy volume

The difference between two meter stands is compared with the energy volume, considering the constant and according to
what is sent in the different registers (due to the code from meter type list). Ideally, the difference is zero. But depending
on the number of digits (accuracy, the number of decimal places) of the energy volume may differ from the accuracy of
meter stands, it might be a difference > 0. If this difference is too big, an error should be reported, but a certain tolerance
of difference must be allowed.
When receiving meter stands for current facility, this tolerance of differance can (gradually) be calculated
For meter stands for monthly metered (or yearly metered) facility there are no decimals, for that reason the tolerance of
difference always is 1 if the constant is 1, and else the same as the constant.
Note that if any of values is NULL, che check can not be performed.
For hourly metered facilities the tolerance of difference on the other hand will be calculated, cfr the following examples:
Example 1 (the unit is presumed to be kWh):
The first meter stand: 10100
The second meter stand: 20300
The tolerance of differance may now at the most be 100 kWh since the hundreds digit is varying, while the lower digits
are zero.
The third meter stand: 27440
Now the tolerance of difference is changed to at the most 10 kWh since the tens digit is varying between the meter stands.
If the ones digit would change between the meter stands the tolerance of difference would at the most be 1 kWh. After
only a few meter stands (maximum 3) the tolerance of difference can be established and will not need to be changed for
UTILTS-APERAK
Page 135 of 137
Ediel-guide
UTILTS & APERAK
every new received meter stand. The next time it may be needed to be changed is after a change of meter or other changes
of the meter (after PRODAT Z10 or Z06F).
The difference between the second and the third meter stand is 7140 kWh. The Energy volume is allowed to vary with +/the tolerance of difference to this difference, i.e. between 7130 and 7150 kWh.
Example 2
The first meter stand: 34890,8
The second meter stand: 58347,5
The tolerance of difference is 0,1 since the meter stands are specified with one decimal. If the meter stands would be
specified with two decimals the tolerance of difference would be 0,01 etcetera.
The difference between the meter stands is 23456,7. The energy volume is allowed to vary between +/- 0,1 kWh to this
value before an error is reported.. An energy volume of 23456,79 kWh is therefore permitted, but not an energy volume of
23456,81 kWh. In the latter case the meter stands are rejected with the Reason for rejection code E19, Meter stand not
within limits.
The tolerance of difference may then be calculated based on the position of the last changable digit in the meter stands.
Notice that at this check you should also take into account if the meter has gone full circle.
Appendix 3 UTILTS EDIFACT-examples per object

See separate Collection of examples.
Appendix 4 APERAK and UTILTS ERR EDIFACT-examples per object

Appendix 5 UTILTS EDIFACT-examples for aggregated time series

Appendix 6 APERAK and UTILTS ERR EDIFACT-examples for

aggregated time series
UTILTS-APERAK
Page 136 of 137
Ediel-guide
UTILTS & APERAK
Appendix 7 EAN-numbers for electricity meters and facilities

The text comes from webbpages published by GS1 Sweden, see further www.gs1.se. [Not translated.]
Elmtare
Elmtarna numreras med GIAI (Global Individual Asset Identifier, GS1-individnummer). GIAI omfattar upp till 30
positioner, men fr elmtare tillverkade i Sverige anvnds endast 16 positioner eftersom det tcker behovet. Det r viktigt
att man i databaser nd tar hnsyn till att elmtare med nummer som r lngre n 16 positioner och r tillverkade i andra
lnder skulle kunna komma in i svenska databaser. Drfr mste fltet i de svenska databaserna fr elmtarnummer
definieras s att de rymmer 30 positioner, och att de inledande positionerna fylls ut med nollor.
Streckkodning av elmtaridentiteten
Fr att streckkoda elmtaridentiteten anvnds streckodssystemet GS1-128. Koden utgrs av en streckkodstyp (Code128
med funktionskoden 1 (FNC1)) och en uppsttning med dataelement (elmtaridentiteten). Dataelementen identifieras med
en inledande applikationsidentifierare (Application Identifier, AI).
Applikationsidentifieraren anvnds bland annat fr att streckodslsare ska kunna identifiera typ av dataelement och fr att
informationen ska kunna slussas rtt i administrativa system. AI fr GIAI och elmtaridentiteten r 8004. Bde AI och
elmtaridentiteten ingr i streckkoden och siffrorna skrivs ut under streckkoden med AI inom parentes.
Observera att AI inte ingr vid berkning av kontrollsiffran och att elmtaridentiteten endast bestr av 16 positioner, ven
om 20 positioner ingr i streckkoden. Det r drfr viktigt att AI (8004) tas bort och att endast de 16 positionerna
registreras nr elmtaridentiteten ska lagras i en databas.Exempel p en mtaridentitet fr en mtare tillverkad av ett
svenskt fretag r fljande: 73 1234567 123456 7
Anlggningar
Mtpunkterna identifieras med hjlp av GSRN (Global Service Relation Number, GS1-affrsrelationsnummer) som
omfattar 18 positioner. P samma stt som fr elmtaridentiteten, anvnds en applikationsidentifierare fr att
streckkodning enligt standarden GS1-128. Fr mtpunktsidentiteten anvnds AI (8018).
Bde AI och mtpunktsidentiteten ingr i streckkoden och siffrorna skrivs ut under streckkoden med AI inom parentes. AI
ingr inte vid berkning av kontrollsiffran och mtpunktsidentiteten bestr av 18 positioner, ven om 22 positioner ingr i
streckkoden. Det r drfr viktigt att AI (8018) tas bort och inte registreras nr mtpunktsidentiteten ska lagras i en
databas.
Branschgemensamt nummer i fretagsprefixet
GS1 Sweden tilldelar de svenska elfretagen ett GS1 fretagsprefix dr ett branschgemensamt nummer ingr. Detta gr
det mjligt att anvnda sig av ett kortare nummer fr mtpunktsidentitet i muntlig kommunikation. Ett elfretag tilldelas
drfr 73 5999 samt tre positioner till fretaget som fretagsprefix. Drefter numrerar fretaget sjlv sina mtpunkter,
vilket ger utrymme fr 100 miljoner nummer. Observera att i en databas mste alla 18 positioner i mtpunktsidentiteten
anges ven om fretagsprefixet bestr av ett gemensamt nummer.
Exempel p ett svenskt nummer fr mtpunkter r 735999888777777778.
UTILTS-APERAK
Page 137 of 137

UTILTS User Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UTILTS User Guide

Transféré par

Droits d'auteur :

Formats disponibles

Ediel-guide

UTILTS & APERAK

General about Ediel

Using and implementing Ediel

Who is the Ediel-guide intended for?

Development and updating of the guide

Tests of UTILTS APERAK

To the guide there are seven appendices.

Changes earlier than version 10.A.0 are not included.

current time series product.

2 UTILTS a short introduction

Reason for transaction is always the same in the whole message.

UTILTS roles, flows and message types

Bilateralt/enligt avtal Ntgare

Metered Data Responsible

Balance Responsible (DDK)

System operator (EZ)

Market Information Aggregator

From Svenska kraftnt

Request for UTILTS for planning (UTILTS-Request)

Network owner (in the role

Collected data per object

From network owner

From network owner

Time series per object

Request for UTILTS for report of metered values (UTILTS-Request)

Network owner (in the role

Request missing validated

From Balance responsible

Request for UTILTS for Settlement (UTILTS-Request)

UTILTS-REQUEST (request missing time series)

The message is used after bilateral agreement.

Negative UTILTS UTILTS-ERR (rejection)

General rules for UTILTS-ERR

Transaction/facility no 2 in UTILTS contains a processability error,

Figure 19 Relations between UTILTS and UTILTS-ERR

Some fields and terms in UTILTS

Message types and Ancillary role

UTILTS general rules

Delivery period (field 245) Examples

In to the grid source = positive = no sign

Aggregated metered value

Grading (quality) for aggregated metered values

Missing underlying value

Reason for transaction, in the natural gas market

Monthly values missing value at turn of the month (one register).

Mellan 20 jan och 15 maj

Rapporteras senast 10/2

Rapporteras senast 10/3

Figure 22 Example of reporting of missing metered values at turn of month

maximum 1 Mbyte and

Field name - Swedish

For S02: should be 23-DDQ-S02-S

UTILTS-message type: S02, S03, S04

Field name - Swedish

Date when the UTILTS-message was created in the

Legal receiver, Ediel-id

Code for the party not responsible for the message, in

Transaction level, repeated once or several times per

The senders unique id of the transaction. Used for

Field name - Swedish

Latest update date

Reason for transaction

Current period of the transaction