Автоматизация заказов поставщику превращает утверждённую закупку в проверенный проект заказа, сверяет позиции и условия, а затем отслеживает ответ поставщика. Скрипт переносит исходные данные и считает по заданным правилам; ИИ объясняет найденные расхождения; закупщик утверждает запись и отправку. Сценарий подходит там, где уже определены источник остатков, полномочия сотрудников и порядок согласования закупки.
Точка старта
Маршрут начинается после статуса «закупка утверждена»: заказ поставщику получает отдельные проверки прав, остатков, лимитов и подтверждения перед отправкой.
Заявка на закупку и заказ поставщику решают разные задачи. Заявка отвечает, что и зачем требуется подразделению; заказ фиксирует согласованные позиции, адресата, количество, цену и условия исполнения. Поэтому входом служит утверждённая запись с версией состава и отметкой согласующего. Если статус ещё открыт либо состав изменился после решения, система возвращает запись на согласование. Подбор поставщика и первоначальную заявку сюда включать бессмысленно: для них нужны собственные правила и ответственные.
В учётной системе, например в 1С при наличии настроенного обмена, заранее определяют обязательные поля проекта: внутренний код номенклатуры, единицу измерения, количество, склад, поставщика, договор, дату потребности и валюту. Само упоминание 1С означает источник данных, а доступные механизмы обмена зависят от конфигурации и доработок компании. Список полей подписывают закупщик и владелец учёта. Они же назначают систему, где хранится окончательный заказ, чтобы разные копии документа расходились только по контролируемому маршруту.
Соседний сценарий автоматизации закупок с ИИ охватывает более широкий процесс. Здесь важен узкий переход от уже принятого решения к обязательству перед поставщиком. В журнале перехода сохраняют идентификатор утверждения, версию строк и ответственного закупщика. Эти поля позволяют объяснить, почему проект заказа появился, и остановить отправку при отмене исходного решения.
Сборка заказа
Сборку ведёт обычный скрипт или маршрут n8n, если такой инструмент уже допущен в компании. Он берёт утверждённые строки, сопоставляет внутренний справочник с кодами поставщика и переносит согласованные условия договора. Сырые остатки и формулы держат в учётном контуре: скрипт сверяет утверждённое количество с текущими остатками, уже размещёнными заказами и кратностью упаковки. Расхождение возвращают закупщику; менять утверждённое количество без нового согласования нельзя. Модель получает только итоговые значения и признаки расхождений; менять арифметику по собственному текстовому выводу ей нельзя.
- Получить утверждённую закупку и проверить актуальность её версии, срок действия решения и права инициатора на выбранное подразделение.
- Сопоставить каждую строку с кодом поставщика, единицей измерения и согласованным договором; неоднозначное соответствие отправить закупщику.
- Сверить остаток, зарезервированные объёмы и открытые заказы с утверждённым количеством; показать входные значения и остановить проект при расхождении.
- Проверить лимит закупки и условия согласования: сумму, поставщика, срок, место поставки и допустимые отклонения.
- Создать проект заказа с журналом проверок; запись в учёт и отправку разрешить после подтверждения уполномоченного закупщика.
Критичная деталь — единый ключ операции. Он связывает утверждённую закупку, поставщика и версию строк. Если обмен повторился после таймаута, скрипт находит прежний проект и обновляет статус проверки либо предлагает человеку разбор. Второй самостоятельный заказ из того же решения создаёт риск двойной поставки. Подробнее связь ИИ с учётным контуром разобрана в материале про нейросеть и 1С; конкретный способ подключения выбирают после проверки конфигурации.
Правила допуска
Перед отправкой требуется отдельный контроль доступа. Инициатор закупки может видеть состояние, согласующий — утверждать исходную потребность, а закупщик с соответствующим правом — подтверждать заказ и адресата. Право фиксируют в рабочей системе, а сервер проверяет его при каждом действии. Текст модели, письмо поставщика и ссылка из уведомления лишены возможности добавить сотруднику права. Изменение суммы, количества или поставщика после согласования возвращает документ на повторный маршрут по правилам компании.
| Сигнал | Проверка скрипта | Решение закупщика |
|---|---|---|
| Код товара расходится | Справочник, единица и упаковка | Выбрать корректное соответствие |
| Остаток изменился | Текущий остаток, резерв и открытые заказы | Уточнить объём заказа |
| Лимит превышен | Бюджет и уже принятые обязательства | Вернуть на согласование |
| Срок расходится | Дата потребности и условия договора | Согласовать новую дату |
| Повторная заявка | Ключ операции и версия утверждения | Закрыть дубль либо разобрать отличие |
ИИ здесь переводит технические сигналы в понятное объяснение: «внутренний код связан с двумя артикулами поставщика» или «предлагаемая дата позже даты потребности». Для такого вывода модели передают только разрешённые поля, ссылку на правило и результат расчёта. Закупщик видит исходные значения рядом с объяснением, исправляет справочник или согласует исключение через штатный маршрут. Если модель ошиблась, числовая проверка и статус заказа остаются прежними. Это предлагаемый порядок автоматизации; внедрённый клиентский кейс здесь отсутствует.
Перед рабочим запуском соберите примеры с совпадением строк, сменой упаковки, исчерпанным лимитом и отменённым согласованием. На каждом примере проверяйте итоговый статус и право на действие, а качество объяснения оценивайте отдельно. Так процесс выдерживает спорные случаи, даже когда формулировка модели звучит убедительно.
Где ваш заказ поставщику чаще застревает на проверке?
Ответ поставщика
После подтверждённой отправки маршрут продолжается. Письмо либо файл от поставщика связывают с номером исходного заказа через безопасный канал компании. Скрипт разбирает структурированные поля или передаёт распознавание в отдельный этап, затем сравнивает подтверждённые позиции, количество, цену, срок и адрес доставки с утверждённой версией. Исходное вложение сохраняют для проверки. Отсутствие ответа отмечают статусом ожидания; автоматическое напоминание запускают только по согласованному правилу и с известным адресатом.
Если поставщик подтверждает заказ частично, каждая строка получает свой результат: принята, предложена замена, изменён срок либо нужна ручная сверка. ИИ может подготовить сводку расхождений для закупщика, опираясь на два документа и результаты сравнения. Он лишь объясняет, какое поле расходится и какое правило затронуто. Решение о замене номенклатуры, новом сроке или дополнительном согласовании принимает человек; обновление записи проходит через проверку прав и журнала версий.
Ошибки транспорта и ошибки содержания тоже разделяют. При сетевом сбое система сохраняет ключ операции, технический статус и время следующей попытки; повтор отправки проходит через проверку факта доставки. При ошибочном артикуле или спорной цене повтор того же письма бесполезен: закупщик исправляет источник и выпускает новую согласованную версию. Уведомление о проблеме должно вести к конкретному заказу и полям сравнения, чтобы сотрудник мог принять решение без поиска переписки по нескольким ящикам.
Для контроля сроков поставки пригодится разбор работы снабженца со сроками. В текущем маршруте контроль начинается с ответа на отправленный заказ, а последующее исполнение поставки живёт в отдельном процессе. Такой раздел ответственности помогает видеть, где именно возникло отклонение: до отправки, при подтверждении или уже при исполнении.
Проверка маршрута
Начните с карты одного типа заказа: от статуса утверждения до получения подтверждения поставщика. Покажите её закупщику, владельцу справочника и ответственному за права доступа. Вместе назовите обязательные поля, источник остатков, лимит, правило повторной отправки и способ возврата на согласование. После этого настройте черновой проход на учебных данных. Его результатом станет проект заказа и журнал причин остановки, без реальной отправки поставщику.
Проверяйте маршрут по наблюдаемым признакам. У каждой утверждённой версии должен появиться максимум один активный проект; строки проекта должны совпадать с проверенным справочником; превышение лимита должно блокировать подтверждение; изменение условий после согласования должно возвращать запись ответственному. Затем проведите ручную проверку объяснений ИИ: закупщик сверяет каждое с исходными полями и отмечает выдуманные причины. Решение о рабочем допуске принимают по результатам проверки фактов, прав и ошибок.
Состав интеграции зависит от качества справочника, числа поставщиков, форматов подтверждений и действующего порядка доступа. Эти обстоятельства влияют и на стоимость проекта; универсальная цифра здесь вводила бы в заблуждение. Для расчёта полезно принести образцы утверждённой закупки, заказа и ответа поставщика, а также перечень исключений. Команда сможет определить границы работ, ответственных и критерии приёмки по вашим данным.
Возьмите один обезличенный утверждённый заказ и вручную восстановите цепочку: источник строки, остаток, лимит, код поставщика, согласующий и ответ поставщика. Если любое звено приходится угадывать, сначала исправьте источник или правило. Затем обсудите автоматизацию бизнес-процесса заказа поставщику: напишите нам, посчитаем под вашу задачу.