После отказа хочется сразу поправить пару формулировок и отправить заявление ещё раз. Но одинаковое слово «отказ» может скрывать разные ситуации: проблемы регистрации заявления, несоответствие требованиям или недостаточные доказательства по конкретному критерию. Исправлять их одним способом бесполезно.
Мы в GLS Expert начинаем с полного решения и экспертного заключения. Нужны точное основание, версия поданного комплекта и факты, которые проверяли эксперты. Пересказ «не понравилось описание» не позволяет понять, что действительно нужно менять.
Разделите замечание и его причину
Правила ведения реестра утверждены постановлением Правительства №1236. Официальный реестр содержит разделы с документами и порядком рассмотрения. Документы реестра российского ПО.
| Что написано в замечании | Что проверяем в компании | Какое исправление может понадобиться |
|---|---|---|
| Не подтверждены права | Цепочку от авторов и подрядчиков до правообладателя | Недостающие документы или устранение реального разрыва прав |
| Не подтверждён функционал | Версию продукта и доступные сценарии проверки | Доступ к рабочей версии и воспроизводимое описание функций |
| Расходятся сведения | Заявление, сайт, документы и фактическую архитектуру | Одинаковые достоверные сведения во всём комплекте |
| Не соблюдено условие допуска | Юридическую структуру и применимый пункт правил | Изменение фактического положения, если оно возможно |
Одной редактурой текста нельзя исправить отсутствующее право или функцию, которой в продукте нет. И наоборот, существующая функция может остаться недоказанной, если эксперт не смог её воспроизвести.
Пример: функция есть, но её не видно
Предположим, разработчик заявляет автоматическое распределение заявок. В демонстрационной версии кнопка доступна только администратору, а эксперту передали учётную запись оператора. Скриншот из презентации не решает проблему доступа.
Для исправления мы проверяем конкретную версию, роль пользователя, входные данные и последовательность действий. Затем описываем наблюдаемый результат: заявка с такими параметрами попадает в такую очередь по указанному правилу. При этом не передаём реальные клиентские данные. Демонстрационный набор должен быть безопасным и достаточным для проверки.
Практический критерий качества: человек, который не участвовал в разработке, способен пройти инструкцию и получить заявленный результат. Если ему приходится звонить программисту после каждого шага, комплект ещё требует доработки.
Когда повторная подача требует особой осторожности
Подпункт «б» пункта 15 Правил №1236 предусматривает проверку определённых прежних решений в отношении того же заявителя и того же программного обеспечения, связанных с подложными документами или недостоверными сведениями. Для применения ограничения за предшествующие 12 месяцев нужно сопоставить конкретное основание решения с отсылками к пунктам 27 и 33 в действующей редакции Правил. Это не универсальный запрет на год после любого отказа. Основание своего решения нужно читать буквально и сопоставлять с действующей редакцией правил. Порядок на сайте реестра.
Не меняйте правообладателя или название продукта только ради обхода причины отказа. Такие действия не устраняют фактическую проблему и могут создать новые противоречия. Если решение кажется ошибочным, отдельно оценивается процедура его оспаривания и сроки по документам компании и с юридическим разбором.
Как собрать повторную редакцию
- Зафиксировать все замечания и ответственного за каждое: юрист, разработчик, бухгалтер или руководитель.
- Отделить уже существующие доказательства от работ, которые ещё предстоит выполнить.
- Проверить цепочку прав, состав продукта, ограничения сторонних компонентов и сведения на сайте.
- Подготовить проверяемую демонстрацию и согласовать название и версию во всех документах.
- Сравнить новую редакцию со старой: что исправлено, чем подтверждено и какие замечания остаются.
Срок подготовки зависит от причины. Найти потерянный акт и оформить права на разработку, которая юридически осталась у подрядчика, требуют разных усилий. Поэтому обещать фиксированные «три дня до повторной подачи» без изучения решения было бы необоснованно.
Мы помогаем превратить перечень замечаний в конкретный план исправлений и связный комплект. Начать стоит с решения об отказе и той версии заявления, которую рассматривали. Обсудить повторную подачу в реестр ПО. Вопросы происхождения продукта подробно разбираем в статье о правах на разработку.
