в графе 6 табл. – «Источник, по которому СО формирует данные по генерации (преобразователь ТМ или псевдоизмерения) – указываются последовательно с разделением знаком «;»:

-  диспетчерское наименование единицы генерирующего оборудования;

-  диспетчерское наименование сетевого элемента, на котором установлен датчик телеизмерений;

-  направление измеряемой энергии (прием; отдача, прием/отдача);

-  тип и класс датчика телеизмерений;

-  признак наблюдаемости в ОДУ (при отсутствии датчика телеизмерений указывается псевдоизмерения и источник информации, на основании которых формируется псевдоизмерения);

в графе 7 – «Примечания» – необходимые разъяснения.

Приложение 3.2

ОПИСАНИЕ ФОРМАТА И РЕГЛАМЕНТА ПЕРЕДАЧИ КО

ЭЛЕКТРОННОГО ДОКУМЕНТА «ЗАЯВКА О ПОДГОТОВКЕ БАЗЫ ДАННЫХ КО

ДЛЯ ПРИЕМА В ЭЛЕКТРОННОМ ВИДЕ ПЕРЕЧНЯ СРЕДСТВ ИЗМЕРЕНИЙ»

1. Предмет действия

Настоящий Порядок описывает формат и регламент предоставления в КО участниками оптового рынка или ФСК электронного документа, содержащего Заявку о подготовке базы данных КО для приема Перечня Средств измерений (далее – ПСИ) в электронном виде (далее – Заявка)

2. Общие положения

2.1. Заявка оформляется в виде макета 60070 с целью подготовки ПАК сбора данный КУ к приему макета 60090 (Перечень средств измерений, приложение 3 к настоящему Положению).

2.2. Заявка должна быть оформлена в строгом соответствии с требованиями настоящего Приложения и подписана ЭЦП участника оптового рынка или ФСК, полученной в соответствии с Соглашением о применении электронно-цифровой подписи в торговой системе оптового рынка (Приложение № Д7 к Договору о присоединении к торговой системе оптового рынка).

НЕ нашли? Не то? Что вы ищете?

2.3. В макете 60070 Участник оптового рынка или ФСК должен заявить информацию, относящуюся только к одному ПСИ для передачи одного электронного документа 60090.

2.4. Заявка может быть направлена в КО

– в отношении новой ГТП генерации (потребления) либо нового сечения коммерческого учета не ранее получения Инициатором положительной технической экспертизы на комплект документов, представленных для согласования новой ГТП потребления (ГТП генерации);

– при внесении изменений в ГТП потребления (генерации) либо при изменении ПСИ без внесения изменений в ГТП потребления (генерации) в соответствии с порядком и в сроки, указанные в приложении 3 к настоящему Положению.

2.5. Номер версии ПСИ в Заявке должен быть на единицу больше чем номер версии ПСИ с аналогичными кодами ГТП (кодом ГТП генерации), указанным в Заявке, находящегося в ПАК сбора данных КУ КО. Если в ПАК сбора данных КУ КО отсутствует ПСИ с кодами ГТП (кодом ГТП генерации), указанными в Заявке, то в Заявке указывается номер версии равный 1 (единице).

2.7. При передаче электронного документа используется расширяемый язык разметки (XML) в соответствии со спецификацией Extensible Markup Language (XML) 1.0.

2.8. При декларации кодировки, являющейся частью декларации XML, используются названия и псевдонимы русскоязычных наборов символов, зарегистрированных в Internet Assigned Numbers Authority. Для данного электронного документа используется кодировка “windows-1251”.

3. Регламент передачи

3.1. Передача электронных документов 60070 производится на адрес электронной почты *****@***com.

3.2. Полученная в КО Заявка обрабатывается в ПАК сбора данных КУ, где проводится ее машинный анализ.

3.3. В случае формирования файла в соответствии с требованиями настоящего приложения участнику оптового рынка или ФСК автоматически отправляется ответная квитанция о правильно сформированном электронном документе с точки зрения машинного анализа (макет 60071). В этом случае Заявка доступна для рассмотрения КО.

3.4. Если макет 60070 сформирован неверно с точки зрения машинного анализа (макет содержит ошибки структуры, указана более ранняя версия ПСИ, а также ИНН, ЭЦП, торговый код и код (-ы) ГТП в отношении данного субъекта оптового рынка не соответствуют регистрационной информации КО), то в ответной квитанции участнику оптового рынка или ФСК направляется список ошибок, обнаруженных при анализе полученного документа.

3.5. Макет 60071 формируется в виде документа XML, подписывается ЭЦП и отправляется по электронной почте на адрес участника оптового рынка или ФСК, с которого был получен макет 60070.

3.6. При отсутствии ответа КО в течение 120 минут после отправки Заявки, участник оптового рынка и ФСК должен повторить передачу Заявки в КО. Если с момента повторной передачи Заявки не получено ответа КО в течение 120 минут, то уполномоченное лицо организации, ответственное за передачу Заявки, должно связаться с представителем КО, ответственным за прием информации с целью локализации и устранения проблемы.

3.7. После принятия данных (макет 60070 не содержал структурные и криптографические ошибки) в ПАК сбора данных КУ КО проводит рассмотрение данной Заявки.

3.8. По результатам рассмотрения Заявки технологом КО участнику оптового рынка или ФСК отправляется на адрес электронной почты, с которой получен макет 60070 ответная квитанция (макет 60072) с результатами рассмотрения технологом КО Заявки.

3.9. Если Заявка была положительно рассмотрена КО (в Заявке указана информация, не содержащая ошибок и противоречий), участник оптового рынка или ФСК должен передать макет 60090 (ПСИ в электронном виде) в ПАК сбора данных КУ не позднее чем по истечению 10 (десяти) календарных дней.

3.10. В случае если КО отклонил Заявку, участник оптового рынка или ФСК для повторной процедуры должен исправить ошибки, указанные в ответной квитанции (макет 60072), и отправить в КО макет 60070 с исправленными замечаниями. В этом случае процедуры, описанные в настоящем приложении, выполняются повторно.

4. Описание форматов

4.1 Макет 60070

Имя файла

Имя файла, содержащего электронный документ, должно составляться в формате “<тип документа>_<ИНН>_<дата>”, где:

1)  тип документа – номер, присвоенный КО данному типу документа;

2)  ИНН – ИНН организации, направляющей ПСИ на согласование в КО, длина inn – 10 символов;

3)  дата – дата формирования заявки в формате “ГГГГММДДччммсс”, где ГГГГ – год, ММ – порядковый номер месяца, ДД – день, чч – час, мм – минуты, сс – секунды. Длина поля <дата> – 14 знаков.

Расширение файла ― xml.

Описание структуры документа (формат 60070)

4.1.1. Элемент <message> является корневым элементом. Потомками элемента <message> являются элементы <organization>, <peretok>, <deliverygroup>. В документе допускается наличие только одного корневого элемента <message>.

4.1.2. Атрибут class корневого элемента <message> является обязательным и содержит данные о типе электронного документа. Значение атрибута class должно быть равно 60070.

4.1.3. Атрибут version корневого элемента <message> является обязательным и содержит данные о версии формата.

4.1.4. Значением атрибута generationtime корневого элемента <message> является дата и время создания электронного документа. Дата и время создания электронного документа предоставляется в формате “ГГГГММДДччммссGMT+S”, где: ГГГГ – год, ММ – порядковый номер месяца, ДД – день, чч – час, мм – минуты, сс – секунды, GMT+S – сдвиг времени относительно времени по Гринвичу.

4.1.5. Элемент <organization> является потомком корневого элемента <message>. В документе допускается наличие только одного элемента <organization>. Элемент <organization> описывает организацию, сформировавшую заявку на получение кодов. Атрибутами элемента <organization> являются inn, name.

4.1.6. Атрибут inn элемента <organization> является обязательным и содержит ИНН организации, сформировавшей заявку.

4.1.7. Атрибут name элемента <organization> является обязательным и содержит название организации, сформировавшей заявку. Длина названия до 250 символов.

4.1.8. Элемент <peretok> является потомком корневого элемента <message>. В документе допускается наличие только одного элемента <peretok> или только одного элемента <deliverygroup>. Элемент <peretok> содержит сведения о сальдо перетоков между двумя группами точек поставки. Атрибутами элемента <peretok> являются code-from, сode-to, algorithmversion, name, reason. Потомками элемента <peretok> является элементы <techexpertiza> и <proverka-psi>.

-  содержимым атрибута name является наименование сечения КУ. Длина наименования до 250 символов. Наименование сечения коммерческого учета должно быть представлено в следующем виде: V.__{номер версии ПСИ, совпадает с algorithmversion в настоящем пункте} Переток ____{Наименование Заявителя (наименование объекта)} – ____{Наименование Смежника Заявителя} _______ (коды смежных ГТП потребления), при этом; наименование сечений коммерческого учета должно соответствовать наименованиям, указанному в Актах согласования ГТП потребления;

-  атрибут code-from содержит код ГТП потребления Заявителя, присвоенный КО;

-  атрибут code-to содержит код ГТП потребления смежного Участника оптового рынка или ФСК, присвоенный КО;

-  атрибут algorithmversion содержит номер версии ПСИ;

-  атрибут reason содержит сведения о причине направления ПСИ в электронном виде и может принимать следующие значения:

1 – новая ГТП;

2 – изменение ГТП;

3 – изменение алгоритма расчета потерь без изменения ГТП;

4 – изменение метода восстановления информации в случае выхода из строя ОИП и отсутствия РИП;

5 – изменение способа формирования ежедневного профиля нагрузки по «малым» ТП;

6 – замена приборов учета (электросчетчиков) без изменения состава ГТП и ТИ;

7 – изменение регистрационной информации в случае допуска к торговой системе оптового рынка Инициатора по новой или измененной ГТП, который влечет за собой изменение в сечении других участников оптового рынка или участника оптового рынка и ФСК, не входящего в состав ГТП потребления Инициатора;

8 – получение Акта АИИС по точкам измерения (ОИП и (или) РИП).

4.1.9. Элемент <deliverygroup> является потомком корневого элемента <message>. В документе допускается наличие только одного элемента <deliverygroup> или только одного элемента <peretok>. Элемент <deliverygroup> содержит сведения о группе точек поставки генерации. Атрибутами элемента <deliverygroup> являются code, algorithmversion, name. Потомками элемента <deliverygroup> является элементы <techexpertiza> и <proverka-psi>.

-  содержимым атрибута name является наименование данной ГТП генерации. Длина наименования до 250 символов. Наименование ГТП генерации должно быть представлено в следующем виде: «V.__{номер версии ПСИ, совпадает с algorithmversion в настоящем пункте} Генерация _____{Наименование Заявителя (наименование станции)} ______(код ГТП генерации)», при этом наименование ГТП генерации должно соответствовать наименованию, указанному в Акте согласования ГТП генерации;

-  атрибут code содержит уникальный код ГТП генерации, присвоенный КО;

-  атрибут algorithmversion содержит номер версии ПСИ;

-  атрибут reason содержит сведения о причине направления ПСИ электронном виде и может принимать следующие значения:

1 – новая ГТП;

2 – изменение ГТП;

4.1.10. При необходимости после элемента <reason> может быть размещен элемент-комментарий. Комментарии размещаются внутри специального тега, начинающегося с символов <!-- и заканчивающегося символами -->. Два знака дефис (--) внутри комментария присутствовать не могут.

4.1.11. Элемент <techexpertiza> содержит ссылку на номер и дату согласования Заключения технической экспертизы КО (далее – ТЭ). В документе допускается наличие только одного элемента <techexpertiza>. Атрибутами элемента <techexpertiza> являются number, date.

-  содержимым атрибута number является номер ТЭ, присвоенный КО. В начале номера указывается сокращенное наименование документа и далее следует номер документа без пробела;

-  атрибут date содержит дату регистрации соответствующего документа в формате “ГГГГММДДччммсс”, где ГГГГ – год, ММ – порядковый номер месяца, ДД – день.

4.1.12. Элемент <proverka-psi> является необязательным потомком элемента <deliverygroup> только при значениях атрибута reason равным 1. Элемент <proverka-psi> содержит ссылку на номер и дату регистрации действующего ПСИ. В документе допускается наличие только одного элемента <proverka-psi>. Атрибутами элемента <proverka-psi> являются number, date.

-  содержимым атрибута number является номер ПСИ, присвоенный КО;

-  атрибут date содержит дату регистрации соответствующего документа в формате “ГГГГММДДччммсс”, где ГГГГ – год, ММ – порядковый номер месяца, ДД – день.

Примеры макета 60070

1. Пример макета документа 60070 для ПСИ по сечению:

<?xml version="1.0" encoding="windows-1251" standalone="no"?>

<message class="60070" version="1" generationtime="GMT+03">

<organization inn="" name="Некоторая организация">

</organization>

<peretok code-from="PNEKGRES" code-to="PNEKITES" name=" V.1 Переток Заявителя» - Смежника Заявителя» (PXXXXXXX-PYYYYYYY)" algorithmversion="1" reason="1">

<!-- -->

<techexpertiza number="Техническая_экспертиза-2787/10" date="">

</techexpertiza>

<proverka-psi number="ПСИ-1/5" date="">

</proverka-psi>

</peretok>

</message>

2. Пример электронного входного документа 60070 для ПСИ по ГТП генерации

<?xml version="1.0" encoding="windows-1251" standalone="no"?>

<message class="60070" version="1" generationtime="GMT+03">

<organization inn="" name="Некоторая организация">

</organization>

<deliverygroup code="GNEKGRES" name=" V.4 Генерация Заявителя» (ТЭЦ1) (GXXXXXXX)" algorithmversion="4" reason="2">

<!-- -->

<techexpertiza number="ТЭ2770-10" date="">

</techexpertiza>

<proverka-psi number="ПСИ-1/30" date="">

</proverka-psi>

</deliverygroup >

</message>

4.2 Макет 60071 – Ответная квитанция на макет 60070 (машинный разбор)

Макет 60071

Описание структуры

1.  Корневым элементом электронного документа является <message>. В документе допускается наличие только одного элемента <message>. Потомками элемента <message> являются элементы <file>, <reply>.

2.  Атрибут class элемента <message> является обязательным и содержит данные о типе документа. Значение атрибута class должно быть равно 60071.

3.  Атрибут version элемента <message> является обязательным и содержит данные о версии документа. Текущее значение версии равно 2.

4.  Атрибут id элемента <message> является необязательным и содержит уникальный цифровой код квитанции.

5.  Атрибут datetime элемента <message> является необязательным и содержит дату создания ответной квитанции в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды.

6.  Элемент <file> является потомком корневого элемента <message> и содержит информацию о вложенном в электронное сообщение файле XML формата 60070. В документе допускается наличие только одного элемента <file>. Потомками элемента <file> являются элементы <fromaddr>, <name>, <sender>, <day>, <id>, <received>.

7.  Элемент <fromaddr> является необязательным потомком элемента <file> и содержит адрес электронной почты, с которой пришло письмо, содержащее входящий макет 60070, и на который была сформирована данная ответная квитанция.

8.  Элемент <name> является обязательным потомком элемента <file> и содержит название макета 60070, на который была сформирована данная ответная квитанция.

9.  Элемент <sender> является необязательным потомком элемента <file> и содержит ИНН организации –поставщика информации, которая сформировала входящий файл

10.  Элемент <day> является необязательным потомком элемента <file> и содержит сутки, на которые был сформирован входящий файл в формате ГГГГММДД, где ГГГГ – год, ММ – месяц, ДД – день.

11.  Элемент <id> является обязательным потомком элемента <file> и содержит код входящего XML-файла в ПАК сбора данных КУ.

12.  Элемент <received> является обязательным потомком элемента <file> и содержит дату получения входящего файла системой ПАК сбора данных КУ в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды.

13.  Элемент <reply> является обязательным потомком корневого элемента <message> и содержит информацию по ошибкам присланного Заявителем файла и статусу его обработки в ПАК сбора данных КУ. В документе допускается наличие только одного элемента <reply>. Потомками элемента <reply> являются элементы <error> и <comment>.

14.  Атрибут filestatus элемента <reply> является необязательным и содержит цифровой код статуса обработки файла. Может принимать следующие значения: 0 ― ошибок при обработке не обнаружено, данные приняты; 3 ― файл содержал ошибки.

15.  Атрибут desc элемента <reply> является и содержит короткое текстовое описание кода статуса обработки из атрибута filestatus.

16.  Элемент <error> является необязательным потомком элемента <reply> и содержит текст ошибки, найденной во входящем файле.

17.  Атрибут type элемента <error> является необязательным и содержит цифровой код типа ошибки.

18.  Атрибут subtype элемента <error> является необязательным и содержит цифровой код подтипа ошибки.

Пример макета 60071

<?xml version="1.0" encoding="windows-1251"?>

<message class="60071" version="2" id="" datetime="">

<file>

<fromaddr><![CDATA[*****@***ru]]></fromaddr>

<name>60070__.xml</name>

<sender></sender>

<day></day>

<id>4105080</id>

<received></received>

</file>

<reply filestatus="0" desc="Заявка на рассмотрении.">

</reply>

</message>

4.3 Макет 60072 – Ответная квитанция на макет 60070 (действия технолога КО)

Описание структуры

1.  Корневым элементом электронного документа является <message>. В документе допускается наличие только одного элемента <message>. Потомками элемента <message> являются элементы <file>, <reply>.

2.  Атрибут class элемента <message> является обязательным и содержит данные о типе документа. Значение атрибута class должно быть равно 60072.

3.  Атрибут version элемента <message> является обязательным и содержит данные о версии документа. Текущее значение версии равно 2.

4.  Атрибут id элемента <message> является и содержит уникальный цифровой код квитанции.

5.  Атрибут datetime элемента <message> является и содержит дату создания ответной квитанции в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды.

6.  Элемент <file> является потомком корневого элемента <message> и содержит информацию о вложенном в электронное сообщение Заявителя файле XML формата 60070. В документе допускается наличие только одного элемента <file>. Потомками элемента <file> являются элементы <fromaddr>, <name>, <sender>, <day>, <id>, <received>.

7.  Элемент <fromaddr> является потомком элемента <file> и содержит адрес электронной почты, с которой пришло письмо, содержащее входящий макет 60070, и на который была сформирована данная ответная квитанция.

8.  Элемент <name> является обязательным потомком элемента <file> и содержит название макета 60070, на который была сформирована данная ответная квитанция.

9.  Элемент <sender> является потомком элемента <file> и содержит ИНН организации – поставщика информации, которая сформировала входящий файл.

10.  Элемент <day> является потомком элемента <file> и содержит сутки, на которые был сформирован входящий файл в формате ГГГГММДД, где ГГГГ – год, ММ – месяц, ДД – день.

11.  Элемент <id> является обязательным потомком элемента <file> и содержит код входящего XML-файла в ПАК сбора данных КУ.

12.  Элемент <received> является обязательным потомком элемента <file> и содержит дату получения входящего файла системой ПАК сбора данных КУ в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды.

13.  Элемент <reply> является обязательным потомком корневого элемента <message> и содержит информацию по ошибкам присланного Заявителем файла и статусу его обработки в ПАК сбора данных КУ. В документе допускается наличие только одного элемента <reply>. Потомком элемента <reply> является элемент <comment>.

14.  Атрибут desc элемента <reply> содержит данные о результатах рассмотрения Заявки: «Заявка принята» или «Заявка отклонена».

Элемент <comment> является необязательным в случае положительного результата рассмотрения Заявки, либо содержит дополнительную информацию о причинах отрицательного результата рассмотрения Заявки. Причины отрицательного результата рассмотрения Заявки формируются технологом КО и должны соответствовать одному или нескольким нижеперечисленным критериям:

– отсутствует положительная техническая экспертиза в отношении сечения (ГТП генерации);

– причина направления ПСИ не совпадает с причинами, указанными в технической экспертизе;

– не совпадают реквизиты положительной технической экспертизы (номер, дата);

– не правильно указана версия ПСИ;

– не правильно указаны код (-ы) ГТП генерации (потребления);

– не правильно указаны наименование ГТП генерации или наименование сечения

Пример макета 60072

<?xml version="1.0" encoding="windows-1251" ?><message class="60072" version="2" id="CC1A2861AEEB3F14E04010ACF0017E8E" datetime="">

<file>

<fromaddr><![CDATA[*****@***ru]]></fromaddr>

<name>60070__.xml</name>

<sender></sender>

<day></day>

<id>4104402</id>

<received></received>

</file>

<reply desc="Заявка отклонена.">

<comment><![CDATA[В поле \"наименование\" не указано: коды ГТП смежных участников (п. 4.1.8 приложения 3.2 к Положению о порядке получения статуса субъекта оптового рынка и ведения реестра субъектов оптового рынка (Приложение № 1.1 к Договору о присоединении к торговой системе оптового рынка))]]></comment>

</reply>

</message>

Приложение 3.3

ОПИСАНИЕ ФОРМАТА И РЕГЛАМЕНТА ПЕРЕДАЧИ КО

ЭЛЕКТРОННОГО ДОКУМЕНТА «ПЕРЕЧНЯ СРЕДСТВ ИЗМЕРЕНИЙ»

1.  Предмет действия

Настоящий Порядок устанавливает описание формата и регламента предоставления в КО участниками оптового рынка или ФСК электронного документа, содержащего Перечень средств измерений для целей коммерческого учета по точкам поставки в сечении (генерации) (далее ― ПСИ).

2.  Общие положения

2.1. ПСИ оформляется участником оптового рынка (по ГТП генерации) или участниками оптового рынка (ФСК) (в отношении смежного сечения) в виде макета 60090.

2.2. ПСИ должен быть оформлен в строгом соответствии с требованиями настоящего Приложения, не должен противоречить требованиям к содержащейся в нем информации, описанным в приложениях 3 и 3.1 к настоящему Положению, и подписан двумя ЭЦП (участниками оптового рынка (ФСК) в отношении ПСИ по смежному сечению либо участником оптового рынка и СО в отношении ГТП генерации), полученной в соответствии с Соглашением о применении электронно-цифровой подписи в торговой системе оптового рынка (Приложение № Д7 к Договору о присоединении к торговой системе оптового рынка).

2.3. Для автоматизированного разбора коды ТП и ТИ (по закодированным объектам ОИП) должны соответствовать кодам, присвоенным при проведении процедуры кодирования ТИ и ТП, проводимой по п. 2.6.4 настоящего Положения. Если РИПы установлены в ТИ, которые были закодированы КО, то в отношении указанных ТИ и соответствующих им ТП также должны передаваться коды, присвоенные при проведении процедуры кодирования ТИ и ТП, проводимой по п. 2.6.4 настоящего Положения.

2.4. В одном файле макета 60090 участник оптового рынка или ФСК должен передать информацию, относящуюся только к одному сечению коммерческого учета или одной ГТП генерации.

2.5. При передаче электронного документа используется расширяемый язык разметки (XML) в соответствии со спецификацией Extensible Markup Language (XML) 1.0.

2.6. При декларации кодировки, являющейся частью декларации XML, используются названия и псевдонимы русскоязычных наборов символов, зарегистрированных в Internet Assigned Numbers Authority. Для данного электронного документа используется кодировка “windows-1251”.

3.  Регламент передачи

3.1. Передача электронных документов 60090 производится на адрес электронной почты (*****@***com).

3.2. Макет 60090 может быть передан после подготовки КО ПАК сбора данных КУ для приема электронного документа. Подготовка ПАК сбора данных КУ осуществляется после передачи участником оптового рынка Заявки в виде макета 60070 и получения от КО положительного результата рассмотрения Заявки в виде макета 60072 (Формат и регламента передачи в приложении 3.2 к настоящему Положению). При передаче макета 60090 до момента подготовки КО ПАК сбора данных КУ для приема электронного документа данный файл не будет принят КО и участник оптового рынка получит ответную квитанцию (макет 60091) с уведомлением об ошибке.

3.3. Участник оптового рынка должен передать ПСИ в электронном виде с двумя ЭЦП не позднее чем по истечении 10 (десяти) календарных дней с момента отправки ответной квитанции об успешной подготовке ПАК сбора данных КУ от КО (макет 60072, приложение 3.2 к настоящему Положению). В случае получения участником оптового рынка ответной квитанции с отрицательными результатами проверки ПСИ (макет 60092) участник оптового рынка должен передать исправленный ПСИ в электронном виде не позднее, чем по истечению 30 (тридцати) календарных дней с момента получения ответной квитанции с отрицательными результатами проверки ПСИ (макет 60092). При превышении указанных в настоящем пункте сроков для предоставления ПСИ в электронном виде участник оптового рынка должен передать в КО новую Заявку в виде макета 60070 с аналогичными кодами ГТП и версией ПСИ.

3.4. Полученный КО ПСИ в электроном виде обрабатывается в ПАК сбора данных КУ, где проводится его анализ.

3.5. После обработки файла участнику оптового рынка автоматически отправляется ответная квитанция о правильно сформированном электронном документе с точки зрения возможности машинного разбора информации (макет 60091).

3.6. Если макет 60090 сформирован неверно с точки зрения возможности машинного разбора информации (макет содержит ошибки структуры, указана более ранняя версия ПСИ, неверно указаны коды ТИ и ТП, а также ИНН, ЭЦП, торговый код и код (-ы) ГТП в отношении данного субъекта оптового рынка не соответствуют регистрационной информации КО), то в ответной квитанции участнику оптового рынка направляется список ошибок, обнаруженных при анализе полученного документа. Для формирования ПСИ участник оптового рынка должен исправить ошибки, указанные в макете 60091, и повторить передачу ПСИ в электронном виде в КО.

3.7. Макет 60091 формируется в виде документа XML, подписывается ЭЦП КО и отправляется по электронной почте на адрес участника оптового рынка, с которого был получен макет 60090.

3.8. При отсутствии ответа КО в течение 120 минут после отправки ПСИ в электронном виде, участник оптового рынка должен повторить передачу электронного документа в КО. Если с момента повторной передачи ПСИ не получено ответа КО в течение 120 минут, то уполномоченное лицо организации, ответственное за передачу ПСИ, должно связаться с представителем КО, ответственным за прием информации с целью локализации и устранения проблемы.

3.9. До окончания текущих суток, в которые был сформирован алгоритм расчета учетного показателя в ПАК сбора данных КУ на основе макета 60090, возможна повторная передача документа в КО. В этом случае при получении в ПАК сбора данных КУ измененного ПСИ с большим номером или датой создания, но с аналогичными кодами ГТП и номером версии ПСИ, и не имеющего ошибок формата (макет 60090 не содержал структурные ошибки или ошибки, связанные со сроками передачи данных) и криптографии, вся информация, переданная предыдущим документом, в полном объеме замещается информацией из документа, имеющего более старшую дату создания. Замещение не происходит только в том случае, когда более поздний документ имеет ошибки формата и структуры.

3.10. После формирования алгоритма расчета учетного показателя в ПАК сбора данных КУ на основе макета 60090 проводится проверка ПСИ.

3.11. По результатам проверки ПСИ участнику оптового рынка отправляется ответная квитанция с ее результатами (макет 60092), на адрес электронной почты, с которой получен макет 60090.

3.12. Если результаты проверки ПСИ положительные, то КО регистрирует ПСИ в соответствии с п. 1.9 приложения 3 к настоящему Положению.

3.13. В случае если результаты технической экспертизы отрицательные, участник оптового рынка для повторной процедуры должен исправить ошибки, указанные в ответной квитанции (макет 60092), согласовать (подписать с двух сторон ЭЦП) ПСИ со смежным участником оптового рынка (ФСК) либо с СО (в отношении ГТП генерации) и отправить в КО макет 60090 с исправленными замечаниями. В этом случае процедуры, описанные в настоящем Приложении, выполняются повторно.

4. Описание форматов

4.1 Макет 60090 – ПСИ в электронном виде

Описание формата ПСИ (макет 60090)

Имя файла, содержащего электронный документ, должно составляться в формате

“<тип документа >_<ИНН>_<дата>”, где:

–  тип документа – номер, присвоенный КО данному типу документа (60090);

–  ИНН – ИНН организации, направляющей ПСИ на согласование в КО, длина inn – 10 символов;

–  дата создания файла в формате “ГГГГММДДЧЧММСС”, где ГГГГ – год, ММ – порядковый номер месяца, ДД – день, ЧЧ – часы, ММ – минуты, СС – секунды. Длина поля <дата> – 8 знаков.

Расширение файла ― xml.

Описание структуры документа (тип 60090)

Элемент <message> является корневым элементом. Потомками элемента <message> являются элементы <organization> <deliverypoints>, <peretoks>, <generations>, <consumptions>. Атрибутами элемента <message> являются class, version, number, created. В документе допускается наличие только одного корневого элемента <message>:

–  атрибут class элемента <message> является обязательным и содержит данные о типе электронного документа. Значение атрибута class должно быть равно 60090;

–  атрибут version корневого элемента <message> является обязательным и содержит данные о версии формата;

–  атрибут created элемента <message> является обязательным и содержит дату создания документа.

Элемент <organization> является потомком корневого элемента <message>. В документе допускается наличие только одного элемента <organization>. Элемент <organization> описывает организацию, сформировавшую ПСИ. Атрибутами элемента <organization> являются inn, name.

–  Атрибут inn элемента <organization> является обязательным и содержит ИНН организации, сформировавшей ПСИ.

–  Атрибут name элемента <organization> является обязательным и содержит название организации, сформировавшей ПСИ. Длина названия до 250 символов.

 Элемент <deliverypoints> содержит сведения о точках поставки/совокупностях «малых» точек поставки. Потомками элемента <deliverypoints> являются элементы <deliverypoint>.

 Элемент <deliverypoint> в случае, когда он является потомком элемента <deliverypoints>, содержит сведения о точке поставки/совокупности «малых» точек поставки и формулах расчета сальдо перетоков в ТП. Атрибутами элемента <deliverypoint> являются aiiscode, number, balance_border code, name и algorithmversion. Потомками элемента <deliverypoint> являются элементы <send>, <receive>, <send-losses>, <receive-losses>, <balance-losses>.

–  атрибут aiiscode содержит код АИИС, присвоенный КО;

–  содержимым атрибута name является наименование данной точки поставки/совокупности «малых» точек поставки. Длина наименования до 250 символов. Атрибут является необязательным;

–  атрибут code содержит уникальный код, присвоенный КО точке поставки/совокупности «малых» точек поставки;

–  balance_border содержит описание расположения границы балансовой принадлежности.

Элементы <send>, <receive> содержат сведения об использовании в расчете активной отдачи и активного приема соответственно. Потомками элементов <send>, <receive> являются элементы <calcsum>, <calcformula>.

Элементы <calcsum> содержат сведения об измерительных каналах. Атрибутами элемента <calcsum> являются losses-coefficient (только в случае, если элемент <calcsum> является потомком элементов <send> либо <receive>). Потомками элементов <calcsum> являются элементы <measuringchannel>:

–  атрибут losses-coefficient содержит К – коэффициент, определяющий знак, с которым величина потерь входит в расчет активного приема/активной отдачи.

Элементы <measuringchannel> содержат информацию об измерительных каналах. Атрибутами элемента <measuringchannel> являются mpCode, aiiscode, version, code, sender, coefficient, devicemodel, device_type, note:

–  атрибут mpCode содержит код точки измерения, присвоенный КО. Атрибут mpCode является обязательным в отношении точек измерения, включенных в АИИС либо отнесенных к группе «малых» точек;

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4