Автоматизация регистрации поставщиков: анкета, справочники и допуск к закупке

Руководитель закупок получает новую анкету поставщика. Название выглядит новым, но компания уже может быть записана в справочнике под сокращённым именем. Если сразу создать карточку, появится дубль; если автоматически разрешить закупку после заполнения полей, отдел смешает регистрацию с допуском.

Автоматизация регистрации поставщиков должна дать более узкий и проверяемый результат: найти существующую запись или создать новую, устранить пропуски, сохранить решение ответственного и присвоить понятный статус. Проверка рисков контрагента, подтверждение новых банковских реквизитов и разрешение закупки остаются отдельными действиями.

Какую задачу решает этот процесс

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

Процесс приводит входные данные к одному из результатов:

1. Существующая карточка найдена и дополнена новой версией данных.
2. Совпадений нет, поэтому после обязательных проверок создаётся новая карточка.
3. Данных недостаточно или найдено неоднозначное совпадение — анкета передаётся человеку.
4. Карточка зарегистрирована, но допуск ожидает отдельного решения.

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

Какие данные и правила подготовить

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

• Обязательное — без значения анкету нельзя считать заполненной.
• Условное — поле требуется при определённом типе поставщика, закупки или документа.
• Неизвестное — правило ещё не утверждено; система не должна угадывать значение.

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

Ниже — короткий синтетический образец. Он не содержит клиентских данных и не является результатом внедрения.

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

Как принять анкету без дубля поставщика

Название нельзя использовать как единственный ключ. Одна компания может встретиться как «ООО Альфа-Снаб», «Альфа-Снаб» или «Альфа». И наоборот, одинаковое короткое название может относиться к разным организациям.

Безопасная последовательность выглядит так:

1. Привести пробелы, регистр, кавычки и организационно-правовую форму к согласованному виду для поиска.
2. Найти карточки по устойчивому идентификатору компании.
3. Сопоставить основные реквизиты и отметить расхождения.
4. При точном совпадении идентификатора дополнить существующую запись новой версией.
5. Если совпадение неоднозначно, остановить создание и передать пару карточек владельцу справочника.

В синтетическом примере поиск по ID-COMPANY-042 возвращает одну карточку «Альфа». Новых поставщиков создаётся 0, обновляется 1 существующая карточка. Основное название «ООО Альфа-Снаб» сохраняется вместе с сокращённым вариантом и историей версии.

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

Как проверить заполнение и направить по маршруту

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

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

Маршрут удобно разделить на ветви. Полная анкета без конфликтов идёт согласующему. Пропуск возвращается координатору или поставщику на уточнение. Неоднозначное совпадение получает владелец справочника. Просроченный документ проверяет профильный специалист. Новые банковские реквизиты направляются уполномоченному ответственному по отдельному процессу.

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

Официальная документация Microsoft Dynamics 365 Supply Chain Management описывает ограниченный набор сведений, доступных внешнему поставщику, роли и маршруты запросов пользователей. Это подтверждает, что доступ и согласование можно разделять по ролям, но не доказывает совместимость конкретного проекта, наличие нужного тарифа или выполненную настройку. Эти условия проверяют отдельно.

Как завершить регистрацию и поддерживать актуальность

Для карточки нужны разные статусы, иначе сотрудники будут принимать наличие записи за разрешение работать с компанией:

• Зарегистрирован — карточка создана или дополнена, обязательные поля обработаны.
• Допущен — уполномоченный сотрудник принял отдельное решение по установленным правилам.
• Заблокирован — действует самостоятельное правило или решение ответственного, запрещающее использование карточки.

Между ними возможен промежуточный статус «допуск ожидает решения». Именно его получает поставщик из учебного примера: карточка дополнена, но документ просрочен. Закупка не разрешается автоматически.

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

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

Учебный пример: путь от входных данных до результата

Ниже приведён синтетический пример с условными именами, номерами и датами. Это не клиентский кейс, не выгрузка из SRM и не результат живого теста.

Исходные данные. Пришла анкета компании «ООО Альфа-Снаб» с идентификатором ID-COMPANY-042, контактом contact@example.test и документом CERT-042, действующим до 30.09.2026. Контрольная дата проверки — 15.10.2026. В справочнике уже есть карточка «Альфа» с тем же идентификатором.

Расчёт срока воспроизводим: 15.10.2026 − 30.09.2026 = 15 календарных дней. Условие действительности — дата проверки не позже даты окончания. Оно ложно, поэтому документ просрочен на 15 дней.

Промежуточное решение. По идентификатору найдена одна существующая карточка. Процесс не создаёт нового контрагента, а добавляет к карточке «Альфа» новую версию сведений и официальное название «ООО Альфа-Снаб».

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

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

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

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

Что согласовать для внедрения

Готовая форма или SRM может принимать анкету, хранить карточку и поддерживать маршруты согласования. Но само наличие функции не задаёт идентификатор, обязательные документы, полномочия и правила допуска вашей компании. Перед выбором решения нужно проверить версию платформы, доступные роли, API, права и ограничения. Документированную последовательность для Dynamics 365 Supply Chain Management можно использовать как ориентир, но статья не утверждает, что конкретная конфигурация проверена в системе заказчика.

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

Switch On AI может разработать ИИ-помощника, бота или интеграцию для операции «поставщик включается в справочник после проверки заполненности и решения ответственного» после проверки данных и API. Правила бухгалтерского, юридического, кадрового и отраслевого учёта задаёт и проверяет специалист заказчика. Совместимость, тарифы, права и состав подключений проверяются до согласования прототипа.

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