Тендеры¶

Пакет tenders — пример прикладного пакета процессов: участие организации в закупке по 44-ФЗ от извещения в ЕИС до подписания контракта. На нём видно, как язык процессов, база знаний и коннектор внешнего источника работают вместе. Статья для тех, кто собирает свой прикладной пакет или разворачивает этот. Обоснование — TAI-ADR-0054; предметная область закупок живёт только в пакете tenders и интеграции ЕИС — ядро о закупках не знает.

Что проверено, а что нет

Процесс проверен тестами пакета в песочнице ядра: 19 сценариев проходят весь цикл, покрытие элементов, переходов, строк таблиц и обработчиков — полное. Коннектор ЕИС проверен на реальных и синтетических документах (фикстурах). Работа с живым сервисом ЕИС не проверена: для неё нужен узел с доступом к ЕИС и токен (см. Что нужно для запуска). По умолчанию пакет в установку не входит, а агент коннектора описан с state: stopped.

Состав пакета¶

Объект	Что это
`processes/tender.yaml`	процесс `tender` — закупка от извещения до контракта
`schemas/tender.yaml`	схема данных экземпляра (`data: {$ref: ../schemas/tender.yaml}`)
`agents/eis-connector.yaml`	коннектор ЕИС — агент вида `observer`
`agents/tenders-process.yaml`	личность процесса (вид `service`)
`roles/`	`tender-lead`, `tender-lawyer`, `tender-finance`, `general-director`
`task-types/`	типы задач шагов: go/no-go, юридический анализ, запрос разъяснений, расчёт и согласование цены, документы заявки, обеспечения, подача, проверка итогов, проект контракта, протокол разногласий, подписание, разбор проигрыша
`skills/`	скиллы первичного анализа перед go/no-go: `tender.match_items@1`, `tender.check_requirements@1`, `tender.analyze_docs@2` — см. Первичный анализ тендера
`artifact-types/procurement-document.yaml`	документ закупки — артефакт-ссылка на файл в ЕИС
`notification-rules/tender-escalated.yaml`	уведомление об эскалации срока шага
`tests/*.test.yaml`	19 сценариев

requires: [process-knowledge, platform-calendars] — правило сверки регламентов и тип задачи подтверждения уроков, производственный календарь РФ (ru).

Процесс по стадиям¶

flowchart LR
    SC[screening<br/>отбор] --> DE[decision<br/>go / no-go]
    DE --> AN[analysis<br/>документация и вопросы]
    AN --> PR[pricing<br/>цена и согласования]
    PR --> PP[preparation<br/>заявка]
    PP --> SU[submission<br/>подача человеком]
    SU --> RE[results<br/>протоколы]
    RE -->|победа| CO[contract<br/>контракт]
    RE -->|проигрыш| CL[closing<br/>разбор]

Стадия	Что происходит
`screening`	таблица сроков 44-ФЗ по способу закупки и НМЦК; закупка отсеивается (исход `screened-out`), если закон или способ без строки таблицы или до окончания подачи меньше трёх рабочих дней; `recall` прошлых дел заказчика и уроков; таблица-подсказка по ответу памяти; `recall` знаний о компании, сопоставление позиций с номенклатурой, проверка требований к участнику, исполнитель по профилю работ
`decision`	скилл анализа документации со знанием о компании и рекомендацией (при сбое — дело идёт дальше без анализа, см. Первичный анализ тендера); задача go/no-go руководителю тендерного отдела с контекстом из памяти, сроком за 5 рабочих дней до окончания подачи и эскалациями; не «go» — исход `declined`
`analysis`	юридический анализ; при необходимости — запрос разъяснений заказчику и ожидание ответа (наблюдение `procurement.clarification`) с таймаутом
`pricing`	`recall` цен прошлых закупок; расчёт цены; уровень согласования по таблице порогов; согласование с разделением обязанностей — автор расчёта свою цену не согласует; отказ возвращает расчёт на доработку (до двух повторов), затем исход `price-not-approved`
`preparation`	параллельно документы заявки и обеспечение заявки; детерминированная проверка готовности: документы, согласование, обеспечение, срок; неготово — задача устранить, затем повтор проверки; не успели — исход `not-submitted`
`submission`	задача «подать заявку своей ЭП» человеку; прерывающий таймер на момент окончания подачи — исход `missed-deadline`
`results`	ожидание протокола итогов (30 дней; при приостановке срок замораживается); без протокола — задача проверить итоги вручную; `remember` цен и итога
`contract`	параллельно обеспечение исполнения и проверка проекта контракта; протокол разногласий при необходимости; подписание контракта человеком; ожидание контракта в реестре ЕИС; исход `contract-signed`
`closing`	разбор проигрыша; `remember` причины и разрыва в цене; победитель — из контракта в реестре (протоколы анонимны); исход `lost`

Сквозь стадии (onEvent):

отмена заказчиком — работа приостанавливается, сделанное откатывается в обратном порядке (отзыв согласования цены, задачи финансам освободить обеспечения), исход cancelled-by-customer;
приостановка (например, жалоба в ФАС) — suspend, таймеры стоят; возобновление — resume, сроки сдвигаются на длительность приостановки;
изменение извещения (correlate) переписывает данные закупки — таймеры, читающие сроки, пересчитываются сами.

Подача заявки, протокол разногласий и подписание контракта — только человеком его электронной подписью. У платформы — задача и детерминированная проверка готовности; факт подтверждает ЕИС.

После закрытия дела, в котором решили участвовать, — разбор: агент предлагает уроки, человек подтверждает (retrospective, уроки привязываются к заказчику и коду ОКПД2).

Работа с памятью¶

Что	Как
дело в базе знаний	`memory.case` — `tender:<номер закупки>`; факты — закон, способ, НМЦК, окончание подачи, решение, цена, итог согласования, победа, цена победителя, участники, причина проигрыша, номер контракта
сущности	заказчик — `legal_entity` по ИНН (связь `customer`), закупка (`concerns`), способ закупки (`procured_by`), коды ОКПД2 (`classified_as`)
документы	артефакты `procurement-document` → документы дела
перед go/no-go	`recall` от заказчика: его прошлые дела и уроки (`applies_to`); таблица `go-no-go-advice` по ответу выбирает подсказку: есть уроки / знакомый заказчик / новый
перед ценой	`recall` от заказчика и кода ОКПД2: цены и итоги прошлых закупок
контекст задач	у go/no-go, расчёта и согласования цены — дело, заказчик и уроки по связям
запись	`remember` цен и итога из протокола, победителя из реестра контрактов (узел `legal_entity` со связью `won`)
регламенты	процесс и стадии ссылаются на регламент закупок организации (`regulation:purchasing`, разделы 2–7), таблица сроков и её строки — на 44-ФЗ (`law:44-fz`)

Виды памяти закупок (procurement, procurement_method, okpd2_code, product_registry_entry и связи customer, classified_as, concerns, procured_by, won, registered_as) приходят пакетом онтологии procurement@2 интеграции tenders — расширением базовой онтологии компании company@1, вместе с нейтральным process-knowledge@1 (см. Процессы и база знаний и База знаний компании).

Сроки 44-ФЗ¶

Законодательные сроки — таблица решений deadlines-44fz: каждая строка — пункт закона, у строки есть governedBy на law:44-fz. Внутренние сроки считаются назад от окончания подачи заявок по производственному календарю (cal.addWorkdays).

Сверьте с действующей редакцией закона

Значения ниже — данные пакета, а не юридическая консультация. Перед использованием сверьте таблицу с действующей редакцией 44-ФЗ. Коды способов конкурса и запроса котировок в ЕИС на реальных документах не сверены; для запроса котировок под сомнением срок рассмотрения и применимость 10-дневного запрета ст. 51 — это отмечено в строке таблицы.

Способ (коды ЕИС)	НМЦК	Извещение до окончания подачи	Запрос разъяснений	Рассмотрение	Проект контракта / подписание победителем / заказчиком	Не ранее чем после протокола
электронный аукцион (`EAP20`, `EA20`)	до 300 млн ₽	≥ 7 дней (ст. 42 ч. 3 п. 2)	≤ за 3 дня (ст. 42 ч. 5)	2 раб. дня (ст. 49 ч. 5 п. 1)	2 / 5 / 2 раб. дня (ст. 51)	10 дней
электронный аукцион	более 300 млн ₽	≥ 15 дней	≤ за 3 дня	2 раб. дня	2 / 5 / 2 раб. дня	10 дней
электронный конкурс (`EOK20`, `EOKP20`, `OK20`)	любая	≥ 15 дней (ст. 42 ч. 3 п. 1)	≤ за 3 дня	первые части — 2 раб. дня (ст. 48 ч. 1 п. 3)	2 / 5 / 2 раб. дня	10 дней
электронный запрос котировок (`EZK20`, `EZKP20`, `ZK20`)	любая	≥ 4 раб. дня (ст. 42 ч. 3 п. 3)	≤ за 3 дня	2 раб. дня (ст. 50 ч. 3 п. 1; сверить)	2 / 5 / 2 раб. дня	не применяется (сверить)
прочие способы и 223-ФЗ	—	строки нет — закупка отсеивается на отборе

Для 223-ФЗ сроки задаёт положение о закупке заказчика — это отдельная ветка таблицы, язык и данные закупки её допускают.

Порог согласования цены — таблица approval-thresholds (раздел 4.2 регламента закупок; значения по умолчанию, организация меняет их в своей версии пакета):

НМЦК	Кто согласует
до 3 млн ₽	руководитель тендерного отдела (`tender-lead`), не автор расчёта
от 3 до 30 млн ₽	финансы (`tender-finance`)
от 30 млн ₽	финансы и генеральный директор, оба

Источник — ЕИС¶

Коннектор eis-connector — агент вида observer на узле fleet (см. Агенты описанием). Источник — только официальная ЕИС: сервис отдачи документов getDocsIP (int.zakupki.gov.ru) по токену физического лица и лента RSS расширенного поиска как сигнал.

Что	Как
обнаружение	RSS — кандидаты за текущий день; догонка по регионам и видам извещений за завершённые дни (`getDocsByOrgRegion`, `catchup.days`)
синхронизация	кандидаты и открытые закупки — `getDocsByReestrNumber`; каждый новый документ — наблюдение
фильтры	данные описания агента: `laws`, `okpd2`, `regions`, `minPrice` (первая установка: 44-ФЗ, ОКПД2 `62.` и `63.`, все регионы, НМЦК от 1 млн ₽)
наблюдения	`procurement.notice_published`, `…notice_changed`, `…cancelled`, `…clarification`, `…protocol`, `…suspended`, `…resumed`, `…contract`; служебные `procurement.skipped`, `eis.token_rejected`, `eis.token_missing`
идемпотентность	`dedupKey` вида `eis:<закон>:<номер>:<вид>:<id документа>:<версия>`; ключ экземпляра процесса — номер закупки
документы	артефакты `procurement-document` на файлы в ЕИС; с `attachments: content` (так описан агент пакета) файл кладётся содержимым артефакта — его читает первичный анализ; не скачался или больше 30 МБ — остаётся ссылкой; `reference` — только ссылка, `none` — без артефактов
квоты и сбои	пауза между запросами, экспоненциальный повтор; источник недоступен — кандидаты и курсор остаются, следующий цикл продолжает; токен не принят — опрос прекращается до конца цикла, раз в сутки `eis.token_rejected`
персональные данные	ФИО контактных лиц, членов комиссии и поставщиков-физлиц в данные и события не переносятся

Токен хранится только как секрет узла eis-token (файл в контейнере); в описании агента, аргументах, переменных окружения, журналах и артефактах его нет. Пустой файл — токена нет: агент не падает, ЕИС не опрашивает и раз в сутки пишет eis.token_missing.

Что нужно для запуска¶

Узел fleet с доступом к ЕИС — российский IP, с которого действительно открываются int.zakupki.gov.ru и zakupki.gov.ru; на узле метка eis-access. Проверка с самой машины:

curl -sS -o /dev/null -w "%{http_code}\n" --max-time 15 \
  "https://int.zakupki.gov.ru/eis-integration/services/getDocsIP?wsdl"
curl -sS -o /dev/null -w "%{http_code}\n" --max-time 15 https://zakupki.gov.ru/epz/main/public/home.html

Таймаут — машина не годится. Порядок подключения узла — Узлы и fleet. 2. Токен физического лица. Владелец регистрируется потребителем машиночитаемых данных ЕИС через ЕСИА и получает токен в личном кабинете. Токен кладётся в секрет узла eis-token — записью в тот же файл (cat > …), а не заменой файла: секрет смонтирован в контейнер файлом, и новый inode контейнер не увидит. Коннектор перечитывает файл каждый цикл. 3. Корневые сертификаты НУЦ Минцифры, если публичная часть ЕИС отдаёт сертификат удостоверяющего центра, которого нет в системном хранилище. Корневой и выпускающий сертификаты скачиваются с официальной страницы Госуслуг, отпечатки SHA-256 сверяются с двумя официальными источниками, файлы кладутся в integrations/eis/certs/, образ коннектора пересобирается. Пока их нет, коннектор предупреждает и работает на системных корнях. 4. Установка пакета: переменные ${TENDERS_WORKSPACE_ID} (workspace «Тендеры»), ${TENDERS_ESCALATION_PRINCIPAL_ID} (кому уведомления об эскалациях) и ${TENDERS_COMPANY_INN} (ИНН организации компании — якорь памяти о компании); связка личности tenders-process; план и применение процесса (см. Тесты пакета). 5. База знаний: для дерева workspace включены пакеты онтологии process-knowledge@1, company@1 и procurement@2; загружены регламент закупок организации с ключом regulation:purchasing, 44-ФЗ — law:44-fz и знание о компании (см. Первичный анализ тендера). 6. Скиллы: хостинг local-скиллов с пакетами интеграций tenders, company_knowledge и process_knowledge и LLM инсталляции. 7. Запуск коннектора: state: running в описании агента и применение пакета — контроллер разместит агента на узле с меткой и секретом.

Тесты пакета¶

PYTHONPATH=control-plane/src:control-plane/client/src python3 tools/package_sandbox.py tenders

Сценарии: победа и контракт, контракт с протоколом разногласий, проигрыш (и проигрыш без известного победителя), отказ от участия, отсев 223-ФЗ, короткий срок, изменение извещения, отмена до и после победы, приостановка ФАС и возобновление, разделение обязанностей на цене, цена не согласована, неготовность исправлена, заявка не подана, урок прошлого дела в контексте go/no-go, первичный анализ со знанием компании, ИИ недоступен за все повторы, деградация анализа.