Незаконный обход ошибок ЕИС, или что запрещено предлагать

[kir_dfg]

Итак, уважаемые коллеги. Публикую краткую информацию о проделанных технических исследованиях по предмету данной темы. Постараюсь не углубляться в совсем уж технические детали, но извиняйте, если уж не удержусь.
Итак, прежде всего следует сказать, что данный метод действительно работает. Именно так, как предполагается - то есть обходит все ошибки, по которым запрещена публикация (за исключением ошибок схемы данных, но это уже совсем другие ошибки). Но на этом его достоинства заканчиваются.
Разделим проблемы, которые при этом возникают или могут возникнуть, на две относительно независимые группы: нормативно-правовые и технические.
Среди нормативно-правовых следует, прежде всего, назвать:
1) Незаконность правки страниц в части их клиентского кода. Этим Вы нарушаете авторские права разработчиков. Не очень существенный момент, однако не упоминать о нем нельзя. Кроме того, данная попытка, вообще-то, не является ничем иным, как хакерством. Что тоже наказуемо...
2) Незаконность обхода ошибок, которые выдает ЕИС. Это следует из того, что большинство ФЛК, запрещающих публикацию, так или иначе, выведены из положений НПА. Например, та же самая детализация КВР - публикуя в данный момент записи с кодом 810, Вы нарушаете Приказ Минфина России от 01.07.2013 № 65н "Об утверждении Указаний о порядке применения бюджетной классификации Российской Федерации". Изменения в данный приказ в части указанных кодов, правда, были внесены 7.12.2016, но, поскольку в ЕИС они появились гораздо позже, то выбора в тот период не было. А теперь он есть - нарушать или нет.
3) Если речь идет о такой самоубийственной операции, как удаление опубликованных позиций, или, тем более, всего опубликованного плана, тут все совсем печально – это уже дело подсудное, так как Вы удаляете документ, подписанный собственной (или, того хуже, чужой) подписью. Так что все коды, которые приведены сегодня выше, вообще не следует использовать!

[kir_dfg]

Теперь о технической стороне вопроса. Тут все гораздо интереснее и обширнее.
Как уже говорилось на этом форуме, ЕИС работает по клиент-серверной технологии. Это означает, что есть сервер (то есть компьютер, расположенный где-то в МСК и отвечающий на запросы пользователей) и клиент (то есть компьютер, за которым сидит пользователь). Пользователь запрашивает некие данные, при этом обращаясь на сервер, а сервер после обработки запроса возвращает клиенту данные в составе страницы, которая и отображается в браузере. Так вот. Вместе с этими данными передается также некоторый программный код (назовем его клиентский код) для обработки событий, в которых серверу участвовать не требуется. Например, таких, как изменение одного поля данных на странице при изменении другого поля, обработка нажатия кнопок и так далее.
Принципиальным является то, что никакой клиентский код, на самом деле, не способен до конца обработать тот или иной запрос. Это очевидно – допустим, Вы отправляете что-то для размещения - это же нужно передать на сервер, чтоб он это обработал и сохранил в базе данных. Схема действий примерно такая: Вы формируете план, нажимаете «Отправить», клиентский код его размечает и отправляет на сервер. Сервер осуществляет верификацию, возвращает ошибки, и они Вам выдаются в знаменитом окошке. Далее, в зависимости от того, что вернул сервер, клиентский код выводит Вам несколько кнопок – кнопки исправления и/или продолжения. При этом, если есть хотя бы одна ошибка, этот код не выведет кнопки «Продолжить». Если нажата кнопка «Продолжить» (при наличии), или ошибок нет, то клиентская сторона формирует с согласия пользователя ЭЦП и отправляет подписанную структуру на сервер уже для размещения (ну или контроля – несущественно в данном объяснении).
В нашумевшем методе предлагается изменить код страницы так, чтобы кнопка «Продолжить» выводилась даже и в последнем случае. То есть получается, что, несмотря на предупреждения сервера о том, что данные некорректны, пользователь их подписывает и отправляет для размещения. Другими словами, используется уязвимость сервера - второй раз подписанные данные уже не проверяются.

[kir_dfg]

И что же мы имеем? А имеем мы размещенную структуру данных, не прошедшую ФЛК. При этом совсем необязательно, что это вызовет какие-то проблемы с этим планом – возможно, все будет хорошо. А возможно, что размещение подобной структуры пойдет в рассогласование с форматом базы данных на сервере, вызовет какие-то непредсказуемые ошибки в будущем, например, при обходе плана закупок приведет к невероятным глюкам в ПГ, нарушит связи и так далее.
И вот тут и возникает главная проблема правки клиентского кода: если Вы не знаете в деталях, как сервер обрабатывает те или иные данные, как реагирует на ту или иную ошибку, почему считает ее ошибкой (то есть является ли это следствием технических деталей реализации кода или нормативных каких-то положений), Вы не вправе считать, что изменение клиентского кода будет безопасным.
Этого не знает никто (должны знать разработчики, но что-то я в этом уже тоже стал сомневаться))). Иначе говоря, если Вы отправляете структуру, не соответствующую схеме данных и/или не прошедшую ФЛК, последствия будут непредсказуемыми.
Несколько реальных примеров – опыт прошлых четырех месяцев. Один уже где-то озвучивал на форуме. Здесь есть инструкции, по которым можно было исправить проблему невозможности внесения изменений в позицию ПЗ из-за некорректного наименования. Они как раз из этого сорта – правка кода страницы. Есть относительно безопасные, а есть и не очень. У нас в регионе один товарищ взял такую инструкцию, в которой было указано: скопировать разметку рабочей позиции на место нерабочей, изменив ключи (там их сейчас три). Он скопировал, но изменил только два ключа. Как только он после этого нажал кнопку «Изменить», ему была предъявлена позиция- чудо селекции: сумма от одной, наименование от другой, а ИКЗ превратился в пятизначное число (год размещения извещения плюс КВР). И более данный гибрид нельзя было ни сохранить, ни попробовать разделить, ни удалить – во всех действиях система зависала (то есть клиентский код отправлял на сервер запрос действия, а сервер не понимал, чего от него хотят). Проблему удалось решить через ТП в течение пары недель. Но они долго мучали вопросами.

[kir_dfg]

Второй пример. Все мы знаем, что извещение привязывается к ПГ, а не к ПЗ. А в ПГ ИКЗ формируется не вручную, а методом частичного переноса с ИКЗ позиции ПЗ – то есть поля частично перекрываются, частично копируются. А теперь представьте, что Вы в ПЗ зафутболили какое-то изменение ИКЗ мимо контроля ФЛК. Можете ли Вы гарантировать на 100 %, что ИКЗ, измененный в ПЗ, повторно корректно привяжется к ПГ? И есть ли вообще в серверном коде обработка такой ситуации, учитывая, что изменение ИКЗ незаконно? Тем более, что мне неизвестно ни одного случая, когда даже реализованная в ЕИС опция «Ввести одной строкой» была корректно отработана и в ПЗ, и в ПГ. Можете, да, его поменять. Но дальше что? Отправите на контроль мимо ФЛК? Но что при этом произойдет с ПГ?
На форуме есть инструкция, как изменить ИКЗ позиции, слазив в код страницы и тупо там его поправив. Один из участников воспользовался ей. ИКЗ в ПГ при этом, как ни странно, не изменился. То есть, помимо прямого нарушения 44 закона, у него еще и ИКЗ в ПГ, не соответствующий ПЗ, и размещенное извещение с ИКЗ КВР, который отражен в ПГ, а не в ПЗ, т.е. с неправильным. Соответственно, казначейство заворачивает сие извещение, а недальновидный участник оказывается в безвыходной ситуации – удалить извещение, не прошедшее контроль, нельзя, отменить позицию ПГ, к которой привязано извещение, тоже, а отменить позицию ПЗ нельзя, потому что не отменена позиция ПГ. Теперь, поскольку все эти позиции подписаны, он вынужден обращаться в ФАС или прокуратуру с жалобой на самого себя для того, чтобы удалить эту цепочку.

[kir_dfg]

Для тех, кто еще не осознал всю опасность подобных правок, еще один пример. Человек хочет внести изменения в КВР ПГ. Но при этом, в силу отсутствия представления о работе с программным кодом, считает, что инструкция о внесении изменений в наименование позиции – для него. Заходит в код, не видит там ничего подозрительного (по инструкции), и решает исправить то, что, по его мнению, является источником проблемы. При этом он задевает имя функции, к которой происходит обращение в момент нажатия кнопки «Изменить» - меняет его на такое же, как в остальных позициях. Однако он не учел, что данная позиция находилась в статусе «размещена», тогда как остальные не были размещены, и находились в статусах «новая» или «изменена». В результате скопировал позицию из статуса «новая». Позиция открылась (хотя она и так открывалась – проблема-то была совсем не в этом). КВР, естественно, изменить не удалось. Но когда он попытался опубликовать данный план, ему была выдана длинная «портянка» ошибок, которую мы все хорошо знаем – о несоответствии схемы данных. И здесь, так же, как и в предыдущих случаях, он уже не смог самостоятельно исправить проблему.
Я думаю, не обязательно дальше конкретизировать какие-то технические проблемы по данному методу, так как все вышесказанное в равной степени относится и к нему, тем более, что он, как порошок «Дося», отстирывает…пардон, исправляет все возможные ошибки. Но хотелось бы еще отметить некоторые моменты по ошибкам, которые имеют место быть последнее время:
1) Проблема с детализацией КВР – на текущий момент самая популярная. Если Вы отправляете ПЗ с кодом 810, то последующее создание ПГ и извещения, скорее всего, обломится на этапе контроля этого извещения. Плюс к этому: если Вы попытаетесь исправить ИКЗ вручную через код страницы, то, скорее всего, нарушите связь ИКЗ с ПГ.
2) Дублирование позиций в особых закупках (одинаковые КВР по одному году). Обход этой ошибки грозит тем, что при обращении к позициям особых закупок в ПГ будет выдана известная многим уже ошибка «Произошла ошибка, обратитесь в техподдержку». Данный вывод сделан только по клиентскому коду – к серверному доступа у меня нет.

[kir_dfg]

Таким образом, было доказано, что применение данного метода, а также любая иная правка кода, представляет собой крайнюю меру недопущения срывов закупок, опасную и с нормативно-правовой, и с технической стороны. Я бы рекомендовал ей пользоваться только в исключительных случаях, а по возможности – вообще не использовать.
Что касается выданных уважаемым Всальдой сегодня еще трех фрагментов, то они будут уничтожены. Поясняю, почему – из вышесказанного явствует, какой огромный риск несут мелкие изменения кода и шалости вроде добавления кнопок. Что же говорить тогда о таких серьезных вещах, как удаление всего плана? Я даже не возьмусь пофантазировать на этот счет. А Вы?

Уважаемые коллеги. Если у кого-то возникнет острая необходимость что-то поправить таким вот способом, рекомендую Вам, учитывая изложенное, подумать об этом глубоко и долго. Только потом Вы можете обратиться к "инструкции" в первом посте этой темы (которую я обработаю и сделаю более подробной в ближайшее время, возможно, включу в FAQ с полдюжиной предупреждений), снова подумать (а справлюсь ли я?), и в случае уверенности в своих силах выполнить эти действия. Обращаю внимание, что на форуме не будут даваться консультации по данному методу во избежание возникновения претензий, недавно осмеянных троллем из курилки.

[rus94]

Спасибо Кир, полезно написали... но хочу заметить, все это происходит не от хорошей жизни, довели заков до края.

Я помню свое состояние в январе, а люди в таком состоянии до сих пор прибывают.

[kir_dfg]

Спасибо Кир, полезно написали... но хочу заметить, все это происходит не от хорошей жизни, довели заков до края.

Я помню свое состояние в январе, а люди в таком состоянии до сих пор прибывают.

Конечно, что Вы, я все прекрасно понимаю...Особенно вот по этой последней ошибке с детализацией - уж в этом точно виноваты только разработчики ЕИСа. Они обязаны были ввести новые КВР еще в декабре, и ФЛК этот ввести тогда же, а не потом, когда уже у всех все было опубликовано.
Хотя, лукавить не будем, есть ведь немало случаев возникновения необходимости правок, не предусмотренных законом, из-за собственной невнимательности

[Александр С]

Кир, как чудило, которое воспользовалось этой схемой, хотел уточнить, Вы описывали что будет отсутствовать повторная обработка направляемых данных, поясните пожалуйста доходчиво.

[kir_dfg]

Кир, как чудило, которое воспользовалось этой схемой, хотел уточнить, Вы описывали что будет отсутствовать повторная обработка направляемых данных, поясните пожалуйста доходчиво.

Нет, Вы не поняли. Это было в описании процессов, происходящих в ЕИС при отправке, и имелось в виду, что первый раз информация направляется для ФЛК, затем сервер возвращает ошибки, если они есть, и затем уже повторно отправляется для размещения с подписью. Так вот, во второй раз ФЛК уже не проводится. И эту уязвимость использует указанный метод.