Идентификатор запроса не указан. Операция «Запрос на получение результата запроса на получение выписки по юридическому лицу по полученному ранее идентификатору запроса

Общие сведения

Описание входных параметров

Входные данные: XML документ по схеме WS_ULIPZAPRID_2_311_11_04_0 2 _01_01.XSD

1. Описание выходных параметров

Выходные данные: XML документ по схемеWS_OTVVIPULXSD_2_311_14_04_02_01.XSD

или

Выходные данные: XML документ по схеме WS_ULIPOTVID_2_311_09_04_02_01.XSD

Параметры комплексного типа описаны в приложении «Описание общих структур данных» (в пунктах 10, 6, 9).

1. Коды возвратов

№	Код возврата	Описание кода возврата	Условия возникновения	Комментарий
1	01	Запрашиваемые сведения не найдены	Возникает при условии, что сведения о ЮЛ не найдены в ЕГРЮЛ
2	51	Запрос принят в обработку	Возникает в случае успешного приема запроса в обработку
3	52	Ответ не готов	Возникает в случае неготовности ответа по успешно принятому в обработку запросу	Используется при асинхронном запросе
4	53	Сведения в отношении юридического лица/индивидуального предпринимателя не могут быть предоставлены в электронном виде	Возникает при невозможности сформировать ответ на запрос электронном виде
5	82	Ошибка форматно-логического контроля	Возникает при условии несоответствия документа (запроса) xsd-схеме	Резерв, может не использоваться
6	83	Отсутствует запрос с указанным идентификатором запроса и видом запрошенных сведений от данного органа	Возникает в ситуации, когда в запросе на получение результата на запрос выписки по ЮЛ указан некорректный (неизвестный) идентификатор запроса и (или) запрос с таким идентификатором не поступал от данного органа	Используется при асинхронном запросе (при получении результата запроса выписки по ЮЛ)
9	99	Системная ошибка	Возникает при наличии внутренних ошибок в ПО ИС ФНС России

1. Контрольные примеры

Запрос на получение результата запроса на получение выписки по ЮЛ

Ответ на запрос на получение результата запроса на получение выписки по ЮЛ, в случае, запрос ещё не обработан

Ответ на запрос на получение результата запроса на получение выписки по ЮЛ с кодом возврата 53

Ответ на запрос на получение результата запроса на получение выписки по ЮЛ с ошибкой (код обработки которой не зарезервирован)
(меняются значения атрибутов и)

Примечание: условия возникновения данной ошибки в тестовой среде были инициированы искусственно. Данный пример описывает общую логику и структуру ответа с ошибкой. При проведении испытаний на продуктивной среде возврат точно такого же ответа без обеспечения необходимых условий не возможен.

1. Интерфейс должен принимать запросы по протоколу HTTPS с IP-адресов подсетей:
   • 79.142.16.0, маска 255.255.240.0 (20)
   • 91.232.230.0, маска 255.255.254.0 (23)
2. Интерфейс должен обрабатывать параметры, передаваемые системой методом HTTP GET.
3. Интерфейс должен формировать ответ системе в формате XML в кодировке UTF-8.
4. Обмен информацией ведется в режиме “запрос-ответ”, при этом скорость ответа не должна превышать 60 секунд, в противном случае система разрывает соединение по таймауту.
5. Если предполагаемое количество платежей за услуги подключаемого провайдера, ожидается интенсивным (до 10 платежей в минуту и более), необходимо, чтобы интерфейс поддерживал многопоточную коммуникацию до 10-15 одновременных соединений.
6. Интерфейс должен принимать запросы по протоколу HTTPS на один из следующих TCP-портов: 80, 81, 443, 8008, 8080, 8081, 8090, 8443, 4433. Использование иных портов не допускается.

Основные принципы работы интерфейса

Все запросы передаются методом GET, параметры передаются в пути запроса.

Передача информации о платеже провайдеру производится системой QIWI Wallet в два этапа – проверка статуса абонента и непосредственно проведение платежа. Также может добавляться предварительный этап получения дополнительных параметров платежа от провайдера, предоставляющего абоненту несколько сервисов, для информирования плательщика и добавления параметров платежа по выбору плательщика.

Тип запроса передается системой QIWI Wallet в переменной command – строка, принимающая значения check , pay или getInfo:

Параметры запросов

Все параметры обязательны в тех запросах, в которых они используются.

Параметр	Формат	Описание	В каких запросах используется
txn_id	Целое число длиной до 20 знаков	Уникальный идентификатор платежа в системе QIWI. По этому идентификатору производится и решение спорных вопросов.	check , pay
sum	Дробное число с точностью до сотых, в качестве разделителя используется. (точка). Если сумма представляет целое число, то оно все равно дополняется точкой и нулями, например – 152.00 .	Сумма платежа	check , pay
ccy	Код валюты Alpha-3 ISO 4217	Валюта платежа	check , pay
txn_date	ГГГГММДДЧЧММСС	Дата платежа (под датой платежа в системе подразумевается дата получения запроса от клиента). По этой дате производится дальнейшая сверка взаиморасчётов между QIWI Wallet и провайдером. Например, клиент отправил запрос в систему QIWI Wallet 31.12.2010 в 23:59:59, и система QIWI Wallet отправила свой запрос провайдеру 01.01.2011 в 00:00:05. Это может привести к проблеме сверки платежей, если система провайдера поместит транзакцию в следующий расчётный период. Чтобы избежать подобных проблем, QIWI Wallet предоставляет провайдеру оригинальную дату платежа.	pay
account	Строка, содержащая буквы, цифры и спецсимволы, длиной до 200 символов	Идентификатор абонента. Провайдер идентифицирует своего абонента по уникальному идентификатору (номер лицевого счета, телефона, логин и т.д.). Перед отправкой провайдеру, идентификатор проходит проверку корректности в соответствии с регулярным выражением, которое .	check , pay , getInfo
extra	Допустимыми являются цифры (0-9), подчёркивание (_) и строчные буквы латинского алфавита (a-z)	Дополнительные реквизиты платежа (экстра поля). Данные параметры могут быть использованы в случае, если платёж невозможно провести без дополнительных данных (одного идентификатора пользователя в системе провайдера недостаточно). Например, идентификатор пользователя – номер кредитной карты, но для проведения платежа также нужно указать срок действия карты. Перечень необходимых полей для передачи провайдеру необходимо указывать в .	check , pay
prvId	Целое число	Идентификатор сервиса в общей системе провайдера.	getInfo
parameter_name	Формат имени и значения параметров указывается провайдером в .	Дополнительные параметры для идентификации абонента	getInfo

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

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

Формат ответа

Провайдер должен вернуть ответ на запросы системе в формате XML. Общая структура ответа приведена на вкладке справа.

123323498 12369Bdkjh9 100.00 643 2012-04-05T12:00:07 0

В случае если любой из запросов провайдеру завершается ошибкой, то провайдер возвращает код ошибки в соответствии с .

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

В ответе могут присутствовать следующие теги:

Например, имеет место ситуация: клиент прислал в систему запрос 31.12.2010 в 23:59:59. Учитывая задержку на обработку данных и пересылку информации по каналам связи, провайдером платеж будет получен 1.01.2011 00:00:05 и, соответственно, учтен в системе провайдера в другом отчетном периоде. Чтобы при проведении сверок проблем с разными отчетными периодами не возникало, необходимо, чтобы провайдер возвращал дату, по которой производится учет в его системе.

Пример запроса на проверку состояния счета абонента и регистрацию платежа

Условия примера:

Платежное приложение провайдера payment_app располагается по адресу yourservice.prv.ru , сервер поддерживает HTTPS соединения по порту 8443.

Для проверки состояния абонента система QIWI Wallet генерирует запрос (см. вкладку справа).

GET /payment_app?command=check&txn_id=1234567& account=4957835959&sum=10.45&ccy=RUB 1234567 2016AB 10.45 RUB 0 OK

Запрос содержит параметры:

• command=check – идентификатор запроса на проверку состояния абонента;

Успешный ответ провайдера (см. вкладку справа).

Возвращение result=0 на запрос check свидетельствует о том, что лицевой счет абонента с соответствующим ему номером в поле account может быть пополнен на сумму, указанную в запросе в поле sum . После успешной проверки состояния счета абонента система переходит к формированию и отправке запроса на пополнение баланса (запрос pay).

Пример запроса на пополнение лицевого счета

Условия примера:

Для подтверждения платежа система QIWI Wallet генерирует запрос (см. вкладку справа).

GET /payment_app?command=pay&txn_id=1234567& txn_date=20110815120133&account=4957835959&sum=10.45&ccy=RUB HTTP / 1.1 Host : yourservice.prv.ru:8443 Ответ провайдера 1234567 2016AB 10.45 RUB 0 OK 2011-08-15T12:06:45

Запрос содержит параметры:

• command=pay – идентификатор запроса на пополнение баланса абонента;
• txn_id=1234567 – внутренний номер платежа в системе QIWI;
• txn_date=20090815120133 – дата учета платежа в системе QIWI;
• account=4957835959 – идентификатор абонента в информационной системе провайдера;
• sum=10.45 – сумма к зачислению на лицевой счет абонента;
• ccy=RUB – валюта суммы зачисления на лицевой счет абонента.

Возвращая result=0 на запрос pay , провайдер сообщает об успешном завершении операции пополнения баланса. Система полностью завершает обработку данной транзакции.

В необязательном поле comment содержится служебный комментарий.

Пример запроса на получение дополнительных данных платежа

Условия примера:

Платежное приложение провайдера payment_app располагается по адресу yourservice.prv.ru , сервер поддерживает HTTPS соединения на порт 8443.

Для получения дополнительных данных платежа система QIWI Wallet генерирует запрос (см. вкладку справа).

GET /payment_app?command=getInfo&prvId=12345& account=4957835959&name1=%26%30AB&name2=0 HTTP / 1.1 Host : yourservice.prv.ru:8443 Ответ провайдера account1 term2 0 OK

Запрос содержит параметры:

• command=getInfo – идентификатор запрос на получение дополнительных данных платежа для абонента;
• prvId=12345 – идентификатор для определения сервиса провайдера;
• account=4957835959 – идентификатор абонента в информационной системе провайдера;
• name1 , name2 – дополнительные идентификаторы абонента.

Ответ провайдера см. на вкладке справа.

Возвращение result=0 на запрос getInfo свидетельствует о том, что запрос выполнен успешно и дополнительные данные для отображения абоненту получены.

В необязательном поле comment содержится служебный комментарий.

Ежедневная сверка

До 10:00 по московскому времени система генерирует и отправляет по указанному адресу электронный реестр принятых платежей за предыдущий день.

Реестр имеет следующую структуру:

Transaction date (Moscow);Report date;Type;Transaction number;Transaction currency ID;Transaction amount;Merchant"s comment;Merchant"s transaction/invoice number;Invoice date of issue;QW ID;Account;Refund ID

;;Payment;;;;;;;;;

;;Payment;;;;;;;;;

Поля разделены знаком; , дробная часть суммы отделена точкой, дата/время – Московские, перевод строки может состоять как из символов x0D x0A, так и просто из x0D.

Например:

31.02.2005 00:04:00;31.02.2005

00:00:00;Payment;3464968222;USD;5.00;;;;;0957835959;;

31.02.2005 00:04:00;31.02.2005 00:00:00;Payment;3464968912;RUB;10.34;;;;;[email protected];;

31.02.2005 00:11:00;31.02.2005 00:00:00;Payment;3464974548;EUR;4.72;;;;;ABC-12345;;

Система включает в реестр только успешно проведенные платежи.

Подтвержденными считаются платежи, которые пришли как при online обмене сообщениями, так и в реестре.

Если в реестре отсутствуют платежи, которые проведены в базе провайдера, или содержатся платежи, которых нет в базе провайдера, или при неполучении реестра необходимо связаться с контактным лицом QIWI, указанным в договоре, до 12:00 для выяснения ситуации и принятия решения.

Дополнительные возможности авторизации запросов

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

Эти авторизационные данные передаются по стандартным правилам basic-аутентификации при запросах по HTTP(S). К запросу добавляется HTTP-заголовок Authorization . В заголовке указывается строка Basic (с пробелом на конце) и пара “логин:пароль”, закодированная в BASE64:

Authorization: Basic ***

BASE64("Login:Password") = "***"

Заявка на подключение (образец)

Список кодов завершения

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

Знак + в столбце “фатальность” указывает на признак фатальности ошибки. Для системы QIWI Wallet фатальная ошибка означает, что повторная отправка запроса с теми же параметрами приведет к 100% повторению той же ошибки – следовательно, система прекращает обработку клиентского запроса и завершает его с ошибкой.

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

Отсутствие связи с сервером провайдера является нефатальной ошибкой.

Отсутствие в ответе элемента (некорректный XML, страница Service temporarily unavailable и т.д.) также является нефатальной ошибкой.

Код

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

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

Проекту необходимы:

• URL проверки идентификатора или заказа пользователя (указать в Технических настройках в Личном кабинете);
• Обработчик, способный принять и распознать параметры запроса от Системы и ответить так, как того ожидает Система.

Если проверка идентификатора после выставления счёта завершилась с ошибкой, то счёт выставлен не будет, а пользователь переадресуется на страницу ошибки платежа, указанную проектом с помощью параметра return_url_fail или в Технических настройках (если страница не указана - используется аналогичная на стороне Системы). На страницу ошибки платежа методом GET автоматически отправляется параметр err_msg со значением « Такого персонажа не существует» .

Параметры запроса от Системы в Проект

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

• метод передачи - POST ;
• кодировка - UTF-8 .

Параметр	Описание параметра	Формат параметра	Обязательность параметра
userid	Идентификатор пользователя или заказа (равен значению параметра nickname в )	string(256)	Да
userid_extra	Дополнительные сведения, необходимые для совершения платежа или сбора статистики на стороне Проекта (равен значению параметра nick_extra )	string(500)	Нет
key	Контрольная подпись запроса. Формируется как хэш по алгоритму md5 от конкатенации следующих параметров: значение параметра userid , секретный ключ проекта	md5(0userid0секрет проекта)	Да
amount		0	Да
paymentid	Проверка check запроса. Принимает только нулевое значение (amount = 0)	0	Да
orderid	Идентификатор платежа в учётной системе Проекта (равен значению параметра order_id в )	varchar(64)	Нет

Параметры ответа Проекта

На запрос Системы от Проекта должен приходить ответ.

Для передачи параметров запроса используются следующие правила:

• формат - XML ;
• кодировка - UTF-8 .

Параметр	Описание параметра	Формат параметра	Обязательность параметра
code	Код ответа на запрос. YES - идентификатор существует. NO - идентификатор не существует	(регистрозависимый)	Да
comment	Расшифровка кода ответа на запрос. Примеры текста: не прошла валидация по параметру userid; не прошла валидация по параметру orderid; не прошла валидация по параметру key	string(400)	Нет

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

YES

Пример минимального обработчика запросов Системы при проверке идентификатора пользователя или заказа

//Генерация ответа function sendResponse($status, $message = ""){ $response = ""."\n"; $response .= ""."\n"; $response .= "".$status.""."\n"; $response .= "".$message.""."\n"; $response .= ""; die($response); } //Проверка существования идентификатора пользователя или заказа function checkUser($userID){ $sql = "SELECT login FROM users WHERE usr_id = ".intval($userID); $query = mysql_query($sql); if(mysql_error()){ return FALSE; } if(mysql_num_rows($query) == 0){ return FALSE; } return TRUE; } $secretKey = "IT\"S_A_PROJECT_SECRET_WORD"; $projectHash = md5($_POST["amount"].$_POST["userid"].$_POST["paymentid"].$secretKey); if($projectHash != $_POST["key"]){ sendResponse("NO", "Контрольная подпись запроса неверна."); } if(floatval($_POST["amount"]) == 0 && intval($_POST["paymentid"]) == 0){ //Запрос на проверку идентификатора пользователя или заказа if(checkUser($_POST["userid"])){ sendResponse("YES", "Идентификатор существует"); } else{ sendResponse("NO", "Идентификатор не найден"); } }

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

Что представляет собой уникальный идентификатор?

Уникальный идентификатор платежа - это 20-значный код, который необходимо указывать при погашении задолженности по налогам в Это дает возможность беспрепятственно и быстро заплатить налоги из личного кабинета на сайте налоговой службы. Такой подход значительно упрощает и ускоряет процедуру проведения операции. Оплата происходит быстро, а значит, своевременно, что позволяет избежать задержек, а значит, штрафных санкций и пеней.

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

Для чего он нужен?

Он нужен для того, чтобы в ФНС знали, когда и от какого лица поступили деньги на счет. В ГИС зарегистрированы миллионы пользователей, определить, от кого и на какие цели переводятся деньги, сложно. Именно поэтому приказом МинФина №107н от 12.11.13 года были изменены правила, в соответствии с которыми появился отдельный для налогов уникальный идентификатор платежей начисления.

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

Кто его должен указывать?

Указывать уникальный идентификатор платежей могут как простые граждане, предприниматели (физические лица), так и юридические лица. Делать это можно при уплате налогов непосредственно в кабинете информационной системы или через банк. При переводе следует учитывать, что платеж через Сбербанк имеет свои особенности. Они имеют свою особую форму, при заполнении которой уникальный идентификатор не надо указывать. УИН указывается при оплате налогов, госпошлин через сервис "Госуслуги" или отделение банка.

Если физическое или юридическое лицо заполняет платежные документы на уплату налогов и сборов, срок уплаты которых еще не истек, то оно может не вписывать уникальный идентификатор, а в сроке ввода реквизита вставить нуль. Хотя законом такой способ заполнения строки допускается, при оплате через банк служащий может потребовать заполнения строки 20-значным номером платежа и вправе отказаться принять платеж. Поэтому важно знать, в каких случаях его надо указывать, а в каких это не обязательно.

В каких случаях его необходимо указывать?

Следует заметить, что идентификатор не всегда нужно указывать, а только в определенных случаях, которые описаны в правилах и положениях Банка России (в частности, положение №383-П). УИН - уникальный идентификатор указывается в двух случаях:

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

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

Где и как можно получить идентификатор?

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

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

Как правильно заполнить?

При уплате налогоплательщиками платежей в бюджетную систему РФ заполняют платежное поручение. В нем помимо уникального идентификатора предприниматель должен указать:

• БИК того учреждения, через который будет осуществлен платеж;
• наименование банка, его юридический адрес;
• расчетный счет, с которого будет производиться перевод;
• вид оплаты (код);
• дата проведения операции.

Номер вводят в строку уникального идентификатора платежа - 22 (код поля). Не заполняют только в том случае, если платеж происходит своевременно. В таком случае в этой строке проставляют «0» (ноль).

Что делать, если документ уже содержит УИН?

Иногда, особенно при осуществлении платежей через специализированные информационные системы, при заполнении поручения в электронном виде в строке (ее код 22) уникальный идентификатор платежа появляется сам. Как к этому отнестись? Считать ли это ошибкой, если денежные средства вносятся своевременно? На самом деле никакой ошибки нет. Можно оплатить как с указанием номера идентификатора, так и проставив в строке «0». Просто идентификатор требуют указать при просрочке платежа, то есть по требованию налоговой.

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

Но даже если не удалось узнать и указать в поручении идентификатор, это не дает право банкам отказываться принимать его. Банк обязан принять и перевести средства, даже если не указан УИП (уникальный идентификатор платежа). Правило это прописано в официальных документах налоговой службы. В нем вполне ясно указано, что физическому или юридическому лицу достаточно указать свой ИНН, а в строке (код 22) уникального идентификатора платежа вписать «0». В таком случае банк не имеет права отказаться от перевода платежа. Но предприниматель должен учитывать, что в случае ошибки или задержки банк ответственности не несет.

Что означает код: расшифровки идентификатора

Идентификатор расшифровывается следующим образом:

1. Числа с 1 по 3 обозначают код налогового подразделения, в который поступят средства.
2. Цифра 4 обозначает вид платежа. На этом месте всегда стоит нуль.
3. Числа с 5 по 19. Обозначают код документа в системе налогообложения. Каждому плательщику присваивается свой особенный код, основанный на прежней версии индекса документа.
4. Цифра 20. По ее номеру определяется, каким государственным органом власти осуществляется проверка платежа. Рассчитывается с учетом остальных 19 цифр кода.

Уникальный идентификатор платежа идентичен индексу документа только в случае, если индекс состоит из 20 цифр.

Что будет, если его не указать?

По номеру УИН производится учет налогов и прочих платежей в бюджет автоматически. Информация о платежах в бюджет передается в единую базу данных. Если указать неверный код или не указать его, то система не распознает платеж, и деньги не будут переведены. Это чревато такими неприятностями, как:

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

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

Какие документы нужны для получения идентификатора?

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

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

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