Idd part 1 Interfaces with bsc parties and their Agents




старонка5/82
Дата канвертавання24.04.2016
Памер4.34 Mb.
1   2   3   4   5   6   7   8   9   ...   82

2.2.2 File Footer


The file footer will be a record containing the following fields:

ZZZ-File Footer

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZZZ

2

Record count

integer(10)

Includes header and footer

3

Checksum

integer(10)

Although type is shown as integer(10) the value is actually a 32-bit unsigned value and hence will fit in an “unsigned long” C variable.

The value of Checksum is defined according to the following sequence:

  1. initialise to zero

  2. consider each record in turn (including header but excluding trailer)

  3. Break each record into four byte (character) sections (excluding the end of line character), padded with nulls if required, and exclusive OR (XOR) them into checksum.

The algorithm for this is illustrated by the following ‘C-like’ pseudo code.

num_chars = strlen (record_buffer)

FOR (i = 0; i < num_chars;)

value = 0

FOR (j = 0; j < 4; i++, j++)

IF i < num_chars

value = ((value << 8 ) +
record_buffer[i])

ELSE


value = value << 8

END IF


ENDFOR

checksum = checksum XOR value

ENDFOR

The checksum value is a 32 bit value. This is treated as an unsigned integer and appears in the file footer as integer(10).


2.2.3 Record Formats


Each record in the file is presented as follows:

[…]

Where:


  1. record type : 3 characters

  2. record delimiter : Line Feed (ASCII 10)

  3. field separator: “|” (ASCII 124)

NB field separator will thus appear at end of record (i.e. after last field), prior to the linefeed

A record of n fields will have n+1 field separators.

Data fields are presented as follows:


type

rules

integer (n)

optional leading “-“ for negative numbers

no leading zeros

maximum n digits

field may have “-“ and from 1 to n digits


decimal (n,d)

n must be greater than or equal to d

optional leading “-“ for negative numbers

no leading zeros, except where n = d, then number starts “0.”

no trailing zeros

maximum n digits

maximum d digits after decimal point

maximum (n-d) digits before decimal point, except where n=d, then number starts with “0.”

field may have “-“; from 1 to (n-d) digits;
and optionally
“.” and up to d digits.

Thus the maximum field width is n+2 in the case of a negative value, except for the special case of n=d, where the maximum field width is n+3 including the leading zero.

e.g.: -123.456 is decimal (6,3)

-0.123 is a decimal (3,3)

To clarify the valid values between 1 and –1, the value 0.123 can be represented as:

0.123 or .123

but not:

00.123 or 0.1230

Valid representations of zero are:

0 0.0 .0 0. –0 –0.0 -.0 -0.

but not as a decimal point with no digits.


text (n)

up to n characters

field may not contain field separator

no leading spaces

no trailing spaces



boolean

T or F

date

YYYYMMDD

time

HHMM

timestamp

HHMMSS

datetime

YYYYMMDDHHMMSS

char

single character

null

if a field is no longer needed in a future version of a flow, then its data type will be defined to be null, meaning that its value is always null

Text and char fields may contain only the following characters:

Character

ASCII

Character

ASCII

Character

ASCII

space

32

+

43

@

64

!

33

,

44

A-Z

65-90

"

34

-

45

[

91

#

35

.

46

\

92

%

37

/

47

]

93

&

38

0-9

48-57

^

94

'

39

:

58

_

95

(

40

;

59

a-z

97-122

)

41

=

61

{

123

*

42

?

63

}

125

Optional fields are permitted to have nothing between the field separators.

2.2.4 File Types, Record Types and Repeating Structure


The structure of records and their nesting rules are specified using tables. The tables are defined in a spreadsheet attached to the end of the document. The following explains the meaning of data in those tables.

Each interface (flow) may be represented by more than one physical message type (sub-flow) indicated by multiple file types in the physical file format spreadsheet e.g. CRA-I014 has multiple file types R0141, R0142 etc. The file type is made up of three parts: the first character identifies the system (‘B’ (BMRA), ‘C’ (CDCA), ‘R’ (CRA), ‘E’ (ECVAA), or ‘S’ (SAA)); the second to fourth characters are taken from the number within the flow name ; the final character identifies the sub-flow id.

These tables are not provided for most manual flows. Where it is useful to provide this information for a manual flow, a note is provided in the “Physical Details” section of the logical definition of the flow.

Nesting is indicated by use of L1, L2 etc. Items at L2 make up a group at L1, items at L3 make up a group at L2 etc.



Id

Row Type

Flow version / range

L1

L2

L3

L4

data type

valid set

item name/group description (comments)

C0011

F

(File Type)
























Title of Flow (plus sub-flow number where appropriate)

ABC

R

(Record Type)
























record type appears as the first field in an electronic file. Record types are unique across all file types.

N0001

D

(Data Item)
























Each data item is assigned a Data Item Id. The Data Item Id is used for all occurrences of the same Data Item.







1-*



















range indicates how many occurrences of this record type may appear at the current level. (comment may further refine the repeating rules)

0-* indicates unlimited repeat (optional record type)

1-* indicates unlimited repeat with at least one instance of the record type

1 indicates the record type appears exactly once

2 indicates the record type appears exactly twice

46-50 is a special case meaning 46, 48 or 50 (but not 47 or 49) - this applies to the number of Settlement Periods in a Settlement Day (which might be a clock change day)












G
















G indicates that this is a repeating group i.e. a record type













1













1 indicates that this is a data item within a record type













O













O indicates that this is an optional data item within the record type (in electronic files, this means that the field may be empty)


























































Data items and nested record types must appear in the order stated.




























L1, L2… define the nesting structure.




















































text(9)




this field will contain a text string with up to 9 characters






















integer(n)




this field will contain an integer with an optional leading “-“ followed by up to n digits






















decimal




this field will contain a real number






















decimal (n,d)




this field will contain a real number. There will be an optional leading “-“ followed by up to d digits after the decimal point and up to (n-d) before the decimal point






















char




this field will contain a single character






















boolean




this field will contain a single character T or F






















date




this field will contain a date YYYYMMDD






















datetime




this field will contain a date and time YYYYMMDDHHMMSS

























valid set id

the field’s values are constrained to be within the definition of the identified valid set - see section 2.2.11

Different versions of flows are documented in the tables as follows. On the ‘File Type’ record, the flow version / range field indicates the version of the flow (a blank entry indicates version 1). For example, the records shown below define version 1 and version 2 of flow E0221.

Id

Row Type

flow version / range

L1

L2

L3

L4

data type

valid set

item name/group description (comments)

E0221

F























ECVAA-I022: Forward Contract Report





























E0221

F

002



















ECVAA-I022: Forward Contract Report (version 2)































2.2.4.1 The Tabs of the Spreadsheet


There is one tab for each of the Central Systems with which the BSC Parties and Party Agents communicate via electronic data file transfer: CRA, ECVAA, CDCA and SAA. The Response tab reproduces the structure of the ADT record given in section 2.2.7 below in spreadsheet format. The Valid Set tab reproduces the information given in section 2.2.11 below in spreadsheet format. The Flow Role tab lists which From Role Codes and To Role Codes can validly appear in the header for each File Type. The Groups tab is the master definition of each Record Type; the record type definitions in the CRA, ECVAA, CDCA and SAA tabs are copied from there. The Items tab is the master definition of each item; the item definitions in the CRA, ECVAA, CDCA and SAA tabs are copied from there. The Valid Sets, Flow Role, Groups and Items tabs in the IDD Part 1 spreadsheet encompass the contents of the IDD Part 1 and IDD Part 2 spreadsheets.

2.2.5 File names


Files delivered to and sent from NETA must have names which are unique across all Central Systems within any month. The following convention for filenames is proposed, and is in use by the Central Systems:

characters 1-2: Sender role

characters 3-14: Unique identifier (alphanumeric, e.g. may be a sequence number)

(This convention is sufficient for the Central Systems to uniquely identify all incoming files, because these systems move incoming files into a directory whose name identifies the sending participant id. If incoming files have filenames longer than 14 characters, then the Central Systems will truncate the filenames on receipt).

The filenames do not include an extension.

Where files are placed in a shared (read only) area for multiple users to download, the file name will contain meaningful fields to easy allow identification.


2.2.6 Unstructured File Format


To allow for flexibility, an unstructured file format is also defined. This could be used for:

  1. Ad hoc data transfers and text reports

  2. Newly defined messages which have not yet been allocated formal file formats

The unstructured file format will contain the following elements:

1. Standard header record with File Type set to UNSTR001

2. Any ASCII text, with the proviso that no lines may begin with ‘ZZZ’.

3. Standard trailer record


2.2.7 Response Messages


As described in [COMMS], participants have a choice between two methods of receiving files from the Central Systems: either the Central Systems push files to the participant systems (‘Push Method’), or the participant systems pull files from the Central Systems (‘Pull Method’). For the Push Method, the Central Systems consider that a data file has been successfully delivered when the FTP ‘push’ returns a success code. For the Pull Method, the participant systems indicate that they have successfully pulled a file by deleting it from the source directory.

Note the web submission service will allow an agent to create a notification file within the system, and in reply, receive a response to this on a web screen. The web service will therefore not send a file based response to a web submitted notification.

There is only one method available for sending files to the Central Systems: participant systems push the files to the Central Systems. Participant systems should use the FTP ‘push’ success code to determine that the file has been successfully sent.

The remainder of this section applies to electronic data files sent both to and from the Central Systems.

When a system receives a data file, it must reply by sending a response file. The purpose of the response file is to indicate whether the data file has been validated as being syntactically correct.

The Message Role field in the header record is used for differentiating a response file from a data file. A data file is sent with the message role set to data. The response file comprises the header as received, with from/to participant and role reversed and message role set to response (see section 2.2.1), followed by the ADT record(s) and a standard trailer record (ZZZ). There may be more than one ADT record if multiple problems are found with the file.



ADT-Acknowledgement Details

Field

Field Name

Type

Comments

1

Record Type

Text(3)

= ADT

2

Received Time

datetime

(GMT)


Time that the message being acknowledged was received by the receiving party

3

Response Time

datetime

(GMT)


Time that the response message was generated by the receiving party

4

File Name

text(14)

Name of file this response relates to

5

Response Code

integer(3)

A code indicating the nature of the acceptance / rejection

6

Response Data

text (80)

Any data that gives additional information in fixing the problem

The possible values for the Response Code with the meaning and the appropriate action are:

Response Code

Meaning

Appropriate Action




NACK codes

file is rejected

1

Syntax Error in Header Record

Correct and resend.

2

To Participant details in header record are not correct for the actual recipient.

Correct and resend.

3

Unexpected Sequence Number in Header record.

See section 2.2.8

4

Syntax Error in Body. Error Data field contains line number where error detected.

Correct and resend.

5

Syntax Error in Footer Record

Correct and resend.

6

Incorrect Line Count in Footer Record

Correct and resend.

7

Incorrect Checksum in Footer Record

Correct and resend.




ACK codes

file has arrived and been accepted

100

File received

none - file has arrived and its contents have passed the validation checks covered by the NACK response codes

101

Duplicate file received

ensure files are not being resent unnecessarily - a file has arrived with a header identical to one already received

The diagram below illustrates an exchange of files using the push mechanism, where a data file is sent via FTP, and then at a later time, the response file is sent back. Each file transfer consists of an FTP session where the file is first copied to the remote system, and then renamed to a separate directory on the remote system, where it can be accessed for processing.

The diagram below illustrates an exchange of files using the pull mechanism, where a data file is retrieved via FTP, and then at a later time, the response file is sent back as before. The file retrieval consists of an FTP session where the file is detected, copied from the remote system, and then deleted on the remote system.




2.2.7.1 Positive Acknowledgement (ACK Message)


A file must be checked for any of the conditions covered by response codes in the range 1-99. If all the checks pass then an ACK message must be sent.

Standard Receipt Acknowledgement Messages are not explicitly listed in the interface definitions which follow, except where they have been allocated an interface name in the URS - in this case, a section is included which contains only a reference back to this section, 2.2.7.

Receipt acknowledgement does not imply acceptance of the contents of the message.

2.2.7.2 Negative Acknowledgement (NACK Message)


This section applies to electronic data files sent both to and from the Central Systems.

In some cases it may be possible for an addressee to detect a failed message transmission. In this case a message may be returned to the sender with message role set to response.

Standard Negative Acknowledgement Messages are not explicitly listed in the interface definitions which follow.

When a system receives a NACK message, it should alert the operator of the system, informing him of the contents of the ADT record. The operator should read the Response Code field contained in the ADT record (defined in section 2.2.7) and take the appropriate action.


2.2.7.3 Response to response messages


On receipt of a response message, no response is sent.

2.2.7.4 Application Rejection and Acceptance


When a message has been received (and the receipt acknowledged as described above), the content of the message may be accepted or rejected during processing. The approach adopted to this is up to each individual application:

  1. Rejection of a message may cause a message to be sent to the sender indicating the identifier of the message being rejected, and the reasons for rejection. The way in which rejections are dealt with will be described in the application specifications. In some cases, the Rejection message may be transmitted by a manual mechanism rather than as an electronic data file. Where a rejection message has been identified, it is listed as an interface in this document.

  2. Acceptance of a message will not normally be signalled to the sender. In cases where this is required, a message is explicitly defined for the purpose.

2.2.8 Use of Sequence Numbers


The Central Systems expect each data file from a BSC Party in a certain role to have a sequence number for each Central System role in the file header which increments each time a file is sent. In the following processing rules, greater / less than comparisons will be implemented to cater for when a sequence number wraps round through 0. Note that sequence numbers start from 1.

If the received file has a sequence number less than the next expected, and the header is not identical to the file already received with that sequence number, the system generates an out-of-sequence response for the file.

If the received file has a sequence number greater than the next expected, the Central Systems will save the file, but will not process or acknowledge it until:

a) the missing file(s) arrive and the file becomes the next expected sequence and so is processed as normal (and an appropriate response sent according to the validation rules);

b) more than [n] (configurable) files have subsequently arrived all of which are flagged as out-of-sequence. The system generates an out-of-sequence response for the file;

c) more than [t] (configurable) minutes have elapsed since the file arrived. The system generates an out-of-sequence response for the file;

d) an operator manually sets the next expected sequence number to be greater than that of the file.

An out-of-sequence response is a response message with response code 3 and the expected sequence number in the Response Data field of the ADT record of the response message. It is up to the sender of the original file to correct the problem and send back a file with the correct sequence number.

The Central Systems will not process any subsequent files sent until a file with the expected sequence number is received. The sender will have to resend any such files after the sequence number problem has been corrected.

There is no automatic process by which the Central Systems will alter the value of the next expected sequence number which it holds (either up or down), apart from the normal increment when a file is successfully received. The only method by which a BSC Party or Agent can achieve a change in the value of the next expected sequence number held by a Central System will be by manual agreement.

The rules for updating the next expected sequence number in the case of a NACK being generated are as follows:


  1. if a file is rejected because of problems with the HEADER the sequence number is not "used up" and so the next expected sequence number remains unchanged (NACK codes 1,2,3);

  2. if a file is rejected because of problems with the BODY or TRAILER (record count, checksum), the sequence number is used up and the next expected sequence number is incremented (NACK codes 4,5,6,7).

2.2.9 Time


All data items with data format datetime are in GMT.

Settlement Periods are integers defining a half hour period within a Settlement Day. These start at midnight local time, and are numbered sequentially from 1 to 46/48/50.


2.2.10 The CRA Encryption Key


In flow CRA-I012, the CRA system sends out an Encryption Key. How this is used is explained in [COMMS]. This flow is not sent electronically.

2.2.11 Valid Sets


This section defines the Valid Sets referred to in the repeating structure tables.

Note also that BSC Party Ids and BSC Party Agent Ids may contain only characters from this restricted set:



  1. A-Z

  2. 0-9

  3. - (dash)

BM Unit Ids, GSP Ids, GSP Group Ids, Interconnector Ids, Joint BMU Unit Ids and Metering System Ids may contain only characters from this restricted set:

  1. A-Z

  2. 0-9

  3. - (dash)

  4. _ (underscore)

2.2.11.1 Action Code


One of the values:

‘Change’ (New or updated record)

‘No Action’ (Record unchanged)

‘Delete’ (record deleted)



Note: The Action Code field is used in CRA reports to indicate changes since the previous issue of the report, which could include the application of several registration requests. The Action Description field is a free format text field used in registration requests to allow the participant to identify the reason and nature of the change to the CRA operator.

2.2.11.2 Activity


One of the values:

‘A’ (Changing Authorisations)

‘B’ (Accept / Reject Data Estimation)

‘C’ (Site Witness of Meter Readings and on-site Meter Readings)

‘D’ (Work on Metering Systems)

‘E’ (Submitting SVA Entry Process Requests)

‘EA’ – Discontinued (Raise / Agree Standing Data Changes)

‘F’ (BM Units)

‘G’ (Metering System Registrations and MOA Appointment)

‘H’ (Metering System Technical Details and Proving Tests)

‘I’ – Discontinued (TA Site Visit Acceptance)

‘J’ (Party Registration / Changes)

‘K’ (Submit / Terminate ECVNAA or MVRNAA)

‘L’ (Submitting Aggregation Rules)

‘M’ (Amend Report Requirements)

‘N’ (Banking Details Registration / Changes)

‘O’ (Query / Dispute Process)

‘P’ (Submitting CVA Line Loss Factors)

‘Q’ (Registration & Deregistration of Trading Units)

‘R’ (Metering Dispensations applications)

‘S’ (Party Withdrawal)

‘T’ (Transfer of Metering Systems between SMRS and CMRS)

‘U’ (Party Agent Registration & Changes to Details)

‘V’ (Transmission of Reports to all Parties)

‘W’ (Submitting SVA Standing Data Changes)

‘X’ (Submitting SVA Line Loss Factors)

‘Y’ (Submitting MDD Change Reports)

‘Z’ (Manage ECVAA Web Service access)

‘ZA’ (Register LDSO TSO Boundary Point)

‘ZB’ (Signing the SAD and the Qualification Letter and delegating authority for the signing of other Qualification related documentation)

‘ZC’ (A delegated person acting as the signing authority for that company’s Annual Statement of Qualified Status process, re-Qualification Letter and any other documentation relating to Qualification)


2.2.11.3 Alarm Code


One of the values:

Interval Status Codes:

‘PO’ (Power outages)

‘SI’ (Short intervals)

‘LI’ (Long intervals)

‘CR’ (CRC checksum errors)

‘RA’ (RAM checksum errors)

‘RO’ (ROM checksum errors)

‘LA’ (Data missing)

‘CL’ (Clock errors)

‘BR’ (Recorder hardware resets)

‘WT’ (Watchdog timeouts)

‘TR’ (Time resets)

‘TM’ (Test mode)

‘LC’ (Load control)

Channel Status Codes:

‘AD’ (Added interval)

‘RE’ (Replaced data)

‘ES’ (Estimated data)

‘OV’ (Data overflow)

‘HL’ (Data out of limits)

‘XC’ (Excluded data)

‘PY’ (Parity error)

‘TY’ (Energy type change)

‘LR’ (Alarm error)

‘DI’ (Harmonic distortion)


2.2.11.4 BM Unit Type


One of the values:

‘T’ (directly connected to the Transmission network)

‘E’ (Embedded)

‘G’ (GSP Group, default BM unit for a supplier)

‘I’ (Interconnector User)

‘S’ (GSP Group, Specific BM unit identified by a supplier)


2.2.11.5 Certification/Accreditation Status


One of the values:

‘1’ (applied for certification)

‘2’ (completed certification return)

‘3’ (certification report completed)

‘4’ (accredited)

‘5’ (accreditation removed)


2.2.11.6 Estimation method


One of the values:

‘A’ (Generation: Main meter data missing or incorrect in Primary and Secondary Outstations, Check meter data available – copied from Primary Check)

‘D’ (Demand: Main meter data missing or incorrect, Check meter data available – copied from Primary Check)

‘E’ (Demand: Main meter data missing or incorrect, Check meter not fully functional, but Main meter or Check meter register advance available – profiled using Meter Reading Estimation Tool)

‘I’ (Demand: Main meter data missing or incorrect, Check meter not fully functional, Main meter and Check meter register advance NOT available – profiled using Trend)

‘J’ (Generation: Main meter data missing, or incorrect, in Primary Outstation, Secondary Outstation main meter data available – substituted from Secondary Main)

‘K’ (Generation: Main and Check meter data missing or incorrect in Primary and Secondary Outstations, data estimated to zero awaiting confirmation of generation)

‘L’ (Demand; Primary Main meter data missing, or incorrect, Secondary Outstation Main meter data available – substituted from Secondary Main)

‘M’ (Demand: Main meter data missing or incorrect, data copied from suitable settlement period(s))

‘N’ (Validation Failure: Main meter data deemed correct)

‘U’ (Used party’s own reading)

‘X’ (Used different estimation method)


2.2.11.7 I/E Flag


One of the values:

‘I’ (Import)

‘E’ (Export)

2.2.11.8 L/S Flag


Either ‘L’ (Lead) or ‘S’ (Subsidiary). This is used in the Forward Contract Report (ECVAA-I022) to indicate whether the recipient of the report was the lead or subsidiary Party specified in a reported MVRNA Authorisation.

2.2.11.9 Main / Check Indicator


One of the values:

‘M’ (Main)

‘C’ (Check)

2.2.11.10 Measurement Quantity


One of the values:

‘AE’ (Active Export)

‘AI’ (Active Import)

‘RE’ (Reactive Export)

‘RI’ (Reactive Import)

2.2.11.11 Meter Reading Status


One of the values:

‘A’ (Valid)

‘B’ (Invalid)

‘C’ (Unavailable)

‘D’ (Substituted from Secondary Outstation Meter Data)

2.2.11.12 Multi-day Flag


One of the values:

‘M’ (Multi-day)

‘S’ (Single day)

Note that this flag is not used in any current report.


2.2.11.13 Organisation Type


One of the values:

‘BM’ (BMRA)

‘BC’ (BSCCo Ltd)

‘BP’ (BSC Party)

‘CD’ (CDCA)

‘CR’ (CRA)

‘DB’ (Distribution Business)

‘EC’ (ECVAA)

‘EN’ (ECVNA)

‘ER’ (Energy Regulator)

‘FA’ (FAA)

‘HA’ (Half Hourly Data Aggregator)

‘HC’ (Half Hourly Data Collector)

‘HP’ (Helpdesk)

‘IA’ (Interconnector Administrator)

‘IE’ (Interconnector Error Administrator)

‘MA’ (Meter Administration Agent)

‘MI’ (Market Index Data Provider)

‘MO’ (Half Hourly Meter Operator Agent))

‘MS’ (Supplier Meter Administration Agent)

‘MV’ (MVRNA)

‘NA’ (Non Half Hourly Data Aggregator)

‘NC’ (Non Half Hourly Data Collector)

‘NO’ (Non Half Hourly Meter Operator Agent)

‘PA’ (BSC Party Agent)

‘SA’ (SAA)

‘SG’ (BSC Service Agent)

‘SM’ (SMRA)

‘SO’ (System Operator)

‘SV’ (SVAA)

‘TA’ (TAA)

‘TG’ (Trading Party - Generator)

‘TI’ (Trading Party - Interconnector User)

'TL' (Transmission Loss Factor Agent)1

‘TN’ (Trading Party - Non-physical)

‘TS’ (Trading Party - Supplier)


2.2.11.14 Party Sequence


Either ‘1’ or ‘2’. This is used in the Forward Contract Report (ECVAA-I022) to indicate whether the recipient of the report was the first or second Party specified in a reported ECVNA Authorisation.

2.2.11.15 P/C Flag


One of the values:

‘P’ (Production)

‘C’ (Consumption)

2.2.11.16 P/C Status


One of the values:

‘P’ (Production)

‘C’ (Consumption)

2.2.11.17 Point Type


One of the values:

‘BG’ (Gensets connected to TS; boundary point)

‘BS’ (Station Transformer connected to TS; boundary point)

‘BD’ (Demand sites connected to TS; boundary point)

‘BI’ (Interconnector with other TS from TS; boundary point)

‘BE’ (Embedded > 50MW; boundary point)

‘BO’ (Other embedded; boundary point)

‘BT’ (Interconnector with other TS from DS; boundary point)

‘SG’ (Grid Supply Points; system connection point)

‘SD’ (Interconnector between Distribution Networks; system connection point)


2.2.11.18 Price Derivation Code


One of the values:

‘A’

(SBP = Main price; SSP = Reverse Price)

‘B’

(SSP Capped to SBP)

‘C’

(SSP Defaulted to SBP)

‘D’

(SBP & SSP Defaulted to Market Price)

‘E’

(SSP & SBP Defaulted to Zero)

‘F’

(SSP = Main Price; SBP = Reverse Price)

‘G’

(SBP Capped to SSP)

‘H’

(SBP Defaulted to SSP)

‘I’

(SBP & SSP Defaulted to Market Price)

‘J’

(SSP & SBP Defaulted to Zero)

‘K’

(SSP & SBP Defaulted to Market Price)

‘L’

(SSP & SBP Defaulted to Zero)

2.2.11.19 Registration Status


One of the values:

‘S’ (Successful Registration)

‘P’ (Registration Pending)

2.2.11.20 Registration Type


One of the values:

‘PY’ (BSC Party)

‘PA’ (BSC Party Agent)

‘SA’ (BSC Service Agent)

‘BM’ (BM Unit)

‘EI’ (Interconnector)

‘TU’ (Trading Unit)

‘BP’ (Boundary Point/System Connection Point)

‘MS’ (Metering System)

‘GG’ (GSP Group)

‘GS’ (GSP)

‘MI’ (Market Index Data Provider)


2.2.11.21 Run Type


One of the values:

‘II’ (Interim Initial)

‘SF’ (Initial Settlement)

‘R1’ (First Reconciliation)

‘R2’ (Second Reconciliation)

‘R3’ (Third Reconciliation)

‘RF’ (Final Reconciliation)

‘D’ (Dispute)

‘DF’ (Final Dispute)

(Multiple dispute runs for the same Settlement Date are distinguished using run number.)


2.2.12 Example File Formats


The first example is based on CDCA-I0041. A file defined like this in the spreadsheet:

C0411

F




























CDCA-I041: Interconnector Aggregation Report




































AIV

R

1-*

G






















Interconnector Aggregation Report

N0125

D







1













integer(10)




Interconnector Id

N0200

D







1













date




Settlement Date

AIP

R

46-50




G



















Aggregated Interconnector Volume - Period

N0201

D










1










integer(2)




Settlement Period

N0090

D










1










boolean




Estimate Indicator

N0062

D










1










date




Date of Aggregation

N0139

D










1










decimal(10,3)




Meter Volume

N0049

D










1










integer(2)




CDCA Run Number

N0121

D










1










char

I/E Flag

Import/Export Indicator

looks like this:

AAA|C0411001|D|20000204093055|CD|LOGICA|IA|FRANCE|516||

AIV|FRANCE|20000203|

AIP|1|F|20000204|501.2|1|E|

AIP|2|F|20000204|498.6|1|E|

..

AIP|48|F|20000204|468.9|1|E|



ZZZ|51|1067512|

Here are some more examples, based on the ECVN flow ECVAA-I004



An ECVN is defined as follows in the spreadsheet:

E0041

F




























ECVAA-I004: ECVNs





































EDN

R

1

G






















ECVNs

N0080

D







1













text(10)




ECVNAA Id

N0297

D







1













text(10)




ECVNAA Key

M0310

D







1













text(10)




ECVN ECVNAA Id

N0077

D







1













text(10)




ECVN Reference Code

N0081

D







1













date




Effective From Date

N0083

D







O













date




Effective To Date

OTD2

R

0-1




G



















Omitted Data No Change

N0483

D










1










boolean




No Change to Existing Data

CD9

R

0-*




G



















Energy Contract Volumes

N0201

D










1










integer(2)




Settlement Period

N0085

D










1










decimal(10,3)

MWh

energy contract volume

This allows the following file formats:

1) An open-ended ECVN for a single period (effective-to date field omitted):

AAA|E0041001|D|20000204093055|EN|ECVNA1|EC|LOGICA|545546||

EDN|00195|3444343|00195|ECV65011|20000207||

CD9|23|1445233.323|

ZZZ|4|1313360725|


2) Termination of the previous ECVN after a month (no CDV records):

AAA|E0041001|D|20000204103055|EN|ECVNA1|EC|LOGICA|545676||

EDN|00195|3444343|00195|ECV65011|20000207|20000307|

ZZZ|3|51341339|


3) ECVN covering a single (long) day (multiple CDV records):

AAA|E0041001|D|20000204113055|EN|ECVNA1|EC|LOGICA|545873||

EDN|1095|0634343|1095|ECV65043|20000208|20000208|

CD9|1|100|

CD9|2|100|

CD9|3|110.323|

CD9|4|0.9|

CD9|5|0|


….

CD9|45|120|

CD9|46|0|

CD9|47|-120|

CD9|48|-120.5|

CD9|49|-121.0|

CD9|50|-121.0|

ZZZ|53|456423424|




1   2   3   4   5   6   7   8   9   ...   82


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка