Тестирование ПО, реализованного в соответствие с требованиями Методических рекомендаций (утвержденных Приказом ФНС России от 02.11.2009 № ММ-7-6/534@) и в новом формате унифицированного транспортного контейнера (утвержденного Приказом ФНС России от 18.12.2009 № ММ-7-6/693@), продолжается.
Практически, тестирование идет уже три месяца.
И хотя оно должно было закончиться для предварительного подведения итогов, еще два месяца назад, тем не менее, хотя бы какое-то промежуточное подведение итогов запланировано на четверг, 22 апреля 2010 года.
Некоторые практические итоги.
Что можно сказать уже сейчас:
Практически, тестирование идет уже три месяца.
И хотя оно должно было закончиться для предварительного подведения итогов, еще два месяца назад, тем не менее, хотя бы какое-то промежуточное подведение итогов запланировано на четверг, 22 апреля 2010 года.
Некоторые практические итоги.
Что можно сказать уже сейчас:
- До настоящего времени новыми методическими рекомендациями охвачен только вопрос представления отчетности. Нормативных документов ФНС по информационному обслуживанию налогоплательщиков, равно как и по не формализованному документообороту нет, как их не было и раньше. Хотя Административный регламент, на основании которого и выполнялась вся работа, содержит нормы для всех трех составляющих.
- Техническая реализация 534/693 приказов разными разработчиками, как и ожидалось, выявила различные трактовки нормативных документов. Согласование разночтений, это одна из целей совещания 22 апреля, однако этот процесс не может пройти безболезненно.
- Во-первых, для крупнейших специализированных операторов связи некоторые трактовки неприемлемы. А это значит, что нас ждет противостояние, вплоть до полного паралича и переноса уровня принятия решений с технических специалистов (рабочая группа под крылом ФНС, в которую включены ГНИВЦ, разработчики ГПР и представители крупнейших спецоператоров) на административный уровень ФНС (где принятие решений отнюдь не очевидно). Это мы уже проходили и, надо сказать, выбор ФНС не всегда предсказуем.
- Во-вторых, устранение этих разночтений, а так же корректировка выявленных ошибок, это внесение изменений в нормативные документы (приказы ФНС), что само по себе процесс не быстрый.
- Нет существенных сдвигов в части ИРУЦ. SOAP-сервис аннотирован и тестируется. Но и аннотация кривая, и тестирование вялое. Хотя лично я альтернативы централизованному средству управления системой не вижу.
- Есть большой объем дополнительных работ, связанных с переходом на новые нормативные документы, которые не согласованы участниками даже по составу, не говоря уже о сроках исполнения и технических подробностях. Значительная часть вины лежит на разработчиках ИРУЦ и ГПР, но предложений по этим работам со стороны тоже не поступало.
- Озвученные на совещании ФНС жесткие сроки перевода налогоплательщиков на единый приемный комплекс (до 01.08.2010 для пяти пилотных регионов, до 01.11.2010 для всех остальных регионов) вызвали, как обычно, перегибы на местах. Кроме лишней нервозности никаких плюсов это не несет.
- Кадровые перемены в высшем руководстве ФНС привели к неопределенности, которую ни кто не берется предсказывать.
- Нас ожидает война нервов вокруг ИРУЦ, связанная как с техническими, так и с организационными проблемами.
- Отладочное тестирование (если только сроки внедрения нового ПО, обозначенные как май 2010 года, не будут перенесены) будет продолжаться практически до момента внедрения, с негарантированным результатом.
- Сам срок внедрения (еще раз напоминаю - май 2010 года), хотя никем и не оспаривается, в силу нерешенности значимых вопросов оказывается весьма условным. Кстати, следующий период, в который можно будет выполнить этот перевод - это ноябрь.
- Переход на новое ПО будет определяться не столько его реальной готовностью к промышленной эксплуатации, сколько политической волей ФНС, что имеет свои плюсы и минусы.
Page Summary
Комментарии
- 3 май 2023, 01:04К слову об ПАБах. Они не только у себя падают через раз, они и в Украине взрываются как у "себя" — то есть тоже, через раз. Что довольно идиотично, потому как я понятия не имею, как надо изговнять…
- 3 май 2023, 00:54Сразу видно, настоящий русский. В историю ни в зуб ногой. Даже беларусов поляками назвал. И эти люди называют войну СВО, ну и понятно, почему так всё хреново идёт, и закончится для рф крайне…
- 2 май 2023, 18:27В операции против Ираке учавствовало 2 тысячи самолетов союзников, которые месяц проводили регулярные вылеты, при том что Ирак — пустыня, все как на ладони.
РФ смогла пригнать только 400 единиц… - 2 май 2023, 16:17К войне с крупным (мобилизационный потенциал несколько миллионов человек, индустриальный тип экономики) неядерным (т.е. против которого в наступлении на его территории нельзя применить ЯО без…
- 2 май 2023, 16:10так ведь и войной нельзя называть то, что невойна как бы?...
Comments
В то же время, все организации, которые посылают отчетность через спецоператоров, проходят процедуру регистрации у самого спецоператора. В такой схеме ИРУЦ занимается простой ретрансляцией того, что сообщит спецоператор, и поэтому выглядит лишним звеном. Всем сторонам придется преодолеть целый ряд сложностей, чтобы система заработала гладко. И конечно, хотелось бы не делать того, что можно не делать. В данном случае, ресурсы всех сторон будут затрачены на отладку регистрации в ИРУЦ. Предложенный интерфейс показывает, что в существующем ИРУЦе есть тяжелое наследие, с которым неизбежно придется считаться (и это вполне стандартная ситуация). Но, блин, раз реальной ценности не видно, то было бы здорово обойти эту задачу и вообще ей не заниматься :)
Степан Унегов
Задача, которую мы сейчас общими усилиями пытаемся решить, стоит так: в инспекциях ФНС должен быть установлен один приемный комплекс, а не набор приемных комплексов различных специализированных операторов связи.
Одной из задач приемного комплекса, не считая транспорта, импорта-экспорта, криптографии и ведения архива юридическизначимых документов, является проверка подлинности отправителя и правомерности применения ЭЦП при подписании документов.
Для определения подлинности абонента и правомерности применения ЭЦП у нас есть только - проверка принадлежности сертификата ключа подписи (СКП). Т.е. на приемном комплексе мы должны иметь возможность определить, что владелец конкретного СКП имеет право подписывать документы, поступающие от конкретного налогоплательщика. Или, формулируя чуть-чуть иначе: отчетность конкретного налогоплательщика может быть подписана конечным числов владельцев СКП.
Однако, сам СКП не содержит достаточно полной информации, позволяющей определить правомочность его применения. Соответственно, нам приходится создавать набор эталонных значений, однозначно связывающих налогоплательщика и владельца СКП. В простейшнм случае, это связка ИНН - отпечаток сертификата.
Для того, чтобы создать набор эталонных значений у нас есть три пути.
Во-первых, мы можем заставить каждого налогоплательщика приходить со своим сертификатом в инспекцию ФНС, предъявлять там свои документы и регистрировать сертификат СКП в БД приемного комплекса.
Во-вторых, мы можем дать возможность специализированным операторам связи регистрировать эту информацию, тем или иным способом, непосредственно в БД приемного комплекса.
В третьих, мы можем вести эту регистрацию централизованно, предоставив специализированным операторам связи доступ к одному или нескольким внешним интерфейсам, но сохранив централизованное управление ключевой информацией внутри системы.
Первый вариант даже обсуждать не хочу. Не смотря на всю его внешнюю простоту, н приведет только к лишней сумтохе и ошибкам, с минимальными возможностями контроля.
Второй вариант нам пытаются последовательно навязать тем или иным способом, главным образом аппелируя к недостаткам ИРУЦ. Практически он легко реализуем. Главным недостатком, с моей точки зрения, является распыление управления комплексом и существенное снижение безопасности.
Третий вариант реализован сейчас.
Давайте рассмотрим его преимущества и недостатки.
Основных недостатков у него два:
1) Будучи единым и централизованным он автоматически превращается в "бутылочное горлышко" работоспособность и производительность которого обеспечивает весь процесс регистрации.
2) Будучи изначально реализован для других целей, он тяжло подается модификациям, обеспечивающим удобство работы с ним в изменившихся условиях.
Но при этом, у него есть и неоспоримые преимущества.
1) ИРУЦ позяволяет развязать интерфейсы приемного комплекса и интерфейсы взаимодействия со спецоператорами и доверенными УЦ. Например, реализация SOAP-сервисов на ИРУЦ не требует изменений в приемном комплексе.
2) ИРУЦ это централизованное эталонное хранилище, которое обеспечит восстановление информации при любых проблемах на местах.
3) ИРУЦ существенно сокращает издержки на администрирование системы.
По третьему пункту привожу два наглядных примера.
1) Некий УЦ потерял статус доверенного. В распределнной системе, закрытие прав доступа на регистрацию заняло бы на порядок больше времени, чем с использованием ИРУЦ, где достаточно отклюить вход данного УЦ в систему.
2) При реорганизации налоговых органов (например присоединении одной инспекции к другой) перенос регистрационной информации обеспечивается администратором ИРУЦ без участия УЦ и спецоператоров.
Не уверен, что приведенной мной информации достаточно, чтобы вас переубедить, но, надеюсь, этого хватит чтобы подискутировать.
Все проблемы, которые Вы описали (проверка полномочий, легкость администрирования, отказоустойчивость), действительно должны быть решены. И я тоже попробую пробежаться по этим проблемам в контексте использования централизованного ресурса.
1. Проверка полномочий. Полная проверка полномочий может быть произведена только на стороне самой инспекции. Для того, чтобы инспектор физически смог этим заниматься, был введен документ "доверенность". ИРУЦ в этом вопросе, к сожалению, помочь не сможет - он ведь не сможет проверить, что доверенность в указанном налоговом органе действительно есть. Все остальное, сверку физического лица с сертификатом и связь сертификата с организацией, проверяется УЦ и спецоператорами. Допускаю, что кому-то интересно посмотреть, какие сертификаты используются для заданного ИНН, но это вопрос сбора информации, но никак не регистрации через единый ресурс.
2. Легкость администрирования. Согласен, что какие-то вещи лучше настраивать ровно в одном месте, нежели организационными мерами распространять по широкой сети получателей. Если УЦ потерял статус доверенного, то закрыть доступ удобно ровно в одном месте. ИРУЦ для этого и нужен. Но этот пример связан с регистрацией ДУЦ/СОС в ИРУЦ, против которого у меня нет возражений, и никак не связан с регистрацией организаций спецоператоров.
Перенос регистрационной информации из-за реорганизации тоже может проводиться с использованием централизованного ресурса, однако, на мой взгляд, это опять же очень слабо связано с процессом регистрации. Я могу регистрировать организации на местах, а переносить их между разными инспекциями через единый роутер.
Если случится страшное и организации не смогут быть перенесены, то это не будет иметь катастрофических последствий. Те же самые организации нарегистрируются на новом месте. Потребуется только дополнительная проверка полномочий, которую никто, кроме сотрудника самой инспекции, провести все равно не сможет.
3. Отказоустойчивость. Это то, чем пренебрегать нельзя. Во-первых, придется вбухать кучу сил (по администрированию в том числе) и средств, чтобы сделать единую точку отказоустойчивой. Во-вторых, если даже представить, что единая точка отказоустойчива, то только ее наличие уже уменьшает отказоустойчивость системы в целом :) Задача регистрации организации в ИРУЦ стала mission critical задачей. Без предварительной регистрации
становится невозможно доставить отчет до обрабатывающего ПО ФНС (до момента, когда можно считать, что налогоплательщик выполнил свою обязанность в срок). Опять же, у меня почти нет соменений, что если централизованный ресурс откажет, то со стороны ФНС будут предприняты действия, чтобы не наказывать ни в чем не повинных налогоплательщиков. Но это будет пустая трата ресурсов, которую, казалось бы, можно исключить заранее и на корню.
Понятно, что я не рассчитываю на изменения, которые требуют кардинальной переработки всех механизмов ИРУЦ-ГПР. А тем более на изменения, которые требуют серьезных доработок приказов - они выглядят вполне работоспособно. Однако у меня есть ощущение, что можно малой кровью отказаться от "узкого горлышка", только в том месте, где оно реально может сыграть по голове, и не отказываться при этом от удобств, связанных с централизованным
администрированием и т.п. Я вообще всеми силами стараюсь не скатиться в обсуждения идеального варианта. Хочется понять, нельзя ли небольшими усилиями уже в ближайшем будущем существенно улучшить систему. Но на этот вопрос кроме Вас, компетентного в нем и идущему на контакт, никто не может ответить :)
Утверждается, что ИРУЦ призван оперативно проводить синхронизацию учетных записей на серверах в случае их потери.
Тем не менее, мы уже были вынуждены отключить один регион, на которром из-за проблем на сервере СОЭД была утеряна часть учетных записей.
В техподдержке ИРУЦ нам было предложено заново вручную отправить данные в обработку!
Вывод:
1. теряем время и ресурсы на дополнительную точку регистрации. Вызываем негатив абонентов, которые привыкли к оперативному подключению к системе сдачи отчетности.
2. нет никакой гаранитии, что успешно зарегистрированные в ИРУЦ данные столь же успешно прописаны на серверах системы.
3. внятного обоснования неоходимости регистации через ИРУЦ для спецоператоров не имеем (ну, кроме необходимот платить зарплату разработчикам данного софта :) )
Вопрос с технической поддержкой в своем ЖЖ решить не могу. Извините.
По вашим выводам:
1) Это не дополнительная точка регистрации, а единственная для применого комплекса ГНИВЦ ПРИЕМ-Регион.
2) Гарантии в этом случае нет ни где и ни у кого. Примеры ошибок и сбоев могу привести по любому спецоператору, даже в пределах его собственного приемного комплекса.
3) Я попробовал обосновать свое мнение чуть выше: http://ivalnick.livejournal.com/169344.html?thread=323456#t323456