в графе 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 |


