Как сделать ИИ-агента для закупок и снабжения

Что получится в результате

Соберем ИИ-агента для закупок и снабжения, который принимает закупочные заявки, проверяет полноту требований, смотрит остатки и потребность, подбирает поставщиков, сравнивает предложения, готовит RFQ, черновик purchase order и задачи закупщику, но не покупает и не согласует деньги без человека.

Первая рабочая версия будет делать так:

1. настройки хранятся в `settings`;
2. заявители и подразделения хранятся в `requesters`;
3. категории закупок хранятся в `procurement_categories`;
4. закупочные заявки хранятся в `purchase_requests`;
5. строки заявок хранятся в `purchase_request_items`;
6. справочник товаров и услуг хранится в `item_catalog`;
7. поставщики хранятся в `supplier_master`;
8. договоры хранятся в `supplier_contracts`;
9. лимиты и бюджеты хранятся в `budget_limits`;
10. остатки и потребность хранятся в `demand_snapshot`;
11. проверка полноты заявки пишется в `request_checks`;
12. подбор поставщиков пишется в `supplier_candidates`;
13. запросы цен пишутся в `rfq_queue`;
14. предложения поставщиков пишутся в `supplier_quotes`;
15. сравнение предложений пишется в `quote_comparison`;
16. риски закупки пишутся в `procurement_risk_log`;
17. черновики purchase order пишутся в `po_drafts`;
18. спорные действия уходят в `approval_queue`;
19. одобренные действия попадают в `execution_queue`;
20. задачи закупщику, финансам, юристу и складу пишутся в `task_queue`;
21. ежедневная сводка пишется в `daily_procurement_report`;
22. все решения пишутся в `audit_log`;
23. ошибки данных и API пишутся в `error_log`.

В первой версии агент не создает реальный PO, не меняет банковские реквизиты, не выбирает нового поставщика сам, не обходит лимиты и не отправляет деньги. Он проверяет, сравнивает, готовит черновики и отправляет рискованные действия на approval.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets для MVP-таблиц.
• Форма заявки: Google Forms, Tally, Typeform, Bitrix24, CRM или ERP.
• Источник закупочных данных: Odoo, Coupa, SAP Ariba, 1С, МойСклад, ERP или CSV.
• Read-only API-ключ к закупочной системе на первом этапе.
• Справочник поставщиков.
• Список договоров, лимитов, бюджетов и категорий закупок.
• Данные по остаткам или потребности со склада, производства или продаж.
• Канал approval: Telegram, Slack, email или задача.
• API-ключ LLM-провайдера.
• Ответственный закупщик или руководитель, который подтверждает выбор.

Шаг 1. Выберите один сценарий закупки

Не начинайте с полного автономного снабжения.

Для MVP выберите один сценарий:

1. проверка полноты закупочной заявки;
2. поиск подходящих поставщиков;
3. сравнение предложений по RFQ;
4. подготовка черновика PO;
5. поиск дублей закупок;
6. контроль заявок вне бюджета;
7. ежедневный отчет по открытым закупкам.

Самый безопасный старт: `агент проверяет новые закупочные заявки, находит недостающие данные и готовит задачи закупщику`.

Проверка: сценарий можно вручную проверить на 5 заявках.

Шаг 2. Запретите опасные действия

В первой версии запретите агенту:

• создавать реальный purchase order;
• отправлять PO поставщику;
• выбирать нового поставщика без согласования;
• менять банковские реквизиты поставщика;
• менять договор;
• обходить бюджетный лимит;
• подтверждать закупку вне бюджета;
• отправлять оплату;
• менять цену в ERP;
• менять дату поставки в договоре;
• закупать у заблокированного поставщика;
• удалять заявку или документ.

Разрешите агенту:

• читать заявки;
• проверять полноту;
• искать дубли;
• подбирать кандидатов;
• готовить RFQ;
• сравнивать quotes;
• создавать черновик PO;
• отправлять approval;
• вести лог.

Проверка: write-доступ к ERP выключен или все write-действия идут только через `approval_queue`.

Шаг 3. Создайте Google Sheet проекта

Создайте таблицу:

Procurement agent

Добавьте листы:

settings
requesters
procurement_categories
purchase_requests
purchase_request_items
item_catalog
supplier_master
supplier_contracts
budget_limits
demand_snapshot
request_checks
supplier_candidates
rfq_queue
supplier_quotes
quote_comparison
procurement_risk_log
po_drafts
approval_queue
execution_queue
task_queue
daily_procurement_report
audit_log
error_log

Проверка: n8n может читать и писать во все листы.

Шаг 4. Заполните settings

В `settings` добавьте колонки:

key
value
description
updated_at

Заполните минимум:

approval_required | true | закупки только через approval
auto_execute | false | автоприменение выключено
max_po_draft_amount | 500000 | лимит черновика PO
new_supplier_requires_legal | true | новый поставщик требует юрпроверку
bank_details_change_blocked | true | изменение реквизитов запрещено
rfq_min_quotes | 3 | минимум предложений для сравнения
budget_overrun_pct | 5 | допустимое превышение бюджета
duplicate_check_days | 30 | период поиска дублей

Проверка: `approval_required = true`, `auto_execute = false`.

Шаг 5. Заполните requesters

В `requesters` добавьте колонки:

requester_id
name
email
department
manager_email
cost_center
approval_limit
status
updated_at

Пример:

REQ-001 | Анна Орлова | anna@example.ru | production | boss@example.ru | CC-PROD | 50000 | active | 2026-05-23

Проверка: у каждой заявки есть заявитель и cost center.

Шаг 6. Заполните procurement_categories

В `procurement_categories` добавьте колонки:

category_id
name
category_type
default_owner
requires_contract
requires_rfq
requires_legal_review
requires_security_review
status
updated_at

Пример:

CAT-RAW | Сырье и материалы | goods | procurement | true | true | false | false | active | 2026-05-23
CAT-SOFT | SaaS и ПО | service | procurement | true | true | true | true | active | 2026-05-23

Проверка: у каждой категории есть правила review.

Шаг 7. Заполните purchase_requests

В `purchase_requests` добавьте колонки:

request_id
source_system
external_id
requester_id
department
cost_center
category_id
business_reason
needed_by
priority
estimated_amount
currency
status
created_at
updated_at

Статусы:

new
needs_data
checked
rfq_needed
quotes_received
approval_pending
approved
rejected
po_drafted
closed
cancelled

Пример:

PR-1001 | form | 9001 | REQ-001 | production | CC-PROD | CAT-RAW | Нужно сырье для заказа MO-45 | 2026-06-01 | high | 180000 | RUB | new | 2026-05-23 | 2026-05-23

Проверка: есть минимум 3 заявки со статусом `new`.

Шаг 8. Заполните purchase_request_items

В `purchase_request_items` добавьте колонки:

request_item_id
request_id
item_id
item_name
description
quantity
unit
target_price
currency
preferred_supplier_id
spec_file_url
status
updated_at

Пример:

PRI-1001-1 | PR-1001 | MAT-2201 | Доска дубовая 20 мм | сорт A, влажность до 10% | 120 | m2 | 1500 | RUB | SUP-11 | https://drive/spec.pdf | new | 2026-05-23

Проверка: у каждой строки есть количество, единица и описание.

Шаг 9. Заполните item_catalog

В `item_catalog` добавьте колонки:

item_id
sku
name
category_id
unit
standard_spec
last_price
last_supplier_id
lead_time_days
status
updated_at

Пример:

MAT-2201 | OAK-BOARD-20 | Доска дубовая 20 мм | CAT-RAW | m2 | сорт A, влажность до 10% | 1420 | SUP-11 | 7 | active | 2026-05-23

Проверка: агент может сравнить заявку с прошлой ценой и спецификацией.

Шаг 10. Заполните supplier_master

В `supplier_master` добавьте колонки:

supplier_id
name
inn
category_ids
contact_email
contact_phone
payment_terms
average_lead_time_days
quality_score
delivery_score
risk_status
is_approved
status
updated_at

`risk_status`:

ok
watchlist
blocked
new
needs_legal_review

Проверка: поставщик с `blocked` никогда не попадает в recommendation без критического предупреждения.

Шаг 11. Заполните supplier_contracts

В `supplier_contracts` добавьте колонки:

contract_id
supplier_id
contract_number
category_id
valid_from
valid_to
payment_terms
delivery_terms
currency
limit_amount
status
updated_at

Статусы:

active
expired
draft
blocked
missing

Проверка: если категория требует договор, а договора нет, заявка получает риск.

Шаг 12. Заполните budget_limits

В `budget_limits` добавьте колонки:

budget_id
cost_center
category_id
period
budget_amount
committed_amount
spent_amount
available_amount
currency
owner
updated_at

Формула:

available_amount = budget_amount - committed_amount - spent_amount

Проверка: заявка выше доступного бюджета попадает в `procurement_risk_log`.

Шаг 13. Заполните demand_snapshot

В `demand_snapshot` добавьте колонки:

snapshot_at
source_system
item_id
sku
needed_qty
on_hand_qty
incoming_qty
reserved_qty
shortage_qty
needed_by
source_reason
updated_at

`source_reason`:

production_shortage
stockout_risk
sales_order
maintenance
office_need
manual_request

Проверка: закупочная заявка связана с реальной потребностью, а не только с текстом заявителя.

Шаг 14. Подключите источники данных в n8n

Создайте workflow:

Procurement Agent - request check

Добавьте узлы:

1. `Schedule Trigger`;
2. `Read purchase_requests`;
3. `Read purchase_request_items`;
4. `Read item_catalog`;
5. `Read supplier_master`;
6. `Read supplier_contracts`;
7. `Read budget_limits`;
8. `Read demand_snapshot`;
9. `Check request completeness`;
10. `Find supplier candidates`;
11. `Check budget and contract`;
12. `LLM procurement analysis`;
13. `Write checks and risks`;
14. `Create RFQ drafts`;
15. `Send approval`;
16. `Write audit_log`;
17. `Write error_log`.

Проверка: workflow читает все листы и обрабатывает новую заявку.

Шаг 15. Если есть ERP, подключите read-only API

Для Coupa читайте:

requisitions
purchase_orders
suppliers
contracts

Для SAP Ariba читайте:

procurement requests
suppliers
contracts
approval tasks

Для Odoo External API читайте модели:

purchase.order
purchase.order.line
res.partner
product.product
account.analytic.account

Проверка: агент получает заявки, поставщиков и PO, но не создает реальные документы.

Шаг 16. Проверьте полноту заявки в request_checks

В `request_checks` добавьте колонки:

check_id
run_id
request_id
check_type
status
missing_fields
notes
created_at

`check_type`:

required_fields
specification
budget
supplier
contract
duplicate
compliance

Обязательные поля:

1. заявитель;
2. cost center;
3. категория;
4. описание;
5. количество;
6. единица;
7. срок;
8. бизнес-причина;
9. ориентировочная сумма;
10. спецификация или ссылка на файл.

Проверка: неполная заявка получает статус `needs_data`.

Шаг 17. Найдите дубль закупки

Сравните новую заявку с последними заявками за `duplicate_check_days`.

Признаки дубля:

same item_id
same requester
same cost_center
same needed_by
similar description
same preferred_supplier_id

Если найден дубль, запишите риск в `procurement_risk_log`:

duplicate_request

Проверка: две одинаковые заявки на один товар не уходят в RFQ без review.

Шаг 18. Подберите supplier_candidates

В `supplier_candidates` добавьте колонки:

candidate_id
request_id
item_id
supplier_id
supplier_name
match_reason
last_price
average_lead_time_days
quality_score
delivery_score
risk_status
score
status
created_at

Формула простого score:

score = quality_score * 0.4 + delivery_score * 0.4 + price_score * 0.2

Проверка: поставщик `blocked` получает `status = excluded`.

Шаг 19. Создайте rfq_queue

В `rfq_queue` добавьте колонки:

rfq_id
request_id
supplier_id
supplier_email
items_json
message_draft
status
approval_required
sent_at
created_at

Статусы:

draft
sent_to_approval
approved
sent
rejected
expired

Пример `message_draft`:

Просим направить коммерческое предложение по позиции MAT-2201: 120 m2, сорт A, влажность до 10%, срок поставки до 2026-06-01.

Проверка: RFQ не отправляется поставщику без approval.

Шаг 20. Запишите supplier_quotes

В `supplier_quotes` добавьте колонки:

quote_id
rfq_id
request_id
supplier_id
item_id
quantity
unit_price
currency
delivery_cost
lead_time_days
payment_terms
valid_until
attachments_url
status
received_at

Статусы:

received
needs_clarification
valid
expired
rejected

Проверка: предложение без цены, срока или валюты получает `needs_clarification`.

Шаг 21. Сравните предложения в quote_comparison

В `quote_comparison` добавьте колонки:

comparison_id
request_id
quote_ids
best_price_quote_id
best_delivery_quote_id
recommended_quote_id
total_cost
price_delta_pct
lead_time_delta_days
risk_notes
recommendation
created_at

Сравнивайте:

1. цену;
2. стоимость доставки;
3. срок поставки;
4. условия оплаты;
5. наличие договора;
6. качество поставщика;
7. историю задержек;
8. риск статуса поставщика.

Проверка: агент объясняет выбор через evidence, а не только пишет “лучший”.

Шаг 22. Запишите риски в procurement_risk_log

В `procurement_risk_log` добавьте колонки:

risk_id
run_id
request_id
item_id
risk_type
risk_level
evidence_json
recommended_action
owner
status
created_at

`risk_type`:

missing_data
budget_overrun
blocked_supplier
new_supplier
expired_contract
duplicate_request
price_above_last
lead_time_risk
single_quote
bank_details_change

Проверка: закупка у нового поставщика получает `new_supplier` и задачу юристу или закупщику.

Шаг 23. Настройте prompt для LLM procurement analysis

В n8n добавьте узел `LLM procurement analysis`.

System prompt:

Ты закупочный аналитик. Работай только с переданными данными.
Не создавай реальный purchase order, не выбирай поставщика окончательно, не меняй реквизиты и не обходи бюджет.
Если данных не хватает, верни status = needs_data.
Любое финансовое или внешнее действие отправляй в approval.
Ответ возвращай только JSON.

User prompt:

Проанализируй закупочную заявку.

request:
{{$json.purchase_request}}

items:
{{$json.purchase_request_items}}

suppliers:
{{$json.supplier_candidates}}

quotes:
{{$json.supplier_quotes}}

budget:
{{$json.budget_limits}}

contracts:
{{$json.supplier_contracts}}

risks:
{{$json.procurement_risk_log}}

Верни JSON:
{
  "request_id": "...",
  "status": "needs_data | rfq_needed | ready_for_approval | blocked | po_draft_ready",
  "risk_level": "low | medium | high | critical",
  "summary": "...",
  "evidence": ["..."],
  "recommended_actions": [
    {
      "action_type": "ask_requester | send_rfq | request_legal_review | draft_po | create_task | reject_request",
      "owner": "requester | procurement | legal | finance | warehouse",
      "text": "...",
      "requires_approval": true
    }
  ]
}

Проверка: ответ валидный JSON и не содержит покупки без approval.

Шаг 24. Создайте po_drafts

В `po_drafts` добавьте колонки:

po_draft_id
request_id
recommended_quote_id
supplier_id
items_json
total_amount
currency
delivery_terms
payment_terms
contract_id
evidence_json
approval_required
status
created_at

Статусы:

draft
sent_to_approval
approved
rejected
manual_only
exported

Проверка: `po_drafts` - это черновик, а не реальный заказ поставщику.

Шаг 25. Настройте approval_queue

В `approval_queue` добавьте колонки:

approval_id
source
source_id
request_id
action_type
action_text
payload_json
amount
currency
risk_level
requested_by
approver
status
requested_at
approved_at
decision_comment

Статусы:

pending
approved
rejected
needs_changes
expired

В approval отправляйте:

1. RFQ поставщику;
2. выбор поставщика;
3. черновик PO;
4. закупку вне бюджета;
5. нового поставщика;
6. изменение банковских реквизитов;
7. закупку без договора;
8. закупку с единственным предложением.

Проверка: без `approved` запись не попадает в `execution_queue`.

Шаг 26. Сделайте Telegram approval

В n8n добавьте узел `Telegram`.

Сообщение:

PR-1001: закупка 180 000 RUB

Позиция: MAT-2201, 120 m2
Рекомендация: SUP-11
Причина: цена ниже на 4%, срок 7 дней, договор активен.
Риск: medium, есть только 2 quote вместо 3.

Approve: /approve PR-1001
Reject: /reject PR-1001
Need changes: /changes PR-1001

После `/approve PR-1001` workflow должен:

1. найти `approval_id`;
2. проверить статус `pending`;
3. записать `approved`;
4. заполнить `approved_at`;
5. передать действие в `execution_queue`;
6. записать событие в `audit_log`.

Проверка: `/reject` не создает PO и не отправляет поставщику письмо.

Шаг 27. Настройте execution_queue

В `execution_queue` добавьте колонки:

execution_id
approval_id
request_id
action_type
target_system
payload_json
status
executed_at
result_json
error_message

Статусы:

queued
manual_only
executed
failed
skipped

Для MVP используйте `manual_only`: агент готовит документ, а закупщик создает реальный PO в ERP.

Проверка: пока write-доступ не включен, все PO остаются `manual_only`.

Шаг 28. Создайте task_queue

В `task_queue` добавьте колонки:

task_id
source
source_id
request_id
task_type
title
description
owner_team
assignee
priority
status
created_at
due_at
closed_at

`task_type`:

ask_requester
send_rfq
legal_review
finance_review
supplier_check
po_create_manual
warehouse_check
budget_review
data_fix

Пример:

TASK-901 | procurement_risk_log | RISK-441 | PR-1001 | legal_review | Проверить нового поставщика SUP-55 | Поставщик новый, договора нет | legal | lawyer_1 | high | open | 2026-05-23 | 2026-05-24 | -

Проверка: каждый риск превращается в задачу с владельцем и сроком.

Шаг 29. Соберите daily_procurement_report

В `daily_procurement_report` добавьте колонки:

report_date
new_requests
needs_data
rfq_needed
quotes_received
approval_pending
po_drafts
budget_risks
blocked_suppliers
tasks_created
summary
created_at

Пример summary:

Сегодня 14 новых заявок, 5 неполных, 4 требуют RFQ, 3 ждут approval, 2 заявки выше бюджета, 1 поставщик заблокирован.

Проверка: отчет отправляется закупщику и руководителю снабжения.

Шаг 30. Настройте audit_log

В `audit_log` добавьте колонки:

event_id
run_id
event_type
request_id
actor
input_hash
output_hash
summary
created_at

Пишите события:

run_started
data_loaded
request_checked
duplicate_checked
suppliers_scored
rfq_created
quote_compared
risk_found
po_drafted
approval_requested
approval_approved
task_created
run_finished

Проверка: по `run_id` можно объяснить каждую рекомендацию.

Шаг 31. Настройте error_log

В `error_log` добавьте колонки:

error_id
run_id
step
source_system
request_id
supplier_id
error_type
error_message
payload_sample
status
created_at
resolved_at

`error_type`:

api_error
missing_requester
missing_item
missing_budget
unknown_supplier
blocked_supplier
invalid_json
approval_error
write_error

Проверка: если поставщик неизвестен, агент пишет `unknown_supplier`, а не создает поставщика сам.

Шаг 32. Протестируйте на одной заявке

Создайте тестовую заявку:

purchase_requests:
PR-TEST-001 | form | 9001 | REQ-001 | production | CC-PROD | CAT-RAW | Нужно сырье для заказа MO-45 | 2026-06-01 | high | 180000 | RUB | new | 2026-05-23 | 2026-05-23

purchase_request_items:
PRI-TEST-001 | PR-TEST-001 | MAT-2201 | Доска дубовая 20 мм | сорт A, влажность до 10% | 120 | m2 | 1500 | RUB | SUP-11 | https://drive/spec.pdf | new | 2026-05-23

supplier_quotes:
Q-1 | RFQ-1 | PR-TEST-001 | SUP-11 | MAT-2201 | 120 | 1420 | RUB | 8000 | 7 | 50% предоплата | 2026-05-30 | https://drive/q1.pdf | valid | 2026-05-23
Q-2 | RFQ-2 | PR-TEST-001 | SUP-12 | MAT-2201 | 120 | 1490 | RUB | 0 | 5 | постоплата 10 дней | 2026-05-30 | https://drive/q2.pdf | valid | 2026-05-23

Ожидаемый результат:

1. `request_checks` показывает, что заявка полная;
2. `supplier_candidates` содержит минимум 2 поставщика;
3. `quote_comparison` сравнивает цену и срок;
4. `procurement_risk_log` пишет риск, если quote меньше трех;
5. `po_drafts` создает черновик;
6. `approval_queue` создает заявку;
7. `task_queue` создает задачу закупщику;
8. `audit_log` содержит шаги запуска;
9. `error_log` пустой.

Проверка: реальный PO не создан без approval.

Шаг 33. Проверьте негативные сценарии

Сделайте 5 тестов:

1. удалите заявителя из `requesters`;
2. укажите заблокированного поставщика;
3. поставьте сумму выше бюджета;
4. удалите договор для категории, где договор обязателен;
5. верните от LLM невалидный JSON.

Ожидаемый результат:

1. нет заявителя - `missing_requester`;
2. заблокированный поставщик - `blocked_supplier`;
3. сумма выше бюджета - `budget_overrun`;
4. нет договора - `expired_contract` или `missing_contract`;
5. невалидный JSON - `invalid_json`;
6. PO не создается;
7. execution не запускается без approval.

Проверка: агент не обходит лимиты и не придумывает поставщиков.

Минимальная проверка результата

Прототип работает, если выполняются условия:

1. `purchase_requests` содержит минимум 3 заявки;
2. `purchase_request_items` содержит позиции;
3. `supplier_master` содержит поставщиков;
4. `budget_limits` содержит лимиты;
5. `request_checks` ловит неполные заявки;
6. `supplier_candidates` исключает заблокированных;
7. `rfq_queue` создает RFQ только как черновик;
8. `supplier_quotes` хранит предложения;
9. `quote_comparison` показывает evidence;
10. `procurement_risk_log` ловит бюджет, договор и поставщика;
11. `po_drafts` создает только черновик;
12. `approval_queue` блокирует внешние действия;
13. без `approved` нет записи в `execution_queue`;
14. `task_queue` назначает владельца;
15. `daily_procurement_report` показывает статус закупок;
16. `audit_log` объясняет действия;
17. `error_log` показывает плохие данные.

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

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

Частые вопросы

Можно ли начать без Coupa или SAP Ariba?

Да. Для MVP хватит Google Forms, Google Sheets, справочника поставщиков и approval-бота. ERP или procurement platform нужны, когда процесс станет стабильным и появится требование к интеграции.

Может ли агент сам выбирать поставщика?

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

Как агент проверяет бюджет?

Он сравнивает сумму заявки с `available_amount` в `budget_limits` и учитывает `budget_overrun_pct`. Если заявка выше лимита, она получает риск и отдельный approval.

Что делать с новым поставщиком?

Новый поставщик должен идти на legal, finance или compliance review. Агент может создать задачу и собрать данные, но не должен добавлять поставщика в боевой справочник сам.

Какой минимальный результат считать успешным?

Успешный MVP: агент берет одну заявку, проверяет поля, находит поставщиков, сравнивает quotes, создает черновик PO, отправляет approval, создает задачу и пишет audit log.