ошибка в формате кода варианта услуги что делать

Как понять уведомление ФНС об отказе: шпаргалка для бухгалтера

Проверив отчет, ФНС в течение следующего рабочего дня направляет компании квитанцию о приеме или уведомление об отказе. В документе пишут код ошибки и расшифровку этого кода. Чтобы бухгалтерам было проще разобраться, в чем ошибка и как ее исправить, эксперты Экстерна составили шпаргалку по 10 самым распространенным причинам отказов.

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

Отказ в приеме отчетности: как действовать

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

Если вы впервые сдавали отчет с таким номером корректировки, ошибка может быть связана с тем, что файл повторно загрузился базу данных ИФНС. Отчет в этом случае считается представленным.

Как проверить, что отчет принят, описано в инструкции

Отказы с такой формулировкой приходят на РСВ.

Причина в том, что в базе ФНС суммы в приложении 1 Раздела 1 не сходятся с суммой значений за 3 месяца из Приложения 1 и соответствующих значений по всем сотрудникам за предыдущие периоды.

Как исправить эту ошибку, описано в инструкции

Экстерн помогает «отловить» большинство ошибок до отправки отчета, а если придет отказ — быстро сориентироваться, что и как исправить.
Попробуйте — 14 дней бесплатно.

Отказ в приеме отчетности: как действовать (продолжение)

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

Про оформление доверенности для отчетности мы писали в статье. Там же можно скачать образцы доверенностей для разных случаев

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

Не пропустите новые публикации

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

Источник

Ошибки при отправке заявления в ведомство на Госуслугах — что делать, и как исправить?

В данном материале разберём распространённые ошибки, которые могут появляться при онлайн оформлении документов через интернет, посредством портала государственных услуг.

Рис. 1. Внутренняя ошибка на портале Госуслуг (Что-то пошло не так)

Если проблемы при загрузке файлов связаны с ошибками в их параметрах, то нужно обработать файлы по требованиям Госуслуг. Вы можете заказать редактирование файлов у нас. Обрабатываем файлы с гарантией загрузки на портале Госуслуг. Сфотографировать документы можно на камеру телефона. Для заказа нажмите на кнопку ниже.

Содержание:

Перебои на сайте, или ошибка при отправке заявления на Госуслугах

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

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

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

Рис. 2. Ошибка на Госуслугах — размер файла превышает максимально допустимый 5000 Кб

Например, описание ошибки может содержать следующие сведения:

Не все данные заполнены. При этом, пропущенное поле выделено красным цветом;

К загрузке доступно не более 10 файлов;

Ошибка проверки данных документа, удостоверяющего личность. Данные не найдены.

Как видно по вышеперечисленным ошибкам — их формулировки предельно ясны и понятны. Портал напрямую указывает, в чём проблема, и что нужно исправить.

Однако, зачастую встречаются и довольно пространные формулировки ошибок, смысл которых несколько размыт, и до конца не ясен. Например:

Произошла ошибка при обработке запроса проверки фото;

Не сработало. Попробуйте снова;

Произошла ошибка при отправке заявления в ведомство;

Что то пошло не так;

Это может занять некоторое время (при этом, идёт бесконечная загрузка, и ничего не происходит);

Bad Request: На экране s60 не найдено экранов для перехода.

Рис. 3. Во время обработки запроса произошла ошибка

Такие ошибки сигнализируют о неких проблемах при отправке заявки на сайте Госуслуг, но при этом, их причины не выявлены автоматизированным алгоритмом сервиса.

Если проблемы при загрузке файлов связаны с ошибками в их технических параметрах (размер, вес и формат), то их нужно обработать в полном соответствии с требованиями Госуслуг. Вы можете заказать редактирование файлов на нашем сервисе. Обрабатываем файлы с гарантией одобрения на портале Госуслуг. Сфотографировать документы можно на камеру телефона. Для заказа нажмите на кнопку ниже.

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

Чтобы это проверить, рекомендуется повторить отправку запроса чуть позже. Если ошибка была связана со сбоями на портале Госуслуг, то повторная отправка заявки, как правило, решает проблему.

Сбои в автоматизированном сервисе портала Госуслуг случаются не редко, в связи с большой нагрузкой на ресурс. При этом, они оперативно устраняются сотрудниками портала. Как правило, достаточно отправить повторный запрос через 10 или 15 минут

Также, очень часто помогает смена браузера. Например, ошибка с формулировкой — «Не сработало«, в большинстве случаев, решается перезаходом на ГосУслуги через новый браузер, и повторением заполнения заявки с нуля.

Рис. 4. Госуслуги — Не сработало. Попробуйте снова.

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

Таким образом, с временными неполадками на Госуслугах всё более менее понятно — их достаточно просто распознать и выявить. А в большинстве случаев, портал сообщит, что проблемы именно на его стороне.

Рис. 5. Портал Госуслуг временно недоступен

Совсем другое дело, если проблема наличествует на стороне пользователя. А это, как показывает практика, случается гораздо чаще.

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

Объясняется это, прежде всего разным уровнем компьютерной подготовки у аудитории портала. Если принимать во внимание, что численность ресурса, на сегодняшний день, составляет более 80 млн. зарегистрированных пользователей, то становится понятно, что обрабатывать такую аудиторию на полном автомате, бывает проблематично.

Если проблемы при загрузке файлов связаны с ошибками в их параметрах, то нужно обработать файлы по требованиям Госуслуг. Вы можете заказать редактирование файлов у нас. Обрабатываем файлы с гарантией загрузки на портале Госуслуг. Сфотографировать документы можно на камеру телефона. Для заказа нажмите на кнопку ниже.

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

Произошла ошибка при отправке запроса в ведомство — проблема на стороне пользователя

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

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

Ошибка в заполнении персональных данных;

Неисполнение требований Госуслуг к загружаемым файлам (личной фотографии, или документов в электронном виде);

Неверное указание адреса ведомства ответственного за обработку заявки.

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

Чтобы сразу отсеять эти пункты, внимательно перепроверьте все заполненные графы на актуальность информации. При предоставлении персональных данных наиболее распространены ошибки в цифрах и датах.

Рис. 6. Ошибки при заполнении сведений о трудовой деятельности на портале Госуслуг

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

Что касается третьего пункта, а именно неверного указания подразделения ответственного за исполнение заявки, то указание неверного адреса ФМС, тоже достаточно распространённая ошибка на Госуслугах.

Чтобы её исключить, портал ввёл специальные автоматические подсказки, которые предлагают полный адрес подразделения при наборе его первых букв.

Начните вводить первые буквы адреса ближайшего к Вам подразделения (в случае оформления загранпаспорта, это будет отделение ФМС). При возникновении подсказок снизу от поля ввода, выберите правильный вариант. Не нужно пытаться в ручную вбивать адрес, игнорируя подсказки

Если с первым и третьим пунктом проблем нет, но сайт Гос услуг снова выдаёт ошибку, то остаётся только второй пункт. С ним дела обстоят немного сложнее, так как он включает в себя несколько возможных вариаций неправильных действий со стороны пользователя. Поэтому, далее разберём их подробнее.

Технические требованиям к файлам загружаемым на ГосУслуги

Итак, последний пункт, который нам остаётся проверить — параметры загружаемого файла. Что с ними может быть не так?

Дело в том, что проблема может быть сразу по нескольким направлениям. Оговариваются они требованиями ведомства к загружаемым на портал файлам.

Соответственно, необходимо проверить файл по ряду обязательных параметров. Далее перечислим основные из них.

Требования к содержимому фотографии:

На снимке должен присутствовать только один человек, с положением головы строго в анфас, и спокойным выражением лица;

Изображение должно быть чёткое. Все особенности внешности и черты лица отчётливо просматриваемы;

Соотношение пропорций головы относительно общей площади фотографии — 80%;

Не допускается фотография в затемненных очках, головных уборах, и прочих элементов одежды затрудняющих идентификацию личности (примечание: головной убор допустим для граждан чьи религиозные обычаи предписывают обязательное его ношение);

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

Рис. 7.Требования к фотодля Госуслуг

Требования к техническим параметрам файла:

Размер (соотношение сторон). В зависимости от оформляемой услуги или документа, этот параметр может отличаться. Например, при подаче заявки на получение или смену паспорта РФ, необходимо прикрепить личное фото размером 35 на 45 мм;

Вес (объём) файла. По данному параметру существуют минимальные и максимальные ограничения за пределы которые нельзя выходить. Эти ограничения опять-таки зависят от конкретного вида оформляемой услуги или документа. Например, при оформлении справки о несудимости, общий объём загружаемых файлов не должен превышать — 5120 Кб;

Разрешение изображения. Не менее важный показатель качества изображения изменяемый в точках на дюйм (DPI). Как правило, Госуслуги принимают файлы с разрешением не менее 300 или 450 DPI. Значения ниже этой отметки, не принимаются, так как качество изображения может быть недостаточным, чтобы отчётливо прочесть информацию на скан-копии документа (например, главного разворота паспорта с актуальной информацией);

Формат прикрепляемого документа. Расширение файла тоже имеет значение, но в большинстве случаев ничего менять не придётся, так как портал Госуслуг принимает файлы в самых популярных форматах сжатия. Это — JPEG, PDF, RAR.

Рис. 8.Стандартные требования к файлам для загрузки на Госуслуги

Внимательно читайте подсказки на портале сопровождающие заполнение каждого поля в электронном заявлении. Как правило, они дают исчерпывающую информацию по каждому заполняемому пункту

Что делать если появляется ошибка при отправке заявления на Госуслугах?

Мы разобрали основные причины почему портал выдаёт сообщения об отказе в приёме заявления. Теперь осталось решить, что с этим делать?

На самом деле, здесь только один вариант — нужно устранить ошибку на которую указывает ведомство. Но есть два способа, как это можно сделать.

Если дело касается ошибки в заполнении данных (например, неправильно указана дата рождения), то это самый идеальный способ. Просто нужно проявить внимательность, и исправить нужный пункт.

Другое дело, если проблема кроется в неправильно отредактированном файле, который нужно загрузить на Госуслуги. Это может быть личная фотография, или электронная копия документа. Из-за неправильного веса, размера или формата файла, заявку будут постоянно отклонять на Госуслугах.

И в этом случае, чтобы решить проблему самостоятельно, необходимо соответствующим образом откорректировать все необходимые параметры документа в любом графическом редакторе. А для этого, потребуются мало-мальские знания и опыт работы с программой для обработки фотографий.

Рис. 9. Редактирование файла через редактор FastStone Image Viewer

Если же, у вас нет времени на самостоятельное редактирование, то существует более лёгкий, а самое главное, надёжный способ.

Если Вы столкнулись с проблемой, когда портал Госуслуг постоянно выдаёт ошибку при отправке заявления в ведомство, то одним из способов быстрого решения проблемы, будет обращение к специалистам сервиса ФотоНаГосуслуги.ру.

Наш сервис специализируется на редактировании файлов в полном соответствии с требованиями ведомства, и значительно облегчает отправку электронного заявления в органы исполнительной власти.

Заказать услугу редактирования фотографий и скан-копий документов для отправки на Госуслуги, можно перейдя по кнопке ниже.

Источник

Как работать с ошибками бизнес-логики через HTTP

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры «дергают» бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.

№1: HTTP статусы

Если почитать апологетов REST, то для кодов ошибок надо использовать HTTP статусы, а текст ошибки отдавать в теле или в специальном заголовке. Например:

Если у вас примитивная бизнес-логика или API из 5 url, то в принципе это нормальный подход. Однако как-только бизнес-логика станет сложнее, то начнется ряд проблем.

Http статусы предназначались для описания ошибок при передаче данных, а про логику вашего приложения никто не думал. Статусов явно не хватает для описания всего разнообразия ошибок в вашем проекте, да они и не были для этого предназначены. И тут начинается натягивание «совы на глобус»: все начинают спорить, какой статус ошибки дать в том или ином случае. Пример: Есть API для task manager. Какой статус надо вернуть в случае, если пользователь хочет взять задачу, а ее уже взял в работу другой пользователь? Ссылка на http статусы. И таких проблемных примеров можно придумать много.

REST скорее концепция, чем формат общения из чего следует неоднозначность использования статусов. Разработчики используют статусы как им заблагорассудится. Например, некоторые API при отсутствии сущности возвращают 404 и текст ошибки, а некоторые 200 и пустое тело.

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

Когда бизнес-логика приложения усложняется, начинают делать как-то так:

Из-за ограниченности http статусов разработчики начинают вводить “свои” коды ошибок для каждого статуса и передавать их в теле ответа. Другими словами, пользователю API приходится писать нечто подобное:

Из-за этого ветвление клиентского кода начинает стремительно расти: множество http статусов и множество кодов в самом сообщении. Для каждого ошибочного http статуса необходимо проверить наличие кодов ошибок в теле сообщения. От комбинаторного взрыва начинает конкретно пухнуть башка! А значит обработку ошибок скорее всего сведут к сообщению типа “Произошла ошибка” или к молчаливому некорректному поведению.

Многие системы мониторинга сервисов привязываются к http статусам, но это не помогает в мониторинге, если статусы используются для описания ошибок бизнес логики. Например, у нас резкий всплеск ошибок 429 на графике. Это началась DDOS атака, или кто-то из разработчиков выбрал неудачный статус?

Итог: Начать с таким подходом легко и просто и для простого API это вполне подойдет. Но если логика стала сложнее, то использование статусов для описания того, что не укладывается в заданные рамки протокола http приводит к неоднозначности использования и последующим костылям для работы с ошибками. Или что еще хуже к формализму, что ведет к неприятному пользовательскому опыту.

№2: На все 200

Есть другой подход, даже более старый, чем REST, а именно: на все ошибки связанные с бизнес-логикой возвращать 200, а уже в теле ответа есть информация об ошибке. Например:

На самом деле формат зависит от вас или от выбранной библиотеки для реализации коммуникации, например JSON-API.

Звучит здорово, мы теперь отвязались от http статусов и можем спокойно ввести свои коды ошибок. У нас больше нет проблемы “впихнуть невпихуемое”. Выбор нового типа ошибки не вызывает споров, а сводится просто к введению нового числового номера (например, последовательно) или строковой константы. Например:

Клиентские разработчики просто основываясь на кодах ошибок могут создать классы/типы ошибок и притом не бояться, что сервер вернет один и тот же код для разных типов ошибок (из-за бедности http статусов).

Обработка ошибок становится менее ветвящейся, множество http статусов превратились в два: 200 и все остальные (ошибки транспорта).

В некоторых случаях, если есть библиотека десериализации данных, она может взять часть работы на себя. Писать SDK вокруг такого подхода проще нежели вокруг той или иной имплементации REST, ведь реализация зависит от того, как это видел автор. Кроме того, теперь никто не вызовет случайное срабатывание alert в мониторинге из-за того, что выбрал неудачный код ошибки.

Но неудобства тоже есть:

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

При использовании средств отладки (Chrome DevTools) или других подобных инструментов вы не сможете быстро найти ошибочные запросы бизнес логики, придется обязательно заглянуть в тело ответа (ведь всегда 200)

Мониторинг теперь точно будет срабатывать только на ошибки транспорта, а не бизнес-логики, но для мониторинга логики надо будет дописывать парсинг тела сообщения.

В некоторых случаях данный подход вырождается в RPC, то есть по сути вообще отказываются от использования url и шлют все на один url методом POST, а в теле сообщения передают все параметры. Мне кажется это не правильным, ведь url это прекрасный именованный namespace, зачем от этого отказываться, не понятно?! Кроме того, RPC создает проблемы:

нельзя кэшировать по http GET запросы, так как замешали чтение и запись в один метод POST

нельзя делать повторы для неудавшихся GET запросов (на backend) на реверс-прокси (например, nginx) по указанной выше причине

имеются проблемы с документированием – swagger и ApiDoc не подходят, а удобных аналогов я не нашел

Итог: Для сложной бизнес-логики с большим количеством типов ошибок такой подход лучше, чем расплывчатый REST, не зря в проектах c “разухабистой” бизнес-логикой часто именно такой подход и используют.

№3: Смешанный

Возьмем лучшее от двух миров. Мы выберем один http статус, например, 400 или 422 для всех ошибок бизнес-логики, а в теле ответа будем указывать код ошибки или строковую константу. Например:

400 – ошибка бизнес логики

остальное ошибки в транспорте

Тело ответа для удачного запроса у нас имеет произвольную структуру, а вот для ошибки есть четкая схема. Мы избавляемся от избыточности данных (поле ошибки/данных) благодаря использованию http статуса в сравнении со вторым вариантом. Клиентский код упрощается в плане обработки ошибки (в сравнении с первым вариантом). Также мы снижаем его вложенность за счет использования отдельного http статуса для ошибок бизнес логики (в сравнении со вторым вариантом).

Мы можем расширять объект ошибки для детализации проблемы, если хотим. С мониторингом все как во втором варианте, дописывать парсинг придется, но и риска “стрельбы” некорректными alert нету. Для документирования можем спокойно использовать Swagger и ApiDoc. При этом сохраняется удобство использования инструментов разработчика, таких как Chrome DevTools, Postman, Talend API.

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

Самое главное какой бы формат ошибок вы бы не выбрали лучше обговорить его заранее и следовать ему. Если эту вещь пустить на “самотек”, то очень скоро обработка ошибок в проекте станет невыносимо сложной для всех.

P.S. Иногда ошибки любят передавать массивом

Но это актуально в основном в двух случаях:

Когда наш API выступает в роли сервиса без фронтенда (нет сайта/приложения). Например, сервис платежей.

Когда в API есть url для загрузки какого-нибудь длинного отчета в котором может быть ошибка в каждой строке/колонке. И тогда для пользователя удобнее, чтобы ошибки в приложении сразу показывались все, а не по одной.

В противном случае нет особого смысла закладываться сразу на массив ошибок, потому что базовая валидация данных должна происходить на клиенте, зато код упрощается как на сервере, так и на клиенте. А user-experience хакеров, лезущих напрямую в наше API, не должен нас волновать?HTTP

Источник