Версии ТЗ в ЕИС: как собрать пакет после изменений

Версии ТЗ в ЕИС нужно собирать как новый комплект документов, а не как один замененный файл. После изменений заказчик может обновить описание объекта закупки, инструкцию, проект контракта или приложение с характеристиками. Если тендерный отдел сравнит только дату технического задания, в заявку попадут требования из разных редакций.

Какие документы образуют актуальную версию ТЗ в ЕИС

В закупке по 44-ФЗ извещение связано с набором приложений. Статья 42 относит к ним описание объекта закупки, обоснование цены, требования к содержанию и составу заявки и проект контракта. Состав извещения и приложений установлен статьей 42 44-ФЗ. Поэтому новая версия ТЗ может повлиять на заявку через другой файл, даже если само техническое задание внешне изменилось мало.

Для поставки товара проверяйте минимум следующие части пакета:

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

Статья 33 требует описывать функциональные, технические и качественные характеристики так, чтобы можно было установить соответствие. Она также позволяет устанавливать требования к гарантии, эксплуатации, монтажу, наладке и обучению в предусмотренных случаях. Для новых машин и оборудования действуют отдельные правила о гарантии производителя и (или) поставщика. Проверяемые положения содержатся в статье 33 44-ФЗ. Это еще одна причина сравнивать не только таблицу параметров, но и соседние приложения.

Как разложить версии по папкам

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

Внутри держите простой реестр:

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

Отдельная папка final содержит только материалы, по которым готовится заявка. Ее формируют после сравнения, а не путем копирования всего архива. Черновики коммерческого расчета и старые характеристики туда не попадают.

Как сравнивать изменения в ТЗ

Сначала составьте перечень файлов двух соседних пакетов. Для каждого ответьте: появился, исчез, заменен или остался без изменений. Затем переходите к содержанию.

1. Сравните реквизиты закупки, лот и сроки.
2. Проверьте таблицы характеристик построчно, включая единицы измерения и границы показателей.
3. Сверьте количество, комплектность и места поставки.
4. Найдите изменения в требованиях к участнику и составу заявки.
5. Проверьте проект контракта: приемку, оплату, график, гарантию, монтаж и ответственность.
6. Пересчитайте себестоимость и срок поставки по новой редакции.
7. Обновите матрицу соответствия товара.
8. Зафиксируйте решение: участвуем, запрашиваем разъяснение или отказываемся.

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

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

Не сравнивайте абзацы отдельно от ссылок. Если новая редакция сохранила текст, но сослалась на другую таблицу, стандарт или приложение, фактическое требование могло измениться. Откройте связанный документ и добавьте его в реестр. То же касается фразы «согласно спецификации»: нужно найти именно текущую спецификацию и убедиться, что она относится к нужному лоту.

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

Матрица требований после изменений

Матрица превращает разрозненные правки в список решений. Одна строка соответствует одному проверяемому требованию.

Условный пример. В первой редакции требовалось оборудование с производительностью не менее 80 изделий в час, а после изменения нижняя граница стала 85 изделий в час. Коммерческий отдел уже запросил цену на модель с производительностью ровно 80 изделий в час. В матрице строка получает статус «не соответствует», закупщик запрашивает другую модель, а финансист пересчитывает предложение. Если просто заменить PDF в папке, старая модель останется в заявке.

Матрица должна ссылаться на страницу, пункт или строку источника. Запись «характеристика изменилась» слишком общая. Проверяющему нужны точное место и новое значение.

TenderScan можно использовать для анализа требований ТЗ и сопоставления позиций с каталогом. После публикации изменений команда все равно должна загрузить актуальные документы и проверить, что решение относится к текущей редакции, а не к прежнему набору файлов.

Как передать новую версию команде

Правки теряются при передаче между тендерным специалистом, закупщиком, инженером и финансистом. Не рассылайте сообщение «заказчик что-то поменял» без списка действий. Сделайте короткий лист изменений:

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

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

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

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

Перед отправкой выполните «холодную» проверку: сотрудник, который не собирал заявку, открывает только папку final, карточку закупки и площадку. Он должен определить актуальную версию без устных подсказок. Если это невозможно, порядок хранения не готов к дедлайну.

Проверка доступа остается отдельной задачей. Материалы о регистрации в ЕИС и ЕРУЗ и об электронной подписи для госзакупок помогут подготовить учетную запись. Верная версия документов не спасет заявку, если подписант не может завершить отправку.

Контроль перед подачей

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

Прежде чем выходить на электронные торги, финальный контролер проверяет:

1. Дату и время последнего обращения к карточке закупки.
2. Совпадение номера закупки и лота во всех рабочих документах.
3. Наличие реестра версий.
4. Закрытие всех строк матрицы требований.
5. Пересчет цены и логистики после последней правки.
6. Отсутствие старых файлов в папке отправки.
7. Читаемость файлов после загрузки на ЭТП.
8. Сохранение подтверждения финальной подачи.

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

Часто задаваемые вопросы

Достаточно ли сравнить два файла с названием «ТЗ»?

Нет. Изменение может находиться в инструкции, спецификации, проекте контракта или другом приложении. Сначала сравните состав пакетов, затем содержание каждого затронутого документа.

Можно ли удалить старую редакцию после обновления?

Старую редакцию лучше сохранить в архиве с датой получения. Она помогает восстановить ход подготовки и понять, почему команда меняла расчет. В папке отправки при этом должна оставаться только актуальная версия.

Как сравнивать сканированный PDF?

Можно распознать текст для поиска изменений, но числовые параметры и таблицы нужно сверить с изображением страниц. Ошибки распознавания нельзя переносить в заявку.

Что делать, если после изменения товар перестал соответствовать?

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