Код ошибки notacceptablehttpexception рпн

«Ныне действующий портал https://lk. rpn. gov. ru не дает возможности создавать отчеты и сдавать их вовремя. Он абсолютно не работает. Сроки сдачи отчетов не переносят, а экологи подставляются на штрафы из-за невозможности вовремя сдать отчеты».

Из петиции природопользователей, размещенной на Change.org

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

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

Как сдавали отчетность

С конца 2012 года отчетность в Росприроднадзор можно было формировать с помощью программы «Модуль природопользователя» и отправлять в электронном виде через «Личный кабинет природопользователя» (https://lk. fsrpn. ru/#/).

Личный кабинет позволял загружать готовые файлы в формате xml, созданные и в сторонних программах. Кроме того, отчитаться можно было через операторов ЭДО, для чего на портале РПН имелась специальная вкладка.

На протяжении семи лет компании сдавали экоотчетность без особенных проблем. Государство получало причитающиеся платежи в срок, система экоконтроля была относительно налаженной, правила игры — понятны.

Смена коней на переправе

С 25.12.2019 Росприроднадзор ввел в эксплуатацию новый «Личный кабинет природопользователя» (https://lk. rpn. gov. ru/). На сайтах территориальных органов ведомства появились оповещения, что отныне отчетность следует сдавать только через новый сервис.

Практически сразу, с первого же отчета 2020 года (форма 2-ТП воздух, срок сдачи 22.01.2020) начались сбои. Работа «Модуля природопользователя» более не поддерживается, формировать отчеты в нем стало невозможно. Кроме того, все отчеты, хранившиеся в личных кабинетах, исчезли. Компании утратили предыдущие наработки, лишились возможности скопировать и скорректировать свои данные.

Загрузить готовые файлы в систему также невозможно (за исключение формы 2-ТП отходы, добавленной с заметным опозданием).

При этом на заполнение сведений с нуля может уйти от нескольких дней до трех месяцев, что не только существенно повышает трудоемкость рутинной прежде операции, но и чревато риском срыва сроков представления отчетности.

Обновленный сервис не позволяет включить в один отчет несколько объектов, даже когда это прямо предусмотрено нормативными актами. Отсутствуют нужные отчетные формы —отчет ПЭК, формы для экосбора. Ясности, как их сдавать у территориальных органов РПН нет, но ведомство всячески старается не принимать отчеты на бумаге.

Декларация о плате за НВОС появилась только 10 февраля, когда до последнего срока сдачи одного из самых сложных и объемных отчетов оставался ровно месяц. А ведь еще нужно успеть внести плату, значит, все расчеты нужно завершить до 1 марта 2020. При этом сервис сырой, не позволяет сформировать отчет по требованиям законодательства (например, произвести расчет выбросов по источникам, а сбросов — по выпускам). Не говоря уже о пренебрежении деловой стилистикой и русским языком. Так, в разделе 3 графа 8 вместо «Обезврежено в отчетном периоде» значится «Обезьяны в отчетном периоде».

Пример из практики

Компания имеет несколько объектов, оказывающих негативное воздействие на окружающую среду:

объект НВОС № 1 — 3 т выбросов в год;

объект № 2 — 3, 5 т\год;

объект № 3 — 1, 5 тонны в год.

При этом в выбросах есть вещества 1-2 классов опасности (например, бензапирен в выбросах котельной), и компания должна представить отчет по форме 2-ТП (воздух).

Согласно приказу Росстата от 08.11.2018 № 661, нужно подавать форму 2-ТП (воздух), если объем выбросов по всем объектам от 5 до 10 тонн (и в выбросах имеются вещества классов опасности 1-2).

По законодательству, если все опасные объекты находятся в одном субъекте Федерации, компания вправе сформировать один отчет, содержащий три экземпляра каждого из разделов (по одному на каждый из опасных объектов). Однако новый личный кабинет не предусматривает нужного алгоритма, и компания вынуждена готовить три разных отчета. Причем на каждый из них поступит отказ в приемке — из-за того, что не выполняется критерий объема выброса в 5 тонн.

Список экоотчетности, которую сдают компании, смотрите здесь.

Риск санкций

«Прошу Вас официально признать нестабильную работу ЛКПП в отчетный период, чтобы исключить возможные злоупотребления со стороны Ваших подчиненных, в том числе при проверках предприятий; признать установленную возможность направлять отчеты на бумажных носителях, не сформированные в ЛКПП, в рамках действующего законодательства».

Из коллективной жалобы природопользователей, направленной в адрес главы Росприроднадзора Радионовой С. Г.

Природопользователей волнует, станут ли контролеры применять санкции за то, что компании не в состоянии отчитаться качественно и в срок? Перечень административных штрафов широк, они предусмотрены за искажение или сокрытие информации, за непредставление данных, несвоевременное сообщение сведений (статьи КоАП РФ 8,5; 19.7; 13.19; 8.41 и другие нормы).

Размеры санкций для юрлиц также впечатляют, в среднем от 20 000 до 80 000 рублей. За недостоверные сведения в отчетности по экосбору можно поплатиться 250 000 руб., а за несвоевременное его уплату — не менее, чем 500 000 руб. (расчет суммы экосбора подается не позднее 15 апреля).

Решение подсказывают природопользователи

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

Мы собрали и детализировали меры, которые предлагают компании для наведения порядка в процессе сдачи экологической отчетности.

Не чините искусственных препятствий. Позвольте организациям формировать отчетность удобным способом, в том числе с помощью собственного ПО. Дайте возможность загружать и сохранять файлы в личном кабинете. Обеспечьте выкладку в ЛК форматов и обнародуйте правила составления отчетов, их проверки на ошибки.

Регулируйте и контролируйте процесс законными методами. Избежать проблем и споров при сдаче отчетности позволит закрепление правил и требований в нормативно-правовых актах. Нынешний глава Кабмина Михаил Мишустин в ФНС России на деле доказал, что даже самая сложная отчетность может поступать в ведомство четко и в срок. Для этого ведомству надлежит:

— создать и утвердить регламент или другой нормативно-правовой акт с описанием порядка подачи, приема отчетов в электронном виде (по примеру ФНС, ПФР и других контролирующих органов);

— утвердить и опубликовать электронные форматы форм 2-ТП (отходы), 2-ТП (рекультивация), 2-ТП (воздух), а также Декларации о плате за НВОС, Заявки о постановке объектов НВОС на государственный учет, Отчета о результатах ПЭК, форм Экологического сбора.

Разрешите альтернативу. Многие природопользователи начали формировать экологические отчеты в Excel или Word. Они лично приносят их на бумаге или отправляют по почте в территориальные органы РПН. Напомним, если лицо, обязанное вносить плату, не имеет технической возможности подключиться к интернету, декларация представляется на бумаге (приказ Минприроды России от 09.01.2017 № 3). Примите меры для того, чтобы территориальные органы не препятствовали этому, принимали отчеты на бумаге.

Значительная часть природопользователей формирует и сдает отчетность через операторов ЭДО долгие годы. Позвольте компаниям продолжить взаимодействие с операторами. В идеале, если ведомство предоставит программный интерфейс (API), то есть сервис, куда информация будет поступать прямо из информационной системы хозяйствующего субъекта, это выгодно и бизнесу, и государству.

Крупные компании заинтересованы, чтобы сотрудник, ответственный за отчетность, работал в привычном интерфейсе. Тогда ресурсы компании не расходуются впустую на освоение разных интерфейсов многочисленных контролирующих органов, на ввод информации из учетной системы в ручном режиме. Государственное ведомство может не раздувать штат специалистов, ответственных за техподдержку — эти вопросы решает оператор. Он же обеспечивает корректность взаимодействия каналов связи, снижая риск чрезмерной нагрузки на API и DDOS-атак. Оператор, по сути, выступает гарантом процесса, ведь в случае сбоя он рискует своим бизнесом.

Обработка исключений в контроллерах Spring

Часто на практике возникает необходимость централизованной обработки исключений в рамках контроллера или даже всего приложения. В данной статье разберём основные возможности, которые предоставляет Spring Framework для решения этой задачи и на простых примерах посмотрим как всё работает. Кому интересна данная тема — добро пожаловать под кат!

Изначально до Spring 3.2 основными способами обработки исключений в приложении были HandlerExceptionResolver и аннотация @ExceptionHandler. Их мы ещё подробно разберём ниже, но они имеют определённые недостатки. Начиная с версии 3.2 появилась аннотация @ControllerAdvice, в которой устранены ограничения из предыдущих решений. А в Spring 5 добавился новый класс ResponseStatusException, который очень удобен для обработки базовых ошибок для REST API.

А теперь обо всём по порядку, поехали!

Обработка исключений на уровне контроллера — @ExceptionHandler

С помощью аннотации @ExceptionHandler можно обрабатывать исключения на уровне отдельного контроллера. Для этого достаточно объявить метод, в котором будет содержаться вся логика обработки нужного исключения, и проаннотировать его.

В качестве примера разберём простой контроллер:

Тут я сделал метод testExceptionHandler, который вернёт либо исключение BusinessException, либо успешный ответ — всё зависит от того что было передано в параметре запроса. Это нужно для того, чтобы можно было имитировать как штатную работу приложения, так и работу с ошибкой.

А вот следующий метод handleException предназначен уже для обработки ошибок. У него есть аннотация @ExceptionHandler(BusinessException. class), которая говорит нам о том что для последующей обработки будут перехвачены все исключения типа BusinessException. В аннотации @ExceptionHandler можно прописать сразу несколько типов исключений, например так: @ExceptionHandler().

Сама обработка исключения в данном случае примитивная и сделана просто для демонстрации работы метода — по сути вернётся код 200 и JSON с описанием ошибки. На практике часто требуется более сложная логика обработки и если нужно вернуть другой код статуса, то можно воспользоваться дополнительно аннотацией @ResponseStatus, например @ResponseStatus(HttpStatus. INTERNAL_SERVER_ERROR).

Пример работы с ошибкой:

Пример штатной работы:

Основной недостаток @ExceptionHandler в том что он определяется для каждого контроллера отдельно, а не глобально для всего приложения. Это ограничение можно обойти если @ExceptionHandler определен в базовом классе, от которого будут наследоваться все контроллеры в приложении, но такой подход не всегда возможен, особенно если перед нами старое приложение с большим количеством легаси.

Обработка исключений с помощью HandlerExceptionResolver

HandlerExceptionResolver является общим интерфейсом для обработчиков исключений в Spring. Все исключений выброшенные в приложении будут обработаны одним из подклассов HandlerExceptionResolver. Можно сделать как свою собственную реализацию данного интерфейса, так и использовать существующие реализации, которые предоставляет нам Spring из коробки. Давайте разберем их для начала:

ExceptionHandlerExceptionResolver — этот резолвер является частью механизма обработки исключений с помощью аннотации @ExceptionHandler, о которой я уже упоминал ранее.

DefaultHandlerExceptionResolver — используется для обработки стандартных исключений Spring и устанавливает соответствующий код ответа, в зависимости от типа исключения:

Основной недостаток заключается в том что возвращается только код статуса, а на практике для REST API одного кода часто не достаточно. Желательно вернуть клиенту еще и тело ответа с описанием того что произошло. Эту проблему можно решить с помощью ModelAndView, но не нужно, так как есть способ лучше.

ResponseStatusExceptionResolver — позволяет настроить код ответа для любого исключения с помощью аннотации @ResponseStatus.

В качестве примера я создал новый класс исключения ServiceException:

В ServiceException я добавил аннотацию @ResponseStatus и в value указал что данное исключение будет соответствовать статусу INTERNAL_SERVER_ERROR, то есть будет возвращаться статус-код 500.

Для тестирования данного нового исключения я создал простой контроллер:

Если отправить GET-запрос и передать параметр exception=true, то приложение в ответ вернёт 500-ю ошибку:

Из недостатков такого подхода — как и в предыдущем случае отсутствует тело ответа. Но если нужно вернуть только код статуса, то @ResponseStatus довольно удобная штука.

Кастомный HandlerExceptionResolver позволит решить проблему из предыдущих примеров, наконец-то можно вернуть клиенту красивый JSON или XML с необходимой информацией. Но не спешите радоваться, давайте для начала посмотрим на реализацию.

В качестве примера я сделал кастомный резолвер:

Ну так себе, прямо скажем. Код конечно работает, но приходится выполнять всю работу руками: сами проверяем тип исключения, и сами формируем объект древнего класса ModelAndView. На выходе конечно получим красивый JSON, но в коде красоты явно не хватает.

Такой резолвер может глобально перехватывать и обрабатывать любые типы исключений и возвращать как статус-код, так и тело ответа. Формально он даёт нам много возможностей и не имеет недостатков из предыдущих примеров. Но есть способ сделать ещё лучше, к которому мы перейдем чуть позже. А сейчас, чтобы убедиться что всё работает — напишем простой контроллер:

А вот и пример вызова:

Видим что исключение прекрасно обработалось и в ответ получили код 400 и JSON с сообщением об ошибке.

Обработка исключений с помощью @ControllerAdvice

Наконец переходим к самому интересному варианту обработки исключений — эдвайсы. Начиная со Spring 3.2 можно глобально и централизованно обрабатывать исключения с помощью классов с аннотацией @ControllerAdvice.

Разберём простой пример эдвайса для нашего приложения:

Как вы уже догадались, любой класс с аннотацией @ControllerAdvice является глобальным обработчиком исключений, который очень гибко настраивается.
В нашем случае мы создали класс DefaultAdvice с одним единственным методом handleException. Метод handleException имеет аннотацию @ExceptionHandler, в которой, как вы уже знаете, можно определить список обрабатываемых исключений. В нашем случае будем перехватывать все исключения BusinessException.

Можно одним методом обрабатывать и несколько исключений сразу: @ExceptionHandler(). Так же можно в рамках эдвайса сделать сразу несколько методов с аннотациями @ExceptionHandler для обработки разных исключений.
Обратите внимание, что метод handleException возвращает ResponseEntity с нашим собственным типом Response:

Таким образом у нас есть возможность вернуть клиенту как код статуса, так и JSON заданной структуры. В нашем простом примере я записываю в поле message описание ошибки и возвращаю HttpStatus. OK, что соответствует коду 200.

Для проверки работы эдвайса я сделал простой контроллер:

В результате, как и ожидалось, получаем красивый JSON и код 200:

А что если мы хотим обрабатывать исключения только от определенных контроллеров?
Такая возможность тоже есть! Смотрим следующий пример:

Обратите внимание на аннотацию @ControllerAdvice(annotations = CustomExceptionHandler. class). Такая запись означает что CustomAdvice будет обрабатывать исключения только от тех контроллеров, которые дополнительно имеют аннотацию @CustomExceptionHandler.

Аннотацию @CustomExceptionHandler я специально сделал для данного примера:

А вот и исходный код контроллера:

В контроллере Example5Controller присутствует аннотация @CustomExceptionHandler, а так же на то что выбрасывается то же исключение что и в Example4Controller из предыдущего примера. Однако в данном случае исключение BusinessException обработает именно CustomAdvice, а не DefaultAdvice, в чём мы легко можем убедиться.

Для наглядности я немного изменил сообщение об ошибке в CustomAdvice — начал добавлять к нему дату:

Исключение ResponseStatusException.

Сейчас речь пойдёт о формировании ответа путём выброса исключения ResponseStatusException:

Выбрасывая ResponseStatusException можно также возвращать пользователю определённый код статуса, в зависимости от того, что произошло в логике приложения. При этом не нужно создавать кастомное исключение и прописывать аннотацию @ResponseStatus — просто выбрасываем исключение и передаём нужный статус-код. Конечно тут возвращаемся к проблеме отсутствия тела сообщения, но в простых случаях такой подход может быть удобен.

Резюме: мы познакомились с разными способами обработки исключений, каждый из которых имеет свои особенности. В рамках большого приложения можно встретить сразу несколько подходов, но при этом нужно быть очень осторожным и стараться не переусложнять логику обработки ошибок. Иначе получится что какое-нибудь исключение обработается не в том обработчике и на выходе ответ будет отличаться от ожидаемого. Например если в приложении есть несколько эдвайсов, то при создании нового нужно убедиться, что он не сломает существующий порядок обработки исключений из старых контроллеров.
Так что будьте внимательны и всё будет работать замечательно!