Главна информация

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

Входни данни: XML документ по схема WS_ULIPZAPRID_2_311_11_04_02 _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	Системна грешка	Възниква, когато има вътрешни грешки в софтуера на IS на Федералната данъчна служба на Русия

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 в командната променлива - низ, който приема стойностите check, pay или getInfo:

Параметри на заявката

Всички параметри са задължителни в заявките, в които се използват.

Параметър	формат	Описание	В какви заявки се използва?
txn_id	Цяло число с дължина до 20 знака	Уникален идентификатор на плащане в системата QIWI. Този идентификатор се използва за разрешаване на спорни проблеми.	проверка, плащане
сума	Като разделител се използва дробно число с точност до стотни. (точка). Ако сумата представлява цяло число, тогава тя все още се допълва с точка и нули, например - 152.00.	Размер на плащането	проверка, плащане
ccy	Alpha-3 ISO 4217 валутен код	Валута на плащане	проверка, плащане
txn_date	ГГГГММДДЧЧММСС	Дата на плащане (датата на плащане в системата означава датата, на която е получена заявката от клиента). Въз основа на тази дата се извършва допълнително съгласуване на взаимните разплащания между QIWI Wallet и доставчика. Например, клиентът изпрати заявка до системата QIWI Wallet на 31.12.2010 г. в 23:59:59, а системата QIWI Wallet изпрати заявката си до доставчика на 01.01.2011 г. в 00:00:05. Това може да доведе до проблем със съгласуването на плащанията, ако системата на доставчика постави транзакцията в следващия период на фактуриране. За да избегне подобни проблеми, QIWI Wallet предоставя на доставчика оригиналната дата на плащане.	заплащане
сметка	Низ, съдържащ букви, цифри и специални символи, с дължина до 200 знака	ID на абонат. Доставчикът идентифицира своя абонат чрез уникален идентификатор (номер на личен акаунт, телефонен номер, вход и др.). Преди да бъде изпратен на доставчика, идентификаторът се валидира според регулярен израз, който .	проверка, плащане, получаване на информация
екстра	Допустимите числа са цифри (0-9), долна черта (_) и малки латински букви (a-z)	Допълнителни данни за плащане (допълнителни полета). Тези параметри могат да се използват, ако плащането не може да се извърши без допълнителни данни (един потребителски идентификатор в системата на доставчика не е достатъчен). Например потребителският идентификатор е номер на кредитна карта, но за да извършите плащане, трябва да посочите и датата на изтичане на картата. Списъкът на задължителните полета, които трябва да бъдат прехвърлени към доставчика, трябва да бъде посочен в	проверка, плащане
prvId	Цяло число	Идентификатор на услугата в общата система на доставчика.	getInfo
име_на_параметър	Форматът на името и стойността на параметрите се определя от доставчика в .	Допълнителни параметри за идентификация на абоната	getInfo

За да се поддържа разширяемостта и да се поддържа функционалността на услугата на доставчика през периода, когато са активирани различни функции, предвидени от протокола (например разрешаване на прехвърлянето на нови данни за плащане), се предполага, че доставчикът не предотвратява появата на нови HTTP параметри в заявката.

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

Формат на отговора

Доставчикът трябва да върне отговора на заявките към системата в XML формат. Общата структура на отговора е показана в раздела вдясно.

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

Ако някоя от заявките към доставчика е неуспешна, доставчикът връща код за грешка в съответствие с .

Информационната система на доставчика не трябва да съдържа две успешно извършени плащания с един и същи txn_id номер. Ако системата изпрати отново заявка с идентификатор txn_id, който вече съществува в информационната система на доставчика, тогава доставчикът трябва да върне резултата от обработката на предишната заявка.

Отговорът може да съдържа следните тагове:

Например, има ситуация: клиентът изпрати заявка до системата на 31.12.2010 г. в 23:59:59. Като се има предвид забавянето при обработката на данни и изпращането на информация чрез комуникационни канали, плащането ще бъде получено от доставчика на 01.01.2011 г. 00:00:05 и съответно ще бъде взето предвид в системата на доставчика в друго отчитане Период. За да се избегнат проблеми с различни периоди на отчитане при извършване на равнения, е необходимо доставчикът да върне датата, на която е извършено счетоводството в своята система.

Пример за заявка за проверка на състоянието на абонатна сметка и регистриране на плащане

Примерни условия:

Приложението за плащане на доставчика payment_app се намира на yourservice.prv.ru, сървърът поддържа HTTPS връзки на порт 8443.

За да проверите състоянието на абоната, системата QIWI Wallet генерира заявка (вижте раздела вдясно).

ВЗЕМЕТЕ /payment_app?command=check&txn_id=1234567& account=4957835959&sum=10.45&ccy=RUB 1234567 2016AB 10.45 RUB 0 Добре

Заявката съдържа параметри:

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

Успешен отговор от доставчика (виж раздела вдясно).

Връщането на резултат = 0 към заявка за проверка показва, че личната сметка на абоната със съответния номер в полето за сметка може да бъде попълнена със сумата, посочена в заявката в полето за сума. След успешна проверка на състоянието на акаунта на абоната, системата преминава към генериране и изпращане на заявка за попълване на баланса (заявка за плащане).

Пример за заявка за попълване на лична сметка

Примерни условия:

За да потвърди плащането, системата QIWI Wallet генерира заявка (вижте раздела вдясно).

ВЗЕМЕТЕ /payment_app?command=pay&txn_id=1234567& txn_date=20110815120133&account=4957835959&sum=10.45&ccy=RUB HTTP / 1.1 Хост: yourservice.prv.ru:8443 Отговор на доставчика 1234567 2016AB 10.45 RUB 0 Добре 2011-08-15T12:06:45

Заявката съдържа параметри:

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

Като връща резултат=0 към заявката за плащане, доставчикът отчита успешното завършване на операцията по попълване на баланса. Системата завършва обработката на тази транзакция.

Незадължителното поле за коментар съдържа коментар за услугата.

Пример за заявка за допълнителни данни за плащане

Примерни условия:

Приложението за плащане на доставчика payment_app се намира на yourservice.prv.ru, сървърът поддържа HTTPS връзки на порт 8443.

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

ВЗЕМЕТЕ /payment_app?command=getInfo&prvId=12345& account=4957835959&name1=%26%30AB&name2=0 HTTP / 1.1 Хост: yourservice.prv.ru:8443 Отговор на доставчика сметка1 термин2 0 Добре

Заявката съдържа параметри:

• command=getInfo – искане на идентификатор за получаване на допълнителни данни за плащане за абоната;
• prvId=12345 – идентификатор за идентифициране на услугата доставчик;
• account=4957835959 – идентификатор на абоната в информационната система на доставчика;
• име1, име2 – допълнителни идентификатори на абонати.

Вижте раздела вдясно за отговора на доставчика.

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

Незадължителното поле за коментар съдържа коментар за услугата.

Ежедневно помирение

Преди 10:00 часа московско време системата генерира и изпраща на посочения адрес електронен регистър на приетите плащания за предходния ден.

Регистърът има следната структура:

Дата на транзакцията (Москва); Дата на отчета; Тип; Номер на транзакцията; ID на валутата на транзакцията; Сума на транзакцията; Коментар на търговеца; Номер на транзакцията/фактурата на търговеца; Дата на издаване на фактурата; QW ID; Акаунт; ID на възстановяване

;;Плащане; ;;;;;;;;

;;Плащане; ;;;;;;;;

Полетата са разделени със знак; , дробната част от сумата е разделена с точка, датата/часът е Москва, захранването на реда може да се състои от знаците x0D x0A или просто x0D.

Например:

31.02.2005 00:04:00;31.02.2005

00:00:00;Плащане;3464968222;USD;5.00;;;;;0957835959;;

02/31/2005 00:04:00;02/31/2005 00:00:00;Плащане;3464968912;RUB;10.34;;;;; [имейл защитен];;

31.02.2005 г. 00:11:00;31.02.2005 г. 00:00:00;Плащане;3464974548;EUR;4,72;;;;;ABC-12345;;

Системата включва само успешно извършени плащания в регистъра.

Плащанията, получени както чрез онлайн съобщения, така и в регистъра, се считат за потвърдени.

Ако регистърът не съдържа плащания, които са извършени в базата данни на доставчика, или съдържа плащания, които не са в базата данни на доставчика, или ако регистърът не е получен, трябва да се свържете с лицето за контакт на QIWI, посочено в споразумението преди 12:00 часа за изясняване на ситуацията и вземане на решение.

Допълнителни опции за оторизация на искане

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

Тези данни за оторизация се предават съгласно стандартните основни правила за удостоверяване за HTTP(S) заявки. Към заявката се добавя HTTP хедър за оторизация. Заглавката съдържа низа Basic (с интервал в края) и двойката „login:password“, кодирана в BASE64:

Оторизация: Основна ***

BASE64("Вход:Парола") = "***"

Заявление за свързване (образец)

Списък с изходни кодове

Когато обработва заявки от системата, доставчикът трябва да съпостави всички грешки, възникнали в неговото приложение, със списъка по-долу и да върне съответните кодове в елемента.

Знакът + в колоната „fatality“ показва, че грешката е фатална. За системата QIWI Wallet фатална грешка означава, че повторното изпращане на заявка със същите параметри ще доведе до 100% повторение на същата грешка - следователно системата спира да обработва клиентската заявка и я завършва с грешка.

Нефатална грешка означава за системата, че повтарянето на заявката със същите параметри след определен период от време вероятно ще доведе до успех. Системата ще повтаря заявки, които са неуспешни с нефатална грешка, като непрекъснато увеличава интервала, докато операцията успее или се провали, или докато изтече 24-часовият живот на заявката.

Липсата на връзка със сървъра на доставчика е нефатална грешка.

Липсата на елемент в отговора (неправилен XML, страница с временно недостъпна услуга и т.н.) също е нефатална грешка.

Код

Проверката се извършва, за да се гарантира, че фактурата и последващото плащане могат да бъдат обработени правилно от страна на проекта.

С опростената интеграция, потребителският идентификатор и поръчката се проверяват два пъти: когато отивате във формата за плащане и когато избирате метод на плащане.

Проектът се нуждае от:

• Потребителско име или URL за потвърждение на поръчката(посочете в Технически настройки във вашия личен акаунт);
• Манипулатор, способен да приема и разпознава параметри на заявка от Системата и да отговаря, както Системата очаква.

Ако проверката на ID след издаване на фактура е неуспешна, тогава фактурата няма да бъде издадена и потребителят ще бъде пренасочен към страницата за грешка при плащане, посочена от проекта с помощта на параметъра return_url_failили в Техническите настройки (ако страницата не е посочена, се използва подобна от страна на Системата). Параметърът автоматично се изпраща на страницата за грешка при плащане с помощта на метода GET err_msgсъс смисъл "Такъв персонаж не съществува".

Изискване на параметри от системата към проекта

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

• метод на прехвърляне - ПУБЛИКУВАНЕ;
• кодиране - UTF-8.

Параметър	Описание на параметъра	Формат на параметъра	Задължителен параметър
потребителски идентификатор	ID на потребител или поръчка (равно на стойността на параметъра псевдоним V )	низ (256)	да
userid_extra	Допълнителна информация, необходима за извършване на плащане или събиране на статистика от страна на проекта (равна на стойността на параметъра nick_extra )	низ (500)	Не
ключ	Подпис за проверка на заявката. Той се формира като хеш с помощта на алгоритъма md5 от конкатенацията на следните параметри: стойност на параметъра потребителски идентификатор, секретен ключ на проекта	md5(0userid0project secret)	да
количество		0	да
плащане id	Проверка на заявката за проверка. Приема само нулева стойност (количество = 0)	0	да
orderid	Идентификационен номер на плащане в счетоводната система на проекта (равен на стойността на параметъра order_id V )	varchar (64)	Не

Опции за отговор на проекта

Искането на Системата от Проекта трябва да получи отговор.

Следните правила се използват за предаване на параметри на заявката:

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

Параметър	Описание на параметъра	Формат на параметъра	Задължителен параметър
код	Код за отговор на заявка. ДА- идентификаторът съществува. НЕ- идентификаторът не съществува	(различаващ главни от малки букви)	да
коментар	Декодиране на кода за отговор на заявката. Текстови примери: параметърът userid не е валидиран; параметърът orderid не е валидиран; неуспешна проверка на ключовия параметър	низ (400)	Не

Примерен отговор на потребителско име или заявка за проверка на поръчка

ДА

Пример за минимален манипулатор на системни заявки при проверка на потребителски идентификатор или поръчка

//Генериране на функция за отговор sendResponse($status, $message = "")( $response = ""."\n"; $response .= " "."\n"; $response .= " ".$състояние.""."\n"; $response .= " ".$съобщение.""."\n"; $response .= ""; die($response); ) //Проверете съществуването на потребителски идентификатор или функция за поръчка checkUser($userID)( $sql = "ИЗБЕРЕТЕ влизане ОТ потребители 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["сума"].$_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("ДА", "Идентификаторът съществува"); ) else( sendResponse("НЕ", "Идентификаторът не е намерен"); ) )

Уникален идентификатор на плащане - какво е това? За какво е? Това са най-честите въпроси, които предприемачите задават, когато плащат данъци в банката, когато банков служител поиска да посочи, това предизвиква объркване. Къде мога да го намеря, как да го взема и мога ли без него? По този начин инструментът, създаден за опростяване на процедурата, доведе до нови проблеми, които трябваше да бъдат изяснени.

Какво е уникален идентификатор?

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

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

За какво е?

Това е необходимо, за да знае Федералната данъчна служба кога и от кое лице са получени парите по сметката. Има милиони потребители, регистрирани в ГИС, трудно е да се определи от кого и за какви цели се превеждат пари. Ето защо със заповед на Министерството на финансите № 107n от 12 ноември 2013 г. правилата бяха променени, според които уникален идентификатор за начислени плащания се появи отделно за данъци.

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

Кой трябва да го посочи?

И обикновените граждани, и предприемачите (физически лица), и юридическите лица могат да посочат уникален идентификатор на плащане. Това може да стане при плащане на данъци директно в сметката на информационната система или чрез банка. Когато прехвърляте, трябва да имате предвид, че плащането чрез Сбербанк има свои собствени характеристики. Те имат свой собствен специален формуляр, при попълването му не е необходимо да се посочва уникален идентификатор. UIN се посочва при плащане на данъци и държавни такси чрез службата за държавни услуги или банков клон.

Ако физическо или юридическо лице попълни платежни документи за плащане на данъци и такси, срокът за плащане на които все още не е изтекъл, тогава той може да не въвежда уникален идентификатор, а да постави нула в датата на падежа за въвеждане на данните. Въпреки че този метод за попълване на реда е разрешен от закона, когато плащате чрез банка, служителят може да изиска попълване на реда с 20-цифрен номер на плащане и има право да откаже да приеме плащането. Затова е важно да се знае в кои случаи трябва да се посочи и в кои не е необходимо.

В какви случаи е необходимо да се посочи?

Трябва да се отбележи, че идентификаторът не винаги трябва да бъде посочен, но само в определени случаи, които са описани в правилата и разпоредбите на Банката на Русия (по-специално наредба № 383-P). UIN - уникален идентификатор се посочва в два случая:

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

Във втория случай повечето данъкоплатци изпитват затруднения, защото не знаят откъде да го вземат и къде да го посочат в документа. Неправилно посочените данни водят до забавяне на плащанията, неустойки и глоби.

Къде и как мога да получа лична карта?

Как мога да разбера информация за уникалния идентификатор на плащането, както и дали плащането е прието? Можете да проверите това както в личния си ГИС акаунт след регистрация в системата, така и при получаване на платежно нареждане при забавени плащания. Но това е краен случай. Предприемачът ще знае номера от документите, показващи наличието на дълг или глоба към данъчните власти.

Ако не е имало просрочени плащания, но трябва да посочите UIN, тогава просто трябва да изпратите заявка до данъчната служба, за да получите номер.

Как да го попълните правилно?

Когато данъкоплатците извършват плащания към бюджетната система на Руската федерация, те попълват платежно нареждане. В допълнение към уникалния идентификатор, предприемачът трябва да посочи:

• BIC на институцията, чрез която ще се извърши плащането;
• наименование на банката, нейния юридически адрес;
• разплащателната сметка, от която ще се извърши преводът;
• вид плащане (код);
• дата на операцията.

Номерът се въвежда в реда на уникалния идентификатор на плащането - 22 (код на полето). Не попълвайте само ако плащането стане навреме. В този случай въведете „0“ (нула) в този ред.

Какво да направите, ако документът вече съдържа UIN?

Понякога, особено при извършване на плащания чрез специализирани информационни системи, при попълване на поръчка по електронен път в реда (кодът му е 22) се появява уникален идентификатор на плащане сам. Как трябва да се чувстваме по този въпрос? Счита ли се това за грешка, ако средствата са депозирани навреме? Всъщност грешка няма. Можете да платите или като посочите идентификационния номер, или като въведете „0“ в реда. Те просто изискват да посочите идентификатора, когато плащането закъснее, тоест при поискване от данъчната служба.

Въпреки че е възможно да се плаща без ограничения, този подход е нежелателен. Предприятието трябва да прави разлика между редовни данъчни плащания и плащания по искане на данъчните власти. Това ще помогне да се избегне объркване при докладването.

Но дори и да не е било възможно да се намери и посочи идентификаторът в поръчката, това не дава право на банките да откажат да го приемат. Банката е длъжна да приема и превежда средства, дори ако UIP (уникален идентификатор на плащане) не е посочен. Това правило е посочено в официални документи на данъчната служба. Там ясно се посочва, че физическо или юридическо лице трябва само да посочи своя TIN и да въведе „0“ в реда (код 22) на уникалния идентификатор на плащането. В този случай банката няма право да откаже превод на плащането. Но предприемачът трябва да вземе предвид, че в случай на грешка или забавяне банката не носи отговорност.

Какво означава кодът: декодиране на идентификатора

Идентификаторът се дешифрира, както следва:

1. Числата от 1 до 3 показват кода на данъчната служба, към която ще бъдат получени средствата.
2. Числото 4 показва вида на плащането. Това място винаги е нула.
3. Числа от 5 до 19. Посочете кода на документа в данъчната система. На всеки платец се присвоява собствен специален код, базиран на предишната версия на индекса на документа.
4. Цифра 20. Нейният номер определя коя държавна агенция проверява плащането. Изчислено, като се вземат предвид останалите 19 цифри от кода.

Уникалният идентификатор на плащането е идентичен с индекса на документа само ако индексът се състои от 20 цифри.

Какво се случва, ако не го посочите?

С помощта на UIN номера автоматично се записват данъци и други плащания към бюджета. Информацията за плащанията към бюджета се прехвърля в единна база данни. Ако въведете грешен код или не го посочите, системата няма да разпознае плащането и парите няма да бъдат преведени. Това е изпълнено с такива проблеми като:

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

Ако бизнесменът няма или не знае уникален идентификатор на плащане откъде да го получи, той може да използва услугата за поддръжка в ГИС по всяко време, вместо да чака данъчните власти да предприемат действия. Ако предприемачът няма достъп до интернет и електронната система на държавните служби, той може да изпрати редовно писмо до най-близката данъчна служба или да се яви лично, за да получи идентификатор.

Какви документи са необходими за получаване на лична карта?

Всичко зависи от формата, в която ще бъде съставен документът и начина на плащане. Ако това е хартиен документ, тогава трябва да изпратите писмено искане до данъчния орган. В писмото посочете вашите паспортни данни, INN и SNILS номер. Уникален идентификатор на плащането ще бъде изпратен в писмо за отговор. Ако юридическо или физическо лице дойде лично в отдела, за да получи тази информация, тогава тези документи трябва да бъдат с него. От тях се изисква да попълнят формуляри.

За да получите подробности по електронен път, първо трябва да се регистрирате в единната информационна система на уебсайта на държавните служби, като посочите същите данни като при писмено искане. След това ще бъде изпратено писмо до мястото ви на пребиваване с ключ за достъп. И едва след това можете да направите заявка за получаване на уникален идентификатор. Обикновено тази услуга се предоставя в рамките на няколко часа след заявката. Не са необходими документи.

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