Поиск Написать

Архитектура нового сервиса ФНС



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

Я решил испытать этот сервис на себе, и вот, как это выглядит при ближайшем и более внимательном рассмотрении.

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

Полученные результаты

1. Адрес ЮЛ. При внесении сведений об адресе ЮЛ (вносил адрес своего офиса из договора аренды: СПб, пр.Стачек, дом 72) сервисная проверка указала, что по этому адресу зарегистрировано 17 ЮЛ, и попросила либо исправить адрес, либо подтвердить правильность внесённых сведений.

При "подтверждении" можно было идти дальше, а при исправлении обнаружилось следующее. Какой бы номер помещения я бы ни вводил, даже самый невероятный, на нём всё равно было зарегистрировано 17 ЮЛ. Что с номером помещения, что без него. Зато, когда я указал Литер (которого в моём договоре аренды нет и которого нет вообще в природе) проверка не обнаружила по этому адресу ни одного зарегистрированного ЮЛ и пропустила дальше без лишних вопросов.

Зато в подготовленных сервисом документах, а именно в Решении и Уставе (для ООО с одним учредителем "новое") обнаружились расхождения.

Если в Уставе, действительно, было указано место нахождения общества:

1.3. Место нахождения Общества: Г.САНКТ-ПЕТЕРБУРГ;

то в Решении под видом места нахождения Общества был указан его адрес:

3. Место нахождения Общества: 198188, ПР-КТ СТАЧЕК, Д. 72, Г.САНКТ-ПЕТЕРБУРГ;

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

2. Учредители. При внесении сведений для подготовки заявления Р11001, я, как уже указал, использовал только свои ПДн. Интерфейс не смутило что все три учредителя и два ЕИО имеют одни и те же ФИО, ИНН и ПДн. Проверка прошла успешно. В форме, в полном соответствии с абз.3 п.2.20.4 Требований к оформлению документов, в листах "Н" (на заявителей), в связи с тем, что ФИО заявителей полностью совпадали, были заполнены также и пункты 4.3 (дата и место рождения). То, что и эти пункты полностью совпадали у всех трёх заявителей-учредителей программу не смутило.

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

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

3. ЕИО. При переносе при помощи сервиса ПДн учредителя в ПДн ЕИО обнаружилась некорректность в переносе дат (рождения и выдачи паспорта). Они переносятся не в формате ДД.ММ.ГГГГ, как отражаются в соответствующем поле, а в формате ДД.ММ.ГГГГ ЧЧ:ММ:СС. Из-за чего программа воспринимает их как ошибочные. Исправить легко – достаточно кликнуть мышкой по подсвеченной жёлтым дате, и она побелеет (исправится). Но так, мне кажется, быть не должно. Может лучше это всё-таки в программе исправить?

Выявлена и более серьёзная проблема с ЕИО у сервиса для подготовки документов для ООО с единственным учредителем ФЛ. Этот сервис в Решении и форме Р11001 наименование должности указывает такое же, какое ввёл пользователь, а в уставе ЕИО всегда именуется "генеральный директор".

4. Уставный капитал. При заполнении сведений об уставном капитале ООО пользователю предлагается осуществить выбор объекта, сведения о котором он собирается заполнить: 1) Уставный капитал, 2) Складочный капитал, 3) Уставный фонд, 4) Паевой фонд. Причём механизм выбора активен (работает) и та позиция, которая будет выбрана, будет указана и в заявлении на регистрацию ООО. Для объективности, следует сказать, что при переходе на страницу сервиса со сведениями об уставном капитале и долях учредителей по умолчанию выбран Уставный капитал. Может, потому, что он стоит первым в списке? А где же "защита от дурака"? Зачем для ООО вообще пользователю предлагать подобный выбор?

Некоторые затруднения сервис испытывал, когда размер уставного капитала указывался, например, так: "10000.". Если же указать "10000" или "10000.0", то проблем у сервиса с пониманием введённого пользователем размера уставного капитала не возникало.

Ещё одна обнаруженная забавность. Если размер уставного капитала указать = 9999.9999, то сервис далее не пропустит, указав, что это менее 10000 и будет абсолютно прав. Если же указать, например, = 99999.9999, то сервис всё пропустит, а в Решении и в Уставе укажет размер уставного капитала = 100000 руб. 00 коп. При этом в заявлении Р11001 будет указано = 99999.9999.

Таким образом, мы увидели, что 1) сервис умеет округлять по правилам округления и 2) сервис округляет размер уставного капитала в Решении и в Уставе до двух знаков после запятой, т.е. до целых копеек. А хорошо это или плохо? То, что умеет округлять, наверное, хорошо. А, вот, то, что округляет, однозначно плохо. Не дело сервиса менять размер уставного капитала чужого общества. Это дело учредителя, а не машины.

Да и в соответствии с п.1 ст.14 14-ФЗ размер уставного капитала всё же определяется в рублях, а не в рублях и копейках. Правда, на указанной страничке интерфейса про размерность уставного капитала ничего не указано, зато указано, как я понял, про размерность номинальных стоимостей долей – "руб.". Правда, почему то здесь номинальная стоимость доли названа Сумма (руб.). Может, из-за нехватки места в таблице?

5. Доли учредителей. Сервис для заполнения сведений о долях учредителей сначала предлагает выбрать формат определения размера доли: Проценты (%), Десятичная дробь (ДД), Простая дробь (ПД). Причём, указанные размеры долей учредителей в разных форматах ни как не коррелируют между собой.

Так, например, для трёх учредителей (как в моём случае) можно в формате "Проценты" указать: 20% 30% и 50%. При выборе же другого формата определения размера доли (при введённых уже ранее значениях размеров долей в процентах) сервис не покажет, например, в десятичных дробях, как представлялось бы разумным размеры: 0.2 0.3 и 0.5, а в простых дробях: 1/5 3/10 и 1/2. Вместо этого поля с размерами долей будут пустыми. И их можно заполнить любыми значениями. Например, %: 20% 30% и 50%, ДД: 0.1 0.2 и 0.7. и ПД: 1/3 1/3 и 1/3. И сервис зачем-то всё это запомнит. Причём, запомнит без лишних вопросов. После чего, при изменении формата определения размера доли, например, с % на ДД или ПД, сервис будет показывать сохранённые значения размеров (разные, которые сам запомнил), а "Суммы (руб.)" – те, что справа (т.е. номинальные стоимости долей), при изменении формата изменяться не будут.

И сервис всё это пропустит и отразит в форме Р11001. Размеры долей будут меняться, в зависимости от выбранного формата их определения, а номинальные стоимости оставаться неизменными.

Это пока не криминал, а лишь – наблюдение. Но, зачем так сделано? Подловить дурака?

Причём, эти данные по каждому учредителю можно ввести как вручную – все (о "Размере доли" и о "Сумме (руб.)"), так и поручить сервису в зависимости от весённых размеров долей рассчитать Суммы (руб.) – номинальные стоимости долей.

Если воспользоваться этой опцией, то сервис честно всё рассчитает, т.е. выполнит арифметическое действие: умножит внесённый пользователем размер уставного капитала на внесённый пользователем размер доли учредителя и полученное произведение внесёт в поле "Сумма (руб.)" данного учредителя. При этом сервис не будет обеспокоен тем, что, например, пользователем внесены размеры долей не всех учредителей (у которых не внесены – всего лишь помножит на ноль, что всё-таки лучше, чем деление на него), а, если и всех, то при расчёте Сумм (руб.) сервис не станет проверять – равна ли сумма всех размеров долей всех учредителей единице (100%), а сумма всех Сумм (руб.) размеру уставного капитала. Данная проверка будет устроена сервисом позже – при попытке перейти "Далее" на следующую страницу. Тогда он может дальше и не пропустить.

И вот здесь, в алгоритме, который использует указанное выше арифметическое действие, разработчиками этого алгоритма заложена принципиальная ошибка, влекущая все несуразности, которые могут возникнуть при подобном расчёте. Ошибка заключается в нарушении п.2 ст.14 14-ФЗ, а именно, в законе сказано:

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

А разработчики сервиса в алгоритм расчёта, единственного, который производит сервис, волюнтаристски заложили иную формулу:

Номинальная стоимость доли участника общества соответствует произведению размера его доли и уставного капитала общества.

Т.е. перепутаны причина и следствие. На самом деле (как прямо указано в законе), не размер доли во взаимодействии с уставным капиталом порождают её номинальную стоимость, а номинальные стоимости долей образуют (в сумме) уставный капитал и, будучи поделёнными на него, порождают размеры долей, которые выражаются в виде дроби. Иногда (но не всегда!!!) эту дробь можно представить в виде десятичной дроби, при умножении которой на 100 получается представление размера доли в процентах.

Это, примерно, как датчики угловых скоростей установить «вверх ногами» или в полётном задании перепутать локации космодромов. Но, если эти "ошибки" становятся заметны многим, т.к. ракеты, при таком отношении к ним, летают не очень хорошо, то "ошибки" заложенные в алгоритм расчёта долей учредителей/участников менее заметны широкой публике. Обычно, их по телевизору не транслируют. Даже, если у кого-то что-то пойдёт не так.

Из-за указанного отступления от нормы закона возникают, например, следующие (но не все !!!) несуразности.

Если указать размер уставного капитала, например, = 10000, а размер доли каждого из трёх учредителей, например, = 1/3 и попросить сервис рассчитать Суммы (руб.), то в результате этих расчётов Суммы (руб.) у каждого учредителя будут равны = 3333.3333, что в сумме будет = 9999.9999, что не равно 10000 и даже меньше 10000, но сервис подобное пропустит и такие номинальные стоимости долей у каждого учредителя (3333.3333) укажет в форме Р11001.

Если же при всех аналогичных исходных данных Суммы (руб.) указать вручную как 3333.33 или 3333.333 для каждого учредителя, то сервис дальше не пропустит и укажет причину:

Общая сумма долей (в рублях) не сходится с суммой уставного капитала (складочного капитала, уставного фонда, паевого фонда)

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

6. Формы Р11001, генерируемые сервисом, вопросов не вызвали. Правда, они не совсем такие, какие были опубликованы при их утверждении. Но их отличие заключается лишь в несколько иной геометрии расположении знакомест, что, как я понял из практики, в реальной жизни для регистрирующих органов не критично.

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

Так, например в форме Р11001 в листах где указываются данные сведения количество знакомест в Листе В стр.1 п.5.4, Листе Е стр.1 п. 5.4, Листе 3 стр.1 п.5.4 равно 114 (34 в первой строке и по 40 в третей и четвёртой), а в Листе Г стр.3 п.3.2.4.4, Листе Ж стр. 3 п.8.4.4, Листе Н стр.2 п.4.4.4 равно 113 (33 в первой строке и по 40 в третей и четвёртой).

Понимаю, что мелочь. Ведь, точность попадания более 99%! Не ищу смысла, ищу закономерность.

Кажется, было нашёл: 33 знакоместа в первой строке, когда соответствующий пункт расположен в верхней части соответствующей страницы, а 34 – когда в нижней. Однако, в форме Р14001 постигло разочарование. В ней обнаружены исключения: Лист Д стр.1 п.3.5.4 расположен внизу страницы, но содержит в первой строке 33 знакоместа, а Лист М стр.2 п.3.5.4 – вверху и 34 знакоместа.

Каждый из вас может это увидеть, открыв утверждённые формы. Если, конечно, не лень.

Подобные сложности были и тогда, когда М.В.Мишустин своим приказом от 25.01.2012 утвердил новые Формы и Требования по их заполнению. Эти сложности остались и после того, когда он же своим приказом от 25.05.2016 внёс в них изменения.

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

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

Так, в Требованиях в абзаце третьем пункта 1.1 в последней строке образца тридцать третий символ слева изменён с "№" на "N".

Можно ли теперь в формах на регистрацию использовать знак "№"? А если какому-то инспектору не понравится, что в поданной на регистрацию форме такой знак есть, а в Требованиях его нет. И он сочтёт такую представленную на регистрацию форму, формой, не представленной на регистрацию, с последующими для заявителя оргвыводами?

Не смотря на то, что в своё время я принимал посильное участие в разработке "новых-2013" форм, после их принятия, я обнаружил в них не только указанные здесь неожиданности.

Как же сама ФНС относится к некоторым несуразностям ею утверждённых форм? А никак. Она их игнорирует. Для этого она игнорирует и утверждённые ею же Требования по заполнению этих форм.

Так, например, её программа ППДГР, не соблюдает установленные (и не отменённые исключительно для неё) требования к расположению знакомест, к их количеству, к кеглю и кернингу используемого для заполнения форм шрифта.

Интересно, а заявители, которые не используют эту программу, также могут творчески относиться к указанным Требованиям?

Возможно, кто-то сочтёт, что всё это не имеет отношения к новому сервису ФНС. У меня же другие сомнения и выводы.

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

И виновны в этом, отнюдь, не датчики, алгоритмы и карты.

Выводы

1. Типовая форма устава ООО для единственного участника, предлагаемая ФНС, не соответствует законодательству, даже после внесения в неё сведений о размере уставного капитала.

2. Устав и Решение при создании ООО единственным учредителем содержат противоречивую информацию относительно места нахождения создаваемого ООО.

3. Устав и Решение могут содержать сведения о размере уставного капитала, отличающиеся от размера уставного капитала, вносимого сервисом в Форму Р11001.

4. Решение и Р11001 содержат сведения о наименовании должности ЕИО, которое ввёл пользователь. В Уставе всегда будет указан генеральный директор. Только в этом единственном случае они будут совпадать.

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

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

7. В случае, если ООО будет зарегистрировано, это не гарантирует от появления возможных проблем в этом обществе в будущем, из-за некорректно составленных этим сервисом документов.

8. Слово "коррупциогенность" я ни разу, нигде не использовал, несмотря на то, что очень много решений по отказам (или не отказам) в регистрации принимается не в соответствии с действующим законодательством, а по разумению чиновников на местах. Я не ищу здесь злой умысел. Лишь, указываю на тенденцию.

9. В ЦА ФНС хорошо отстроена обратная связь, видна нацеленность на результат, в том числе, и через признание своих ошибок. Но пока не всех.


Подробнее на моём сайте www.ustav.ooo
Редактировано: 19 мая 2019

Комментарии:
 

Подтвердите удаление записи