Заседание Наблюдательного совета НП «Совет рынка» от 30 марта 2012 года по вопросу № 3 «Об изменениях и дополнениях к Договору о присоединении к торговой системе оптового рынка и Положению о порядке получения статуса субъекта оптового рынка и ведения реестра субъектов оптового рынка» Изменения, связанные с оптимизацией работы в электронном документообороте Инициатор: ОАО «АТС». Обоснование: в действующем порядке описаны процедуры передачи, обработки и подтверждения алгоритмов расчета учетных показателей, используемых, в том числе, в процедуре установления соответствия АИИС КУЭ техническим требованиям ОРЭМ. Однако некоторые вопросы требуют доработки: сокращение срока начала обработки Алгоритмов; отмена предоставления Заявки на бумажном носителе с целью получения кодов и подготовки БД для приема Алгоритма в электронном виде; уточнение в описании взаимодействия Участников ОРЭМ или ФСК и КО в части обмена электронными документами; предоставление возможности передачи Алгоритма в электронном виде для установления соответствия АИИС для Участников ОРЭМ или ФСК, имеющих право покупки/продажи электроэнергии и не имеющих действующих Актов соответствия АИИС; внести уточнения в описание документов, применяемых в электронном документообороте; привести описание ответных квитанций (макеты 70001, 80011, 70071, 70072, 80072). Дата вступления в силу: 1 мая 2012 года. Предложения по изменениям и дополнениям в РЕГЛАМЕНТ КОММЕРЧЕСКОГО УЧЕТА ЭЛЕКТРОЭНЕРГИИ И МОЩНОСТИ (Приложение № 11 к Договору о присоединении к торговой системе оптового рынка) № пункта Приложение 5 Редакция, действующая на момент Предлагаемая редакция вступления в силу изменений (изменения выделены цветом) Пример № 3 Акта согласования алгоритма расчета величины Удалить пример № 3 сальдо перетоков электроэнергии в электронном документе формата 80070: <?xml version="1.0" encoding="Windows-1251" standalone="yes"?> <message created="20100115114823" number="1" version="1" class="80070"> <sender name="Некоторая организация" inn="1234567890"/> <deliverypoints> <deliverypoint code="111333555777999" name="Генератор 1Г" algorithmversion="1" aiiscode="1357924680"> <receive> <calcsum losses-coefficient="1"> <measuringchannel coefficient="1" aiiscode="1357924680" code="01" mpcode="123123123123123"/> <measuringchannel coefficient="1" aiiscode="1357924680" code="01" mpcode="456456456456456"/> </calcsum> </receive> <receive-losses time-ratio="30"> <calcformula name="SUM1"> <param type="FORMULA" name="Wa"> <calcformula name="SUM1"> <param type="FORMULA" name="Wa"> <calcformula name="Квадратичная зависимость 2"> <param type="CONST" name="a"> <constvalue>1.995</constvalue> </param> <param type="CONST" name="b"> <constvalue>1.0E7</constvalue> </param> <param type="CONST" name="c"> <constvalue>0.0</constvalue> </param> <param type="SUM" name="Wa"> <calcsum> <measuringchannel coefficient="1" aiiscode="1357924680" code="01" mpcode="123123123123123"/> </calcsum> </param> <param type="SUM" name="Wq"> <calcsum> <measuringchannel coefficient="1" aiiscode="1357924680" code="03" mpcode="123123123123123"/> </calcsum> </param> </calcformula> </param> <param type="FORMULA" name="Wb"> <calcformula name="Квадратичная зависимость 2"> <param type="CONST" name="a"> <constvalue>1.995</constvalue> </param> <param type="CONST" name="b"> <constvalue>1.0E7</constvalue> </param> <param type="CONST" name="c"> <constvalue>0.0</constvalue> </param> <param type="SUM" name="Wa"> <calcsum> <measuringchannel coefficient="1" aiiscode="1357924680" code="01" mpcode="456456456456456"/> </calcsum> </param> <param type="SUM" name="Wq"> <calcsum> <measuringchannel coefficient="1" aiiscode="1357924680" code="03" mpcode="456456456456456"/> </calcsum> </param> </calcformula> </param> </calcformula> </param> <param type="FORMULA" name="Wb"> <calcformula name="Квадратичная зависимость 2"> <param type="CONST" name="a"> <constvalue>1.0</constvalue> </param> <param type="CONST" name="b"> <constvalue>1.0E7</constvalue> </param> <param type="CONST" name="c"> <constvalue>27.358</constvalue> </param> <param type="SUM" name="Wa"> <calcsum> <measuringchannel coefficient="1" aiiscode="1357924680" code="01" mpcode="123123123123123"/> <measuringchannel coefficient="1" aiiscode="1357924680" code="01" mpcode="456456456456456"/> </calcsum> </param> <param type="SUM" name="Wq"> <calcsum> <measuringchannel coefficient="1" aiiscode="1357924680" code="03" mpcode="123123123123123"/> <measuringchannel coefficient="1" aiiscode="1357924680" code="03" mpcode="456456456456456"/> </calcsum> </param> </calcformula> </param> </calcformula> </receive-losses> </deliverypoint> <deliverypoint code="222444666888000" name="Генератор 4Г" algorithmversion="1" aiiscode="1357924680"> <send> <calcsum> <measuringchannel coefficient="1" aiiscode="1357924680" code="02" mpcode="789789789789789"/> </calcsum> </send> </deliverypoint> <deliverypoint code="111222333444555" name="Генератор 8Г" algorithmversion="1" aiiscode="1357924680"> <send> <calcsum> <measuringchannel coefficient="1" aiiscode="1357924680" code="02" mpcode="157157157157157"/> </calcsum> </send> </deliverypoint> </deliverypoints> <peretoks> <peretok enddate="300001010000" startdate="200712010000" code- to="PNEKITES" code-from="PNEKGRES" name="Переток (PNEKGRES-PNEKITES)" algorithmversion="1" aiiscode="1357924680"> <deliverypoint-send coefficient="1" aiiscode="1357924680" algorithmversion="1" code="222444666888000"/> <deliverypoint-send coefficient="1" aiiscode="1357924680" algorithmversion="1" code="111222333444555"/> <deliverypoint-receive coefficient="-1" aiiscode="1357924680" algorithmversion="1" code="111333555777999"/> </peretok> </peretoks> <generations/> </message> Приложени е 5.1, п. 1 ПОРЯДОК И ФОРМАТ ПЕРЕДАЧИ В ОАО «АТС», СМЕЖНЫМ УЧАСТНИКАМ ОПТОВОГО РЫНКА И ОАО «ФСК ЕЭС» ЭЛЕКТРОННОГО ДОКУМЕНТА «АКТ СОГЛАСОВАНИЯ АЛГОРИТМА РАСЧЕТА ВЕЛИЧИНЫ САЛЬДО ПЕРЕТОКОВ ЭЛЕКТРОЭНЕРГИИ В СЕЧЕНИИ МЕЖДУ ГТП ПОТРЕБЛЕНИЯ (ВЕЛИЧИНЫ ПРОИЗВЕДЕННОЙ ЭЛЕКТРОЭНЕРГИИ В ГТП ГЕНЕРАЦИИ)». ДОКУМЕНТ 80070 1. ОПИСАНИЕ ФОРМАТА И РЕГЛАМЕНТА ПЕРЕДАЧИ КО, СМЕЖНЫМ УЧАСТНИКАМ ОПТОВОГО РЫНКА И ФСК ЭЛЕКТРОННОГО ДОКУМЕНТА «АКТ СОГЛАСОВАНИЯ АЛГОРИТМА РАСЧЕТА ВЕЛИЧИНЫ САЛЬДО ПЕРЕТОКОВ ЭЛЕКТРОЭНЕРГИИ В СЕЧЕНИИ МЕЖДУ ГТП ПОТРЕБЛЕНИЯ (ВЕЛИЧИНЫ ПРОИЗВЕДЕННОЙ ЭЛЕКТРОЭНЕРГИИ В ГТП ГЕНЕРАЦИИ)» 1. Предмет действия Настоящее Приложение устанавливает описание формата и регламента предоставления в КО Участниками оптового рынка или ФСК электронного документа, содержащего проект Акта согласования алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП потребления (величины произведенной электроэнергии в ГТП генерации) (далее ― Алгоритм). Предмет и сфера действия Порядка Предмет Настоящий Порядок устанавливает порядок и формат предоставления в КО Участниками оптового рынка и ФСК электронного документа, содержащего Акт согласования алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП потребления (величины произведенной электроэнергии в ГТП генерации) (далее ― Акт). Сфера действия Положения настоящего Порядка распространяются: 1) на Участников оптового рынка электроэнергии; 2) на ФСК; 3) на КО. Приложени е 5.1, п. 2 2. Общие положения 2. Общие положения 2.1. Предоставление Акта в электронном виде производится с 2.1. Проект Алгоритма оформляется Участником оптового рынка или использованием присвоенных КО кодов ГТП, АИИС, точек ФСК в виде макета 80070 с целью формирования Алгоритма расчета поставки и точек измерений. учетного показателя в ПАК сбора данных КУ КО, а также возможности взаимодействия со смежными участниками оптового 2.2. Перечень кодов точек измерений, точек поставки, средств измерений, кодов АИИС, кодов групп передаваемой рынка и(или) ФСК. информации КО направляет Участнику оптового рынка по окончании процедуры кодирования на основании опросных 2.2 Проект Алгоритма должен быть оформлен в строгом соответствии с листов, предоставленных в КО. Коды объектов измерений требованиями настоящего Приложения, не должен противоречить присваиваются КО по запросу на основании вариантов схем требованиям к содержащейся в нем информации, описанным в электроснабжения, за исключением случаев использования приложении 5 к настоящему Регламенту и подписан ЭЦП Участника данных о работе через обходной выключатель (поскольку оптового рынка или ФСК, полученной в соответствии с данные о работе через обходной выключатель передаются Соглашением о применении электронно-цифровой подписи в при передаче результатов измерений). торговой системе оптового рынка (Приложение Д 7 к Договору о Дополнительно по запросу Участника оптового рынка для присоединении к торговой системе оптового рынка). автоматизированного разбора информации КО предоставляет коды в XML файле с использованием ЭЦП 2.3. Для автоматизированного разбора информации (кодов ТП и ТИ) с (Описание, пример и форма официального запроса целью формирования алгоритма расчета учетных показателей в документа 80000 приведены в Приложении № 11.1.1 к электронном виде Участник оптового рынка или ФСК может Положению о порядке получения статуса субъекта оптового рынка и запросить у КО в виде макета 80000 коды точек поставки и точек ведения реестра субъектов оптового рынка «Формат и регламент измерения, а также коды ГТП генерации и(или) сечений КУ в случае предоставления результатов измерений, состояний средств и включения их для передачи информации в КО (описание и пример объектов измерений в ОАО «АТС», ОАО «СО ЕЭС» и приведены в приложении 18 к Приложению № 11.1.1). Запрос на смежным субъектам»). получение макета 80000 оформляется в виде макета 70000. Формат и регламент передачи в КО макета 70000 описан в приложении 19 к 2.3. Передача Акта в электронном виде осуществляется с настоящему документу. использованием электронно-цифровой подписи, полученной в соответствии с Соглашением о применении электронно-цифровой подписи в торговой системе оптового 2.4. В одном файле макета 80070 Участник оптового рынка или ФСК должен передать информацию, относящуюся только к одному рынка. сечению коммерческого учета или одной ГТП генерации. 2.4. Для передачи Акта используется тип документа 80070. 2.5. При передаче электронного документа используется расширяемый 2.5. При передаче электронного документа используется язык разметки XML в соответствии со спецификацией Extensible расширяемый язык разметки (XML) в соответствии со Markup Language (XML) 1.0. спецификацией Extensible Markup Language (XML) 1.0. 2.6. При декларации кодировки, являющейся частью декларации XML, 2.6. При декларации кодировки, являющейся частью декларации используются названия и псевдонимы русскоязычных наборов XML, используются названия и псевдонимы русскоязычных символов, зарегистрированных в Internet Assigned Numbers Authority. наборов символов, зарегистрированных в Internet Assigned Для данного электронного документа используется кодировка Numbers Authority. Для данного электронного документа “windows-1251”. используется кодировка “windows-1251”. 2.7. Каждый электронный документ должен информацию, относящуюся к одному Акту. содержать Приложени е 5.1, п.3 3. Регламент передачи 3. Регламент передачи и обработки 3.1. Перед отправкой документа 80070 в КО, Участнику оптового 3.1. Передача макета 80070 производится на адрес электронной почты рынка необходимо направить запрос на бумажном носителе iasuku_crypto@rosenergo.com. или в формате XML (документ 70070) с использованием 3.2 Макет 80070 может быть передан после подготовки КО ПАК сбора ЭЦП о подготовке базы данных для приема Акта в данных КУ для приема электронного документа. Подготовка ПАК электронном виде с указанием кодов ГТП и номера версии сбора данных КУ осуществляется после передачи Участником Акта. При передаче запроса в электронном виде оптового рынка или ФСК Заявки в виде макета 70070 (Формат и представление его на бумажном носителе не требуется. регламента передачи в приложении 5.2 к настоящему Регламенту). Форма и описание формата официального запроса При передаче макета 80070 до момента подготовки КО ПАК сбора приведены в приложениях 5.2 и 5.3 настоящего Регламента. данных КУ для приема электронного документа данный файл не 3.2. При получении официального ответа на запрос о подготовке будет принят КО и Участник оптового рынка или ФСК получит базы данных для приема Акта в электронном виде участнику ответную квитанцию с уведомлением об ошибке. необходимо выставить в электронном документе время 3.3. Участник оптового рынка или ФСК должен передать Алгоритм в начала и окончания действия Акта, где начало действия Акта электронном виде не позднее чем по истечению 30(тридцати) – 1 число текущего месяца. календарных дней с момента отправки ответной квитанции об 3.3. В случае отсутствия передачи документа 80070 в течение 3 успешной подготовке ПАК сбора данных КУ от КО (макет 70072, месяцев со дня официального ответа от КО на письмо о приложение 5.2 к настоящему Регламенту) либо ответной квитанции подготовке базы данных для приема Акта в электронном виде с отрицательными результатами технической экспертизы (макет фиксируется отказ принятия документа 80070. 80072). При превышении указанного в настоящем пункте срока для предоставления Алгоритма в электронном виде Участник оптового 3.4. Передача электронных документов 80070 производится на рынка или ФСК должен передать в КО Заявку в виде макета 70070 адрес электронной почты (iasuku_crypto@rosenergo.com) повторно. после получения от КО официального ответа на письмо о подготовке базы данных для приема Акта в электронном 3.4. Полученный КО Алгоритм в электроном виде обрабатывается в ПАК сбора данных КУ, где проводится его анализ. виде. 3.5. Полученный в КО документ с Актом обрабатывается в ПАК 3.5. После обработки файла Участнику оптового рынка или ФСК автоматически отправляется ответная квитанция о правильно сбора данных КУ, где проводится анализ его содержимого на сформированном электронном документе с точки зрения предмет наличия ошибок и некорректных данных и возможности машинного разбора информации (макет 80071). формируется документ 80071, содержащий информацию о статусе приема Акта, а также список ошибок и 3.6. В случае формирования файла в соответствии с требованиями предупреждений, обнаруженных при анализе полученного настоящего приложения в ПАК сбора данных КУ формируется документа. Сформированный таким образом документ в Алгоритм расчета учетного показателя на основе переданного макета XML-формате отправляется по электронной почте в качестве 80070. ответа Участнику с использованием ЭЦП. 3.7. Если макет 80070 сформирован неверно с точки зрения возможности машинного разбора информации, то в ответной квитанции Участнику оптового рынка и(или) ФСК направляется список ошибок, обнаруженных при анализе полученного документа. Для формирования Алгоритма расчета учетного показателя Участник оптового рынка или ФСК должен исправить ошибки, указанные в макете 80071, и повторить передачу проекта Алгоритма в электронном виде в КО. 3.6. При отсутствии подтверждения в течение 120 минут после отправки сообщения, Участник оптового рынка должен повторить передачу Акта в КО. Если при повторной передаче данных не получено подтверждение, то уполномоченное лицо Участника оптового рынка, ответственное за передачу Акта, должно связаться с представителем КО, ответственным за прием информации с целью локализации и устранения проблемы. 3.8. Макет 80071 формируется в виде документа XML, подписывается ЭЦП КО и отправляется по электронной почте на адрес Участника 3.7. Время передачи Акта в КО устанавливается по факту оптового рынка или ФСК, с которого был получен макет 80070. получения КО почтового сообщения с электронным документом и указывается в ответном документе. Если 3.9. При отсутствии ответа КО в течение 120 минут после отправки присланный документ содержит информацию о том, что Акт проекта Алгоритма в электронном виде, Участник оптового рынка не принят КО, то участник или ФСК должен исправить или ФСК должен повторить передачу электронного документа в КО. ошибки и повторить передачу Акта в КО. Если с момента повторной передачи проекта Алгоритма не получено 3.8. Блокирование от изменений принятого Акта (документ 80070 ответа КО в течение 120 минут, то уполномоченное лицо не содержал структурные ошибки или ошибки, связанные со организации, ответственное за передачу проекта Алгоритма, должно сроками передачи данных) происходит автоматически через 2 связаться с представителем КО, ответственным за прием рабочих дня, в течение которых допускается передача новых информации с целью локализации и устранения проблемы. (измененных) документов 80070 с аналогичными кодами ГТП и номером версии Акта. 3.9. При получении в ПАК сбора данных КУ нового (измененного) документа 80070 с большим номером или датой создания, но с аналогичными кодами ГТП и номером версии Акта и не имеющего ошибок формата, вся информация, переданная предыдущим документом удаляется и заносится из документа, имеющего более старший номер или дату создания. Замещение не происходит только в том случае, когда более поздний документ имеет ошибки формата. 3.10. До окончания текущих суток, в которые был сформирован алгоритм расчета учетного показателя в ПАК сбора данных КУ на основе макета 80070, возможна повторная передача документа в КО. В этом случае при получении в ПАК сбора данных КУ измененного проекта Алгоритма с большим номером или датой создания, но с аналогичными кодами ГТП и номером версии проекта Алгоритма, и не имеющего ошибок формата (макет 80070 не содержал структурные ошибки или ошибки, связанные со сроками передачи данных) и криптографии, вся информация, переданная предыдущим документом, в полном объеме замещается информацией из документа, имеющего более старший номер или дату создания. Замещение не происходит только в том случае, когда более поздний документ имеет ошибки формата. 3.11 После формирования алгоритма расчета учетного показателя в ПАК сбора данных КУ на основе макета 80070 проводится техническая экспертиза переданной информации. 3.12 По результатам технической экспертизы Участнику оптового рынка или ФСК отправляется ответная квитанция с ее результатами (макет 80072). 3.13 В случае если результаты технической экспертизы положительные, Участнику оптового рынка или ФСК на адрес электронной почты, с которой получен макет 80070, высылается макет 80010 (Приложение 5.3 к настоящему регламенту), содержащий результаты расчета величины учетного показателя. Макет 80010 высылается только при наличии результатов измерения по точкам измерения, переданных в ПАК сбора данных КУ в макете 80020 и(или) 80040, за период, указанный в Положении о порядке получения статуса субъекта оптового рынка и ведения реестра субъектов оптового рынка. 3.14 В случае если результаты технической экспертизы отрицательные, Участник оптового рынка или ФСК для повторной процедуры должен исправить ошибки, указанные в ответной квитанции, и отправить в КО макет 80070 с исправленными замечаниями. В этом случае процедуры, описанные в настоящем Приложении, выполняются повторно. Приложени е 5.1, п. 4 4. Описание формата передачи Акта согласования 4. Описание форматов алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП потребления 4.1. Описание формата Алгоритма (макет 80070) (величины произведенной электроэнергии в ГТП … генерации). (Документ 80070) 4.1. Описание формата документа (тип 80070) … 4.3. Описание формата ответного сообщения (тип 80071) 4.3. Описание ответной квитанции (макет 80071) Корневым элементом электронного документа является <message>. В документе допускается наличие только одного элемента <message>. Потомками элемента <message> являются элементы <file>, <reply>, <fileareas>, <currentstate>. Корневым элементом электронного документа является Атрибут class элемента <message> является обязательным и <message>. В документе допускается наличие только одного содержит данные о типе документа. Значение атрибута class должно быть элемента <message>. Потомками элемента <message> являются равно 80071. элементы <file>, <reply>, <fileareas>, <currentstate>. Атрибут version элемента <message> является обязательным и Атрибут class элемента <message> является обязательным и содержит данные о версии документа. Текущее значение версии равно 1. содержит данные о типе документа. Значение атрибута class должно быть равно 80071. Атрибут id элемента <message> является необязательным и Атрибут version элемента <message> является обязательным содержит уникальный цифровой код сообщения. и содержит данные о версии документа. Текущее значение версии Атрибут datetime элемента <message> является необязательным и равно 1. содержит дату создания ответного сообщения в виде ГГГГММДДччммсс, Атрибут id элемента <message> является необязательным и где ГГГГ − год, ММ − месяц, ДД − день, чч − часы в 24-часовом формате, содержит уникальный цифровой код сообщения. мм − минуты, сс − секунды. Атрибут datetime элемента <message> является Элемент <file> является потомком корневого элемента <message> и необязательным и содержит дату создания ответного сообщения в содержит информацию о вложенном в электронное сообщение файле виде ГГГГММДДччммсс, где ГГГГ − год, ММ − месяц, ДД − день, XML. В документе допускается наличие только одного элемента <file>. чч − часы в 24-часовом формате, мм − минуты, сс − секунды. Потомками элемента <file> являются элементы <fromaddr>, <name>, <sender>, <day>, <id>, <received>. Элемент <file> является потомком корневого элемента <message> и содержит информацию о вложенном в электронное Элемент <fromaddr> является необязательным потомком элемента сообщение файле XML. В документе допускается наличие только <file> и содержит адрес электронной почты, с которой пришло письмо, одного элемента <file>. Потомками элемента <file> являются содержащее входящий макет 80070, на который было сформировано элементы <fromaddr>, <name>, <sender>, <day>, <id>, данное ответное сообщение. <received>. Элемент <name> является обязательным потомком элемента <file> Элемент <fromaddr> является необязательным потомком и содержит название макета 80070, на который было сформировано элемента <file> и содержит адрес электронной почты, с которой данное ответное сообщение. пришло письмо, содержащее входящий файл формата 80070, на Элемент <sender> является необязательным потомком элемента который было сформировано данное ответное сообщение. <file> и содержит ИНН организации-поставщика информации, которая Элемент <name> является обязательным потомком сформировала входящий файл. элемента <file> и содержит название файла XML формата 80070, Элемент <day> является необязательным потомком элемента <file> на который было сформировано данное ответное сообщение. и содержит сутки, на которые был сформирован входящий файл в Элемент <sender> является необязательным потомком формате ГГГГММДД, где ГГГГ − год, ММ − месяц, ДД −день. элемента <file> и содержит ИНН организации-поставщика Элемент <id> является обязательным потомком элемента <file> и информации, которая сформировала входящий файл. содержит код входящего XML-файла в ПАК сбора данных КУ. Элемент <day> является необязательным потомком Элемент <received> является обязательным потомком элемента элемента <file> и содержит сутки, на которые был сформирован <file> и содержит дату получения входящего файла системой ПАК сбора входящий файл в формате ГГГГММДД, где ГГГГ − год, ММ − данных КУ в виде ГГГГММДДччммсс, где ГГГГ − год, ММ − месяц, ДД − месяц, ДД −день. день, чч − часы в 24-часовом формате, мм − минуты, сс − секунды. Элемент <id> является обязательным потомком элемента Элемент <reply> является обязательным потомком корневого <file> и содержит код входящего XML-файла в базе данных элемента <message> и содержит информацию по ошибкам файла и ИАСУ КУ. статусу его обработки. В документе допускается наличие только одного Элемент <received> является обязательным потомком элемента <reply>. Потомками элемента <reply> являются элементы элемента <file> и содержит дату получения входящего файла <error>. системой ИАСУ КУ в виде ГГГГММДДччммсс, где ГГГГ − год, ММ − месяц, ДД − день, чч − часы в 24-часовом формате, мм − Атрибут filestatus элемента <reply> является обязательным и минуты, сс − секунды. содержит цифровой код статуса обработки файла. Может принимать следующие значения: 0 ― ошибок при обработке не обнаружено, данные Элемент <reply> является обязательным потомком приняты; 1 ― ошибок при обработке не обнаружено, некоторые данные корневого элемента <message> и содержит информацию по имели статус некоммерческой информации; 2 и другие значения кроме 0 ошибкам файла и статусу его обработки. В документе допускается и 1 ― файл содержал ошибки, весь файл либо некоторые данные не были наличие только одного элемента <reply>. Потомками элемента приняты. <reply> являются элементы <error>. Атрибут desc элемента <reply> является необязательным и Атрибут filestatus элемента <reply> является обязательным и содержит короткое текстовое описание кода статуса обработки из содержит цифровой код статуса обработки файла. Может атрибута filestatus. принимать следующие значения: 0 ― ошибок при обработке не обнаружено, данные приняты; 1 ― ошибок при обработке не Элемент <error> является необязательным потомком элемента обнаружено, некоторые данные имели статус некоммерческой <reply> и содержит текст ошибки, найденной во входящем файле. В информации; 2 и другие значения кроме 0 и 1 ― файл содержал документе допускается наличие нескольких элементов <error>. ошибки, весь файл либо некоторые данные не были приняты. 4.4. Описание ответной квитанции (макета 80072) Атрибут desc элемента <reply> является необязательным и 4.3.1. Корневым элементом электронного документа является содержит короткое текстовое описание кода статуса обработки из <message>. В документе допускается наличие только одного атрибута filestatus. элемента <message>. Потомками элемента <message> Элемент <error> является необязательным потомком являются элементы <file>, <reply>. элемента <reply> и содержит текст ошибки, найденной во входящем файле. В документе допускается наличие нескольких 4.3.2. Атрибут class элемента <message> является обязательным и элементов <error>. содержит данные о типе документа. Значение атрибута class должно быть равно 80072. Атрибут areacode элемента <error> является необязательным и содержит цифровой код соответствующего 4.3.3. Атрибут version элемента <message> является обязательным элемента <area> во входящем XML-файле для которого была и содержит данные о версии документа. Текущее значение обнаружена данная ошибка. версии равно 2. Атрибут type элемента <error> является необязательным и 4.3.4. Атрибут id элемента <message> является необязательным и содержит цифровой код типа ошибки. содержит уникальный цифровой код квитанции. Атрибут subtype элемента <error> является необязательным и содержит цифровой код подтипа ошибки. Элемент <fileareas> является необязательным потомком корневого элемента <message> и содержит информацию по статусам обработки элементов <area> во входящем XML-файле. В документе допускается наличие не более одного элемента <fileareas>. Потомками элемента <fileareas> являются элементы <area>. 4.3.5. Атрибут datetime элемента <message> является необязательным и содержит дату создания ответной квитанции в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды. 4.3.6. Элемент <file> является потомком корневого элемента Элемент <area> является необязательным потомком элемента <fileareas> и содержит информацию по статусу обработки определенного элемента <area> в соответствующем входящем файле. Атрибут code элемента <area> является обязательным и содержит код группы <area> в исходном файле. Атрибут status элемента <area> является обязательным и содержит статус обработки соответствующего элемента <area> во входящем файле. Может принимать следующие значения: 0 − ошибок при обработке не обнаружено, данные приняты; 1 − ошибок при обработке не обнаружено, некоторые данные имели статус некоммерческой информации; 2 и другие значения кроме 0 и 1 − группа <area> содержала ошибки и данные из нее приняты не были. Атрибут desc элемента <area> является необязательным и содержит короткое текстовое описание статуса ошибки в атрибуте status. Элемент <currentstate> является потомком корневого элемента <message> и содержит информацию по текущему состоянию статусов групп <area> для данного поставщика информации. В документе допускается наличие не более одного элемента <currentstate>. Потомками элемента <currentstate> являются элементы <area>. Атрибут forsender элемента <currentstate> является обязательным и содержит ИНН организации-поставщика информации для которой приводятся данные. Атрибут fordate элемента <currentstate> является обязательным и содержит дату, на которую приводятся данные в формате ГГГГММДД, где ГГГГ − год, ММ − месяц, ДД − день. <message> и содержит информацию о вложенном в электронное сообщение файле XML. В документе допускается наличие только одного элемента <file>. Потомками элемента <file> являются элементы <fromaddr>, <name>, <sender>, <day>, <id>, <received>. 4.3.7. Элемент <fromaddr> является необязательным потомком элемента <file> и содержит адрес электронной почты, с которой пришло письмо, содержащее входящий макет 80070, и на который была сформирована данная ответная квитанция. 4.3.8. Элемент <name> является обязательным потомком элемента <file> и содержит название макета 80070, на который была сформирована данная ответная квитанция. 4.3.9. Элемент <sender> является необязательным потомком элемента <file> и содержит ИНН организации - поставщика информации, которая сформировала входящий файл. 4.3.10. Элемент <day> является необязательным потомком элемента <file> и содержит сутки, на которые был сформирован входящий файл в формате ГГГГММДД, где ГГГГ – год, ММ – месяц, ДД – день. 4.3.11. Элемент <id> является обязательным потомком элемента <file> и содержит код входящего документа XML в ПАК сбора данных КУ. Атрибут desc элемента <currentstate> является необязательным и содержит короткое текстовое описание элемента <currentstate>. 4.3.12. Элемент <received> является обязательным потомком элемента <file> и содержит дату получения входящего файла системой ПАК сбора данных КУ в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды. Элемент <area> является необязательным потомком элемента <currentstate> и содержит информацию по статусу обработки наилучшего элемента <area> для поставщика 4.3.13. Элемент <reply> является обязательным потомком корневого элемента <message> и содержит информацию об ошибках файла и результатах его обработки. В документе информации, указанного в атрибуте forsender для суток, указанных в атрибуте fordate. допускается наличие только одного элемента <reply>. Потомком элемента <reply> является элемент <comment>. Атрибут code элемента <area> является обязательным и содержит код группы <area> в исходном файле. 4.3.14. Атрибут desc элемента <reply> содержит данные о результатах технической экспертизы проекта Алгоритма: « Положительная экспертиза» или «Отрицательная экспертиза». Атрибут status элемента <area> является необязательным и содержит статус обработки соответствующего элемента <area> во входящем файле. Может принимать следующие значения: 0 − ошибок при обработке не обнаружено, данные приняты; 1 − ошибок при обработке не обнаружено, некоторые данные имели статус некоммерческой информации; 2 и другие значения кроме 0 и 1 − группа <area> содержала ошибки и данные из нее приняты не были. Атрибут desc элемента <area> является необязательным и содержит короткое текстовое описание статуса ошибки в атрибуте status. Атрибут fromfile элемента <area> является необязательным и содержит название файла, данные из которого получили наилучший статус по этой группе <area> и были занесены в базу данных ИАСУ КУ. 4.3.15. Элемент <comment> является необязательным в случае положительного результата технической экспертизы, либо содержит дополнительную информацию о причинах отрицательного результата технической экспертизы. Приложение 5.2 Приложение 5.2 (на бланке Заявителя) Начальнику Департамента сбора данных КУ ЭЭ ОАО «АТС» _________________________________ (Ф.И.О.) О настройке БД для приема формата 80070 Заявка о подготовке базы данных КУ для приема Акта согласования алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП потребления (величины произведенной электроэнергии в ГТП генерации ) в электронном виде (формат 80070) В связи с _____________________________________________________ _______________ прошу (причина запроса) подготовить БД ОАО «АТС» для приема Акта согласования алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП P……. – P………. (величины произведенной электроэнергии в ГТП генерации G………..) _____________________________________________________ ________________________ (наименование Участника ОРЭМ1 (Участника ОРЭМ2)) Удалить Приложение 5.2 с последующим изменением нумерации в электронном виде и подтвердить номер версии Акта согласования алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП потребления (величины произведенной электроэнергии в ГТП генерации)____________________________________________ __________ (№ версии Акта) Заключение о результатах проведения ОАО «АТС» технической экспертизы представленных для регистрации ГТП документов зарегистрировано за номером ______________ (№ документа) от ____________ (дата). _____________________________ __________________________ (должность руководителя, М.П.) (Ф.И.О.) Исполнитель ФИО Тел.: (подпись) Приложение 5.3, п. 1 Приложение 5.3 ФОРМАТ И РЕГЛАМЕНТ ПЕРЕДАЧИ В ОАО «АТС» ЭЛЕКТРОННОГО ДОКУМЕНТА «ЗАЯВКА О ПОДГОТОВКЕ БАЗЫ ДАННЫХ КО ДЛЯ ПРИЕМА АКТА СОГЛАСОВАНИЯ АЛГОРИТМА РАСЧЕТА ВЕЛИЧИНЫ САЛЬДО ПЕРЕТОКОВ ЭЛЕКТРОЭНЕРГИИ В СЕЧЕНИИ МЕЖДУ ГТП ПОТРЕБЛЕНИЯ (ВЕЛИЧИНЫ ПРОИЗВЕДЕННОЙ ЭЛЕКТРОЭНЕРГИИ В ГТП ГЕНЕРАЦИИ)». ДОКУМЕНТ 70070 Приложение 5.2 ОПИСАНИЕ ФОРМАТА И РЕГЛАМЕНТА ПЕРЕДАЧИ КО ЭЛЕКТРОННОГО ДОКУМЕНТА «ЗАЯВКА О ПОДГОТОВКЕ БАЗЫ ДАННЫХ КО ДЛЯ ПРИЕМА АКТА СОГЛАСОВАНИЯ АЛГОРИТМА РАСЧЕТА ВЕЛИЧИНЫ САЛЬДО ПЕРЕТОКОВ ЭЛЕКТРОЭНЕРГИИ В СЕЧЕНИИ МЕЖДУ ГТП ПОТРЕБЛЕНИЯ (ВЕЛИЧИНЫ ПРОИЗВЕДЕННОЙ ЭЛЕКТРОЭНЕРГИИ В ГТП ГЕНЕРАЦИИ)». 1. Предмет действия 1. Предмет и сфера действия Порядка Предмет Настоящий Порядок устанавливает порядок и формат предоставления в КО Участниками оптового рынка и ФСК электронного документа, содержащего Заявку о подготовке базы данных КО для приема Акта согласования алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП потребления (величины произведенной электроэнергии в ГТП генерации) (далее – Заявка) Настоящее Приложение описывает формат и регламент предоставления в КО Участниками оптового рынка или ФСК электронного документа, содержащего Заявку о подготовке базы данных КО для приема проекта Алгоритма в электронном виде (далее – Заявка). Сфера действия Положения настоящего Порядка распространяются: 1) Участников оптового рынка электроэнергии; 2) ФСК; 3) КО. Приложение 5.3, п. 2 2. Общие положения 2. Общие положения 2.1. Для передачи Заявки используется тип документа 70070. 2.1 Заявка оформляется в виде макета 70070 с целью подготовки ПАК сбора данный КУ к приему макета 80070 (проект Алгоритма в электронном виде, приложение 5.1 к настоящему Регламенту). 2.2. Передача Заявки в электронном виде осуществляется с использованием электронно-цифровой подписи, полученной в соответствии с Соглашением о применении 2.2 Заявка должна быть оформлена в строгом соответствии с электронно-цифровой подписи в торговой системе требованиями настоящего Приложения и подписана ЭЦП Участника оптового рынка. оптового рынка или ФСК, полученной в соответствии с Соглашением о применении электронно-цифровой подписи в торговой системе оптового рынка (Приложение Д 7 к Договору о присоединении к торговой системе оптового 2.3. При передаче электронного документа используется рынка). расширяемый язык разметки (XML) в соответствии со спецификацией Extensible Markup Language (XML) 1.0. 2.3 В макете 70070 Участник оптового рынка или ФСК должен заявить информацию, относящуюся только к одному проекту Алгоритма для 2.4. При декларации кодировки, являющейся частью декларации передачи одного электронного документа 80070. XML, используются названия и псевдонимы русскоязычных наборов символов, зарегистрированных в Internet Assigned Numbers Authority. Для данного электронного документа 2.4 Заявка может быть направлена в КО не ранее окончания процедуры используется кодировка “windows-1251”. кодирования и при условии наличия акта о согласовании ГТП субъекта ОРЭМ и отнесении их к узлам расчетной модели. При 2.5. Каждый электронный документ должен содержать передаче макета 70070 до момента окончания процедуры информацию, относящуюся к одному Акту согласования кодирования данный файл не будет принят КО и Участник оптового алгоритма расчета величины сальдо перетоков рынка или ФСК получит ответную квитанцию с уведомлением об электроэнергии в сечении между ГТП потребления ошибке. (величины произведенной электроэнергии в ГТП генерации). 2.5 Номер версии проекта Алгоритма в Заявке должен быть на единицу больше чем номер версии алгоритма расчета величины учетного показателя с аналогичными кодами ГТП, указанным в Заявке, находящегося в ПАК сбора данных КУ КО. Если в ПАК сбора данных КУ КО отсутствует алгоритм расчета величины учетного показателя с кодами ГТП, указанными в Заявке, то в Заявке указывается номер версии равный 1 (единице). 2.6 Запрещается передавать Заявку о подготовке базы данных КО для приема проекта Алгоритма в электронном виде, если по алгоритму расчета величины учетного показателя, имеющемуся в ПАК сбора данных КУ КО, с теми же кодами ГТП не согласован макет 80010 (приложение 5.3 к настоящему Регламенту). В случае необходимости приостановки работ по данному проекту Алгоритма необходимо направить письмо на бумажном носителе в КО с просьбой о подготовке базы данных КО для приема макета 80070 с новой информацией и указать причину, по которой Расчет (Приложение 5.3 к настоящему Регламенту) по ранее присланному макету 80070 не может быть подтвержден. 2.7 При передаче электронного документа используется расширяемый язык разметки (XML) в соответствии со спецификацией Extensible Markup Language (XML) 1.0. Приложение 5.3, п. 3 3. Регламент передачи 2.8 При декларации кодировки, являющейся частью декларации XML, используются названия и псевдонимы русскоязычных наборов символов, зарегистрированных в Internet Assigned Numbers Authority. Для данного электронного документа используется кодировка “windows-1251”. 3. Регламент передачи и обработки 3.1. Передача электронных документов 70070 производится на 3.1 Передача макета 70070 производится на адрес электронной почты адрес электронной почты iasuku_crypto@rosenergo.com. iasuku_crypto@rosenergo.com. 3.2. Полученный в КО документ с Заявкой обрабатывается в 3.2 Полученная в КО Заявка обрабатывается в ПАК сбора данных КУ, где ПАК сбора данных КУ, где проводится анализ его проводится ее машинный анализ. содержимого на предмет наличия ошибок в кодах ГТП или 3.3 В случае формирования файла в соответствии с требованиями версии расчета и формируется документ 70071, настоящего приложения Участнику оптового рынка или ФСК содержащий информацию о статусе приема Заявки, а также автоматически отправляется ответная квитанция о правильно список ошибок и предупреждений, обнаруженных при сформированном электронном документе с точки зрения машинного анализе полученного документа. Сформированный таким анализа (макет 70071). В этом случае Заявка доступна для образом документ в XML-формате отправляется по рассмотрения КО. электронной почте в качестве ответа Участнику с 3.4 Если макет 70070 сформирован неверно с точки зрения машинного использованием ЭЦП. анализа, то в ответной квитанции Участнику оптового рынка или 3.3. КО не принимает электронный документ в случае ФСК направляется список ошибок, обнаруженных при анализе совпадения кодов ГТП и версии расчета Акта согласования полученного документа. алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП потребления 3.5. Макет 70071 формируется в виде документа XML, подписывается ЭЦП и отправляется по электронной почте на адрес Участника (величины произведенной электроэнергии в ГТП оптового рынка или ФСК, с которого был получен макет 70070. генерации) с уже существующим Актом в ПАК сбора данных КУ. 3.6. При отсутствии ответа КО в течение 120 минут после отправки 3.3. При отсутствии подтверждения в течение 120 минут после отправки сообщения, Участник оптового рынка должен повторить передачу Заявки в КО. Если при повторной передаче данных не получено подтверждение, то уполномоченное лицо Участника оптового рынка, ответственное за передачу Заявки, должно связаться с представителем КО, ответственным за прием информации с целью локализации и устранения проблемы. Заявки, Участник оптового рынка и ФСК должен повторить передачу Заявки в КО. Если с момента повторной передачи Заявки не получено ответа КО в течение 120 минут, то уполномоченное лицо организации, ответственное за передачу Заявки, должно связаться с представителем КО, ответственным за прием информации с целью локализации и устранения проблемы. 3.4. Время передачи Заявки в КО устанавливается по факту 3.7 После принятия данных (макет 70070 не содержал структурные и криптографические ошибки) в ПАК сбора данных КУ на основе получения КО почтового сообщения с электронным макета 70070 КО проводит рассмотрение данной Заявки. документом и указывается в ответном документе. Если присланный документ содержит информацию о том, что 3.8 По результатам рассмотрения Заявки КО Участнику оптового рынка Заявка не принята КО, то участник должен исправить или ФСК отправляется ответная квитанция (макет 70072) на адрес ошибки и повторить передачу Заявки в КО. электронной почты, с которой получен макет 70070. 3.9 Если Заявка была положительно рассмотрена КО (в Заявке указана информация, не содержащая ошибок и противоречий), Участник оптового рынка или ФСК может передать макет 80070 (проект Алгоритма в электронном виде) в ПАК сбора данных КУ не позднее чем по истечению 30 (тридцати) календарных дней. 3.10 В случае если КО отклонил Заявку, Участник оптового рынка или ФСК для повторной процедуры должен исправить ошибки, указанные в ответной квитанции, и отправить в КО макет 70070 с исправленными замечаниями. В этом случае процедуры, описанные в настоящем приложении, выполняются повторно. Приложение 5.3, п. 3 4. Описание формата передачи Заявки о подготовке базы данных КО для приема Акта согласования алгоритма расчета величины сальдо перетоков электроэнергии в сечении между ГТП потребления (величины произведенной электроэнергии в ГТП генерации) (Документ 70070) 4. Описание форматов Макет 70070 4.1. Имя файла Имя файла, содержащего электронный документ, должно составляться в формате “<тип документа>_<ИНН>_<дата>”, где: 4) тип документа – номер, присвоенный КО данному типу документа; 4.1. Описание формата документа (тип 70070) 5) ИНН – ИНН организации, формирующей заявку на получение кодов, длина inn – 10 символов; Имя файла, содержащего электронный документ, должно 6) дата – дата формирования заявки в формате “ГГГГММДДччммсс”, составляться в формате “<тип документа>_<ИНН>_<дата>”, где ГГГГ – год, ММ – порядковый номер месяца, ДД – день, чч – час, где: мм – минуты, сс – секунды. Длина поля <дата> – 14 знаков. 1) тип документа – номер, присвоенный КО данному типу документа; 2) ИНН – ИНН организации, формирующей заявку на получение кодов, длина inn – 10 символов; 3) дата – дата формирования заявки в формате “ГГГГММДДччммсс”, где ГГГГ – год, ММ – порядковый номер месяца, ДД – день, чч – час, мм – минуты, сс – секунды. Длина поля <дата> – 14 знаков. Расширение файла ― xml. 4.2. Описание структуры документа (тип 70070) ... 4.2.8 Элемент <peretok> является потомком корневого элемента <message>. В документе допускается наличие только одного элемента <peretok> или только одного элемента <deliverygroup>. Элемент <peretok> содержит сведения о сальдо перетоков между двумя группами точек поставки. Атрибутами элемента <peretok> являются code-from, сode-to, algorithmversion, name, reason. Потомком элемента <peretok> является элемент <techexpertiza>. содержимым атрибута name является наименование данного сальдо перетоков между двумя группами точек поставки. Длина наименования до 250 символов; атрибут code-from содержит код ГТП, присвоенный КО группе точек поставки; атрибут code-to содержит код ГТП, присвоенный КО группе точек поставки; атрибут algorithmversion содержит номер версии алгоритма; атрибут reason содержит сведения о причине запроса на подготовку базы данных КО для приема Акта в электронном виде и может принимать следующие значения: 1 – новая ГТП; 2 – изменение схемы измерения/состава ГТП; 3 – изменение алгоритма расчета учетного показателя без изменения состава ТИ и ТП (изменение потерь в Расширение файла ― xml. 4.2. Описание структуры документа (формат 70070) … 4.2.8 Элемент <peretok> является потомком корневого элемента <message>. В документе допускается наличие только одного элемента <peretok> или только одного элемента <deliverygroup>. Элемент <peretok> содержит сведения о сальдо перетоков между двумя группами точек поставки. Атрибутами элемента <peretok> являются code-from, сode-to, algorithmversion, name, reason. Потомком элемента <peretok> является элемент <techexpertiza>. содержимым атрибута name является наименование сечения КУ. Длина наименования до 250 символов. Следует указывать форму предоставления наименования сечения коммерческого учета следующего вида: V.__{номер версии Алгоритма, совпадает с algorithmversion в настоящем пункте} Переток ____{Наименование Заявителя (наименование объекта)} – ____{Наименование Смежника Заявителя} _______ (коды смежных ГТП потребления); атрибут code-from содержит код ГТП потребления Заявителя, присвоенный КО; атрибут code-to содержит код ГТП потребления смежного Участника оптового рынка или ФСК, присвоенный КО; атрибут algorithmversion содержит номер версии Алгоритма; атрибут reason содержит сведения о причине запроса на подготовку базы данных КО для приема Акта в электронном виде и может принимать следующие значения: 1 – новая ГТП; 2 – изменение схемы измерения/состава ГТП; 3 – изменение алгоритма расчета учетного показателя без изменения состава ТИ и ТП (изменение потерь в ТП, перераспределение ТП, ввод дополнительных условий и т.д.). 4.2.9 Элемент <deliverygroup> является потомком корневого элемента <message>. В документе допускается наличие только одного элемента <deliverygroup> или только одного элемента <peretok>. Элемент <deliverygroup> содержит сведения о группе точек поставки генерации. Атрибутами элемента <deliverygroup> являются code, algorithmversion, ТП, перераспределение ТП, ввод дополнительных name. Потомком элемента <deliverygroup> является элемент условий и т.д.). <techexpertiza>. 4.2.9 Элемент <deliverygroup> является потомком корневого содержимым атрибута name является наименование данной ГТП элемента <message>. В документе допускается наличие только генерации. Длина наименования до 250 символов. Следует одного элемента <deliverygroup> или только одного элемента указывать форму предоставления наименования ГТП генерации <peretok>. Элемент <deliverygroup> содержит сведения о следующего вида: V.__{номер версии Алгоритма, совпадает с группе точек поставки генерации. Атрибутами элемента algorithmversion в настоящем пункте} Генерация _____{Наименование <deliverygroup> являются code, algorithmversion, name. Заявителя (наименование станции)} ______(код ГТП генерации); Потомком элемента <deliverygroup> является элемент атрибут code содержит уникальный код ГТП генерации, <techexpertiza>. присвоенный КО; содержимым атрибута name является наименование атрибут algorithmversion содержит номер версии алгоритма; данной группы точек поставки. Длина наименования до атрибут reason содержит сведения о причине запроса на 250 символов; подготовку базы данных КО для приема Акта в электронном виде атрибут code содержит уникальный код, присвоенный и может принимать следующие значения: КО группе точек поставки; 1 – новая ГТП; 2 – изменение схемы измерения/состава ГТП; атрибут algorithmversion содержит номер версии 3 – изменение алгоритма расчета учетного показателя без алгоритма; изменения состава ТИ и ТП (изменение потерь в ТП, атрибут reason содержит сведения о причине запроса на перераспределение ТП, ввод дополнительных условий и т.д.). подготовку базы данных КО для приема Акта в 4.2.10 При необходимости после элемента <reason> может быть электронном виде и может принимать следующие размещен элемент-комментарий. Комментарии размещаются значения: внутри специального тега, начинающегося с символов <!-- и 1 – новая ГТП; заканчивающегося символами -->. Два знака дефис (--) внутри 2 – изменение схемы измерения/состава ГТП; комментария присутствовать не могут. 3 – изменение алгоритма расчета учетного показателя без изменения состава ТИ и ТП (изменение потерь в 4.2.11 Элемент <techexpertiza> содержит ссылку на номер и дату ТП, перераспределение ТП, ввод дополнительных согласования Заключения технической экспертизы КО (далее - ТЭ) или условий и т.д.). ПСИ. В документе допускается наличие только одного элемента 4.2.10 Элемент <techexpertiza> содержит информацию из <techexpertiza>. Атрибутами элемента <techexpertiza> являются number, Заключения о результатах проведения КО технической date. экспертизы представленных для регистрации ГТП документов содержимым атрибута number является номер ТЭ или ПСИ, (далее - Заключение). В документе допускается наличие только присвоенный КО. При этом указывается номер и дата того одного элемента <techexpertiza>. Атрибутами элемента документа, который подтверждает состав ТП в проекте Алгоритма. <techexpertiza> являются number, date. В начале номера указывается сокращенное наименование документа (ТЭ, ПСИ) и далее следует номер документа без содержимым атрибута number является номер пробела; Заключения, присвоенный КО; атрибут date содержит дату регистрации соответствующего атрибут date содержит дату Заключения, присвоенную документа в формате “ГГГГММДДччммсс”, где ГГГГ – год, ММ КО. – порядковый номер месяца, ДД – день. Макет 70071 4.3 Описание структуры 4.3.1. Корневым элементом электронного документа является <message>. В документе допускается наличие только одного элемента <message>. Потомками элемента <message> являются элементы <file>, <reply>. 4.3.2. Атрибут class элемента <message> является обязательным и содержит данные о типе документа. Значение атрибута class должно быть равно 70071. 4.3.3. Атрибут version элемента <message> является обязательным и содержит данные о версии документа. Текущее значение версии равно 2. 4.3.4. Атрибут id элемента <message> является необязательным и содержит уникальный цифровой код квитанции. 4.3.5. Атрибут datetime элемента <message> является необязательным и содержит дату создания ответной квитанции в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды. 4.3.6. Элемент <file> является потомком корневого элемента <message> и содержит информацию о вложенном в электронное сообщение файле XML. В документе допускается наличие только одного элемента <file>. Потомками элемента <file> являются элементы <fromaddr>, <name>, <sender>, <day>, <id>, <received>. 4.3.7. Элемент <fromaddr> является необязательным потомком элемента <file> и содержит адрес электронной почты, с которой пришло письмо, содержащее входящий макет 70070, и на который была сформирована данная ответная квитанция. 4.3.8. Элемент <name> является обязательным потомком элемента <file> и содержит название макета 70070, на который была сформирована данная ответная квитанция. 4.3.9. Элемент <sender> является необязательным потомком элемента <file> и содержит ИНН организации – поставщика информации, которая сформировала входящий файл. 4.3.10. Элемент <day> является необязательным потомком элемента <file> и содержит сутки, на которые был сформирован входящий файл в формате ГГГГММДД, где ГГГГ – год, ММ – месяц, ДД – день. 4.3.11. Элемент <id> является обязательным потомком элемента <file> и содержит код входящего XML-файла в ПАК сбора данных КУ. 4.3.12. Элемент <received> является обязательным потомком элемента <file> и содержит дату получения входящего файла системой ПАК сбора данных КУ в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды. 4.3.13. Элемент <reply> является обязательным потомком корневого элемента <message> и содержит информацию по ошибкам файла и статусу его обработки. В документе допускается наличие только одного элемента <reply>. Потомками элемента <reply> являются элементы <error> и <comment>. 4.3.14. Атрибут filestatus элемента <reply> является необязательным и содержит цифровой код статуса обработки файла. Может принимать следующие значения: 0 ― ошибок при обработке не обнаружено, данные приняты; 3 ― файл содержал ошибки, весь файл либо некоторые данные не были приняты. 4.3.15. Атрибут desc элемента <reply> является необязательным и содержит короткое текстовое описание кода статуса обработки из атрибута filestatus. 4.3.16. Элемент <error> является необязательным потомком элемента <reply> и содержит текст ошибки, найденной во входящем файле. 4.3.17. Атрибут type элемента <error> является необязательным и содержит цифровой код типа ошибки. 4.3.18. Атрибут subtype элемента <error> является необязательным и содержит цифровой код подтипа ошибки. Макет 70072 4.4 описание структуры 4.4.1. Корневым элементом электронного документа является <message>. В документе допускается наличие только одного элемента <message>. Потомками элемента <message> являются элементы <file>, <reply>. 4.4.2. Атрибут class элемента <message> является обязательным и содержит данные о типе документа. Значение атрибута class должно быть равно 70072. 4.4.3. Атрибут version элемента <message> является обязательным и содержит данные о версии документа. Текущее значение версии равно 2. 4.4.4. Атрибут id элемента <message> является необязательным и содержит уникальный цифровой код квитанции. 4.4.5. Атрибут datetime элемента <message> является необязательным и содержит дату создания ответной квитанции в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды. 4.4.6. Элемент <file> является потомком корневого элемента <message> и содержит информацию о вложенном в электронное сообщение файле XML. В документе допускается наличие только одного элемента <file>. Потомками элемента <file> являются элементы <fromaddr>, <name>, <sender>, <day>, <id>, <received>. 4.4.7. Элемент <fromaddr> является необязательным потомком элемента <file> и содержит адрес электронной почты, с которой пришло письмо, содержащее входящий макет 70070, и на который была сформирована данная ответная квитанция. 4.4.8. Элемент <name> является обязательным потомком элемента <file> и содержит название макета 70070, на который была сформирована данная ответная квитанция. 4.4.9. Элемент <sender> является необязательным потомком элемента <file> и содержит ИНН организации поставщика информации, которая сформировала входящий файл. 4.4.10. Элемент <day> является необязательным потомком элемента <file> и содержит сутки, на которые был сформирован входящий файл в формате ГГГГММДД, где ГГГГ – год, ММ – месяц, ДД – день. 4.4.11. Элемент <id> является обязательным потомком элемента <file> и содержит код входящего XML-файла в ПАК сбора данных КУ. 4.4.12. Элемент <received> является обязательным потомком элемента <file> и содержит дату получения входящего файла системой ПАК сбора данных КУ в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды. 4.4.13. Элемент <reply> является обязательным потомком корневого элемента <message> и содержит информацию по ошибкам файла и статусу его обработки. В документе допускается наличие только одного элемента <reply>. Потомком элемента <reply> является элемент <comment>. 4.4.14. Атрибут desc элемента <reply> содержит данные о результатах рассмотрения Заявки: «Заявка принята» или «Заявка отклонена». 4.4.15. Элемент <comment> является необязательным в случае положительного результата рассмотрения Заявки, либо содержит дополнительную информацию о причинах отрицательного результата рассмотрения Заявки. Приложение 5.3, п. 5 5. Примеры электронного документа 70070 5. Примеры макета 70070 5.1 Пример электронного входного документа 70070 для Акта 5.1 Пример макета 70070 для Акта согласования алгоритма расчета согласования алгоритма расчета величины сальдо перетоков величины сальдо перетоков электроэнергии в сечении между ГТП электроэнергии в сечении между ГТП потребления: потребления: <?xml version="1.0" encoding="windows-1251" standalone="no"?> <message class="70070" version="1" generationtime="20101014093344GMT+03"> <organization inn="1234567890" name="Некоторая организация"> </organization> <peretok code-from="PNEKGRES" code-to="PNEKITES" name="Переток" algorithmversion="1" reason="3"> <?xml version="1.0" encoding="windows-1251" standalone="no"?> <message class="70070" version="1" generationtime="20101014093344GMT+03"> <organization inn="1234567890" name="Некоторая организация"> </organization> <peretok code-from="PNEKGRES" code-to="PNEKITES" name=" V.1 Переток ОАО «Наименование Заявителя» - ООО «Наименование Смежника Заявителя» (PXXXXXXX-PYYYYYYY)" algorithmversion="1" reason="3"> <techexpertiza number="2787/10" date="20100806"> </techexpertiza> </peretok> </message> 5.2 Пример электронного входного документа 70070 для Акта согласования алгоритма расчета величины произведенной электроэнергии в ГТП генерации <?xml version="1.0" encoding="windows-1251" standalone="no"?> <message class="70070" version="1" generationtime="20101014093350GMT+03"> <organization inn="1234567890" name="Некоторая организация"> </organization> <deliverygroup code="GNEKGRES" name="Генерация" algorithmversion="4" reason="2"> <techexpertiza number="2770-10" date="20100912"> </techexpertiza> </deliverygroup > </message> <!--Текст, который дополнительно поясняет причину, по которой необходимо предоставить проект Алгоритма в КО. Заполнять не обязательно --> <techexpertiza number="ПСИ1-2787/10" date="20100806"> </techexpertiza> </peretok> </message> 5.2 Пример электронного входного документа 70070 для Акта согласования алгоритма расчета величины произведенной электроэнергии в ГТП генерации <?xml version="1.0" encoding="windows-1251" standalone="no"?> <message class="70070" version="1" generationtime="20101014093350GMT+03"> <organization inn="1234567890" name="Некоторая организация"> </organization> <deliverygroup code="GNEKGRES" name=" V.4 Генерация ОАО «Наименование Заявителя» (ТЭЦ1) (GXXXXXXX)" algorithmversion="4" reason="2"> <!--Текст, который дополнительно поясняет причину, по которой необходимо предоставить проект Алгоритма в КО. Заполнять не обязательно --> <techexpertiza number="ТЭ2770-10" date="20100912"> </techexpertiza> </deliverygroup > </message> Приложение 5.4, п. 1 Приложение 5.4 ФОРМАТ И РЕГЛАМЕНТ СОГЛАСОВАНИЯ ЭЛЕКТРОННОГО ДОКУМЕНТА «АВТОМАТИЗИРОВАННОЕ ПОДТВЕРЖДЕНИЕ РАСЧЕТОВ ВЕЛИЧИНЫ УЧЕТНОГО ПОКАЗАТЕЛЯ» ДОКУМЕНТ 80010 1. Предмет и сфера действия Порядка Приложение 5.3 ОПИСАНИЕ ФОРМАТА И РЕГЛАМЕНТА СОГЛАСОВАНИЯ ЭЛЕКТРОННОГО ДОКУМЕНТА «АВТОМАТИЗИРОВАННОЕ ПОДТВЕРЖДЕНИЕ РЕЗУЛЬТАТОВ РАСЧЕТОВ ВЕЛИЧИНЫ УЧЕТНОГО ПОКАЗАТЕЛЯ» 1. Предмет действия Предмет Настоящее Приложение описывает формат и регламент согласования КО и Участниками оптового рынка или ФСК электронного документа, Настоящее Приложение устанавливает формат и регламент содержащего результаты расчета величины учетного показателя (далее – согласования КО, Участниками оптового рынка и ФСК Расчет) электронного документа, содержащего Расчет величины учетного показателя (далее – Расчет) Сфера действия Положения настоящего Порядка распространяются: 1) на Участников оптового рынка электроэнергии; 2) на ФСК; 3) на КО. Приложение 5.4, п. 2 2. Общие положения 2. Общие положения 2.1. Для передачи Расчета используется тип документа 80010. 2.1 Расчет оформляется КО в строгом соответствии с требованиями настоящего Приложения, а также Требованиями к проведению испытаний для определения соответствия автоматизированных информационноизмерительных систем коммерческого учета техническим требованиям оптового рынка электрической энергии (мощности) и присвоения коэффициентов класса АИИС (Приложение № 11.5 к Положению о порядке получения статуса субъекта оптового рынка и ведения реестра субъектов оптового рынка) и подписывается ЭЦП КО. 2.2. Передача Расчета в электронном виде осуществляется с использованием электронно-цифровой подписи, полученной в соответствии с Соглашением о применении электронно-цифровой подписи в торговой системе оптового рынка. 2.3. При передаче электронного документа используется расширяемый язык разметки (XML) в соответствии со 2.2 Расчет оформляется в виде макета 80010 с целью согласования и подтверждения Участником оптового рынка или ФСК, что спецификацией Extensible Markup Language (XML) 1.0. результаты расчета величины учетного показателя за указанный в документе период рассчитаны верно и являются достоверной информацией, полученной на основе проекта Алгоритма и макетов 80020 и(или) 80040, переданных Участником оптового рынка или ФСК в КО. 2.4. При декларации кодировки, являющейся частью декларации XML, используются названия и псевдонимы русскоязычных наборов символов, зарегистрированных в Internet Assigned Numbers Authority. Для данного электронного документа 2.3 Расчет направляется Участнику оптового рынка или ФСК не ранее используется кодировка “windows-1251”. получения положительной технической экспертизы на проект 2.5. Каждый электронный документ должен содержать Алгоритма, переданного в КО в виде макета 80070. информацию, относящуюся к одному Акту согласования алгоритма расчета величины сальдо перетоков 2.4 Участник оптового рынка или ФСК в срок не более 10 (десяти) электроэнергии в сечении между ГТП потребления рабочих дней с даты получения макета 80010 должен подтвердить (величины произведенной электроэнергии в ГТП правильность Расчета путем направления в КО. генерации). 2.5 При передаче электронного документа используется расширяемый язык разметки (XML) в соответствии со спецификацией Extensible Markup Language (XML) 1.0. 2.6 При декларации кодировки, являющейся частью декларации XML, используются названия и псевдонимы русскоязычных наборов символов, зарегистрированных в Internet Assigned Numbers Authority. Для данного электронного документа используется кодировка “windows-1251”. Приложение 5.4, п. 3 3. Регламент передачи 3. Регламент согласования 3.1. В случае представления проекта Акта согласования 3.1 Передача макета 80010 производится КО на адрес электронной почты Участника оптового рынка или ФСК, с которой ранее был получен алгоритма расчета величины сальдо перетоков макет 80070 от Участника оптового рынка или ФСК и на основе электроэнергии в сечении между ГТП потребления которого производился данный Расчет. (величины произведенной электроэнергии в ГТП 3.2 Макет 80010 формируется в виде документа XML, подписывается ЭЦП генерации) в формате XML (документ 80070), КО КО. направляет расчет для подтверждения в формате XML с 3.3 Участник оптового рынка или ФСК, получив Расчет от КО, должен использованием ЭЦП. проверить правильность, содержащейся в нем информации. 3.2. При подтверждении расчета Участник отправляет в КО документ 80010 с использованием ЭЦП. Полученный КО 3.4 Если Участник оптового рынка или ФСК согласен с информацией, имеющейся в Расчете, то Участник оптового рынка или ФСК электронный документ должен содержать две ЭЦП. подтверждает Расчет, подписанный ЭЦП КО, путем подписания 3.3. Передача электронных документов 80010 производится на адрес электронной почты iasuku_crypto@rosenergo.com. 3.4. Время передачи Расчета в КО устанавливается по факту получения КО почтового сообщения с электронным документом и указывается в ответном документе. Если присланный документ содержит информацию о том, что Расчет не принят КО, то участник должен исправить ошибки и повторить передачу Расчета в КО. собственной ЭЦП. Далее Расчет, подписанный ЭЦП КО и ЭЦП Участника оптового рынка или ФСК, передается в КО. 3.5 Передача макета 80010 в КО производится на адрес электронной почты iasuku_crypto@rosenergo.com. 3.6 В случае получения КО макета 80010, ранее направленного Участнику оптового рынка или ФСК и подписанного им в соответствии с требованиями настоящего Приложения, Участнику оптового рынка или ФСК автоматически отправляется ответная квитанция (макет 80011). 3.7 Если ответная квитанция содержит информацию о том, что Расчет не принят КО, то Участник оптового рынка или ФСК должен связаться с представителем КО, ответственным за прием информации. 3.8 При отсутствии ответа КО в течение 120 минут после отправки Расчета, Участник оптового рынка или ФСК должен повторить передачу подтвержденного Расчета в КО. Если с момента повторной передачи Расчета не получено ответа КО в течение 120 минут, то уполномоченное лицо организации, ответственное за передачу Расчета, должно связаться с представителем КО, ответственным за прием информации с целью локализации и устранения проблемы. 3.9 Если Участник оптового рынка и ФСК не согласен с информацией, имеющейся в Расчете, то Участник оптового рынка и ФСК для продолжения процедур по данному проекту Алгоритма необходимо отправить письмо на бумажном носителе в КО с просьбой о подготовке базы данных КО для приема макета 80070 с новой информацией и указать причину, по которой Расчет по ранее присланному макету 80070 не может быть подтвержден. Приложение 5.4, п. 4 4. Описание формата передачи Автоматизированного подтверждения расчетов величины учетного показателя (Документ 80010) 4.1. Описание формата документа (80010) … 4. Описание формата 4.1. Имя файла (макет 80010) … 4.3 Описание формата ответной квитанции (макет 80011). 4.3.1. Корневым элементом электронного документа является <message>. В документе допускается наличие только одного элемента <message>. Потомками элемента <message> являются элементы <file>, <reply>. 4.3.2. Атрибут class элемента <message> является обязательным и содержит данные о типе документа. Значение атрибута class должно быть равно 80011. 4.3.3. Атрибут version элемента <message> является обязательным и содержит данные о версии документа. Текущее значение версии равно 2. 4.3.4. Атрибут id элемента <message> является необязательным и содержит уникальный цифровой код сообщения. 4.3.5. Атрибут datetime элемента <message> является необязательным и содержит дату создания ответного сообщения в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды. 4.3.6. Элемент <file> является потомком корневого элемента <message> и содержит информацию о вложенном в электронное сообщение файле XML. В документе допускается наличие только одного элемента <file>. Потомками элемента <file> являются элементы <fromaddr>, <name>, <sender>, <day>, <id>, <received>. 4.3.7. Элемент <fromaddr> является необязательным потомком элемента <file> и содержит адрес электронной почты, с которой пришло письмо, содержащее входящий файл макета 80010, и на который было сформировано данное ответное сообщение. 4.3.8. Элемент <name> является обязательным потомком элемента <file> и содержит название документа XML макета 80010, на который было сформировано данное ответное сообщение. 4.3.9. Элемент <sender> является необязательным потомком элемента <file> и содержит ИНН организации - поставщика информации, которая сформировала входящий файл. 4.3.10. Элемент <day> является необязательным потомком элемента <file> и содержит сутки, на которые был сформирован входящий файл в формате ГГГГММДД, где ГГГГ – год, ММ – месяц, ДД – день. 4.3.11. Элемент <id> является обязательным потомком элемента <file> и содержит код входящего XML-файла в ПАК сбора данных КУ. 4.3.12. Элемент <received> является обязательным потомком элемента <file> и содержит дату получения входящего файла системой ПАК сбора данных КУ в виде ГГГГММДДччммсс, где ГГГГ – год, ММ – месяц, ДД – день, чч – часы в 24-часовом формате, мм – минуты, сс – секунды. 4.3.13. Элемент <reply> является обязательным потомком корневого элемента <message> и содержит информацию по ошибкам файла и статусу его обработки. В документе допускается наличие только одного элемента <reply>. Потомками элемента <reply> являются элементы <error>. 4.3.14. Атрибут filestatus элемента <reply> является необязательным и содержит цифровой код статуса обработки файла. Может принимать следующие значения: 0 ― ошибок при обработке не обнаружено, данные приняты; 3 ― файл содержал ошибки, весь файл либо некоторые данные не были приняты. 4.3.15. Атрибут desc элемента <reply> является необязательным и содержит короткое текстовое описание кода статуса обработки из атрибута filestatus. 4.3.16. Элемент <error> является необязательным потомком элемента <reply> и содержит текст ошибки, найденной во входящем файле. 4.3.17. Атрибут type элемента <error> является необязательным и содержит цифровой код типа ошибки. 4.3.18. Атрибут subtype элемента <error> является необязательным и содержит цифровой код подтипа ошибки.