Закупщик передвинул задачу в канбане, а заказ поставщику остался в прежнем статусе. Другой сотрудник изменил заказ в учётной системе — теперь доска снова требует ручного обновления. Два представления одного процесса расходятся, хотя каждое по отдельности выглядит рабочим.
Обмен статусами полезен, когда заказ и задача связаны явно, а правила переходов понятны сотрудникам. Разберём внедрение для 53 заказов: что согласовать до запуска, как проверить оба направления и почему конфликт правок нельзя решать случайным перезаписыванием.
Процесс закупки
Связать заказ, действие и проверку
- 01Найти пару
- 02Сверить статус
- 03Передать правку
- 04Проверить результат
- Колонка и завершение задачи — разные состояния
- Разные одновременные правки становятся конфликтом
- Новые заказы требуют правила подключения
Сначала опишите, что означает каждый статус
Название колонки само по себе не определяет действие. «В работе» может означать сбор предложений, ожидание оплаты или подготовку поставки. Возьмите действующий справочник заказов и согласуйте соответствие каждой колонки конкретному статусу, включая отмену и проблемные ситуации.
Отдельно определите, когда задача завершается. В рассмотренном проекте статусы «Доставлен, оплачен» и «Отменен» завершают её, а остальные возобновляют. Это принятое владельцем правило конкретного процесса. Для другой команды оно может отличаться.
Связывайте конкретные записи, а не похожие названия
Заказ и задача должны иметь устойчивую проверенную связь. Перед изменением нужно проверить проект, ответственного и принадлежность заказа. Одинаковое название или сумма не подтверждают, что перед вами одна закупка.
Первый этап можно ограничить согласованным списком. В нашем внедрении это 53 ранее импортированных заказа одного ответственного. Автоматического подключения новых заказов нет: это отдельный сценарий с правилами отбора, создания задачи и проверки дублей.
У канбана и задачи есть два разных состояния
Завершение или возобновление задачи может повлиять на её колонку. Если принять такое служебное перемещение за новую команду закупщика, интеграция способна записать неверный статус обратно в учётную систему.
Поэтому обмен проверяет и колонку, и состояние исполнения. В рабочем сценарии отдельно проверены завершение и возобновление: статус заказа сохранялся, а задача возвращалась к согласованному состоянию. Проверка только перемещения карточки такого результата не доказывает.
| Событие | Согласованное действие | Контроль |
|---|---|---|
| Закупщик меняет колонку | Изменить статус связанного заказа | Повторно прочитать заказ |
| Меняется статус заказа | Переместить связанную задачу | Проверить колонку и состояние задачи |
| Служебное завершение задачи | Сохранить правило жизненного цикла | Не передать побочную смену колонки обратно |
| Разные правки с обеих сторон | Показать конфликт | Получить согласованное решение |
Повторный проход должен учитывать уже сделанное
Обмен сохраняет состояние пары и намерение до записи, перечитывает обе системы перед изменением и проверяет результат после него. Это помогает продолжить обработку после частичного сбоя и не вернуть статус назад следующим проходом.
Между двумя разными API нет общей атомарной операции. Если одна сторона недоступна, нельзя считать весь переход успешным только по первому ответу. Журнал должен показывать незавершённое действие и дальнейший порядок проверки.
Конфликт — рабочая ситуация, которую нужно показать
Два сотрудника могут почти одновременно принять разные решения в разных системах. Правило «последний ответ победил» скрывает это расхождение. В выполненном обмене разные одновременные изменения сохраняются как конфликт без автоматического перезаписывания.
Для разрешения в этом проекте ставят одинаковый статус на обеих сторонах. Ошибки и конфликты видны в журнале; уведомления в чаты не подключены. Канал уведомлений и ответственного за такие ситуации стоит согласовать до расширения интеграции.
Что проверили в рабочем внедрении
8 октября 2026 года проверили переход из Битрикс24 в Бизнес.Ру и обратное изменение из заказа в задачу. Сумма, название, оплаты и проведение заказа сохранились. Отдельные проверки подтвердили завершение и возобновление задач.
Итоговое чтение всех 53 пар показало 37 заказов в работе и 16 в состоянии «Доставлен, оплачен», без несовпадений. Автоматический проход завершился без ошибок и конфликтов. Эти цифры подтверждают состояние выбранного набора на момент проверки, а не весь закупочный контур компании.
Как принять первый этап
Выберите несколько контрольных заказов и проверьте оба направления, повторный проход, недоступность одной стороны и одновременную правку. Убедитесь, что обмен меняет только согласованные поля и не затрагивает суммы или платежи.
В результат первого этапа входят карта статусов, список связей, журнал и инструкция по остановке и конфликтам. Частоту обновления, добавление новых заказов и уведомления нужно согласовать отдельно. Быстрые изменения с возвратом между опросами могут остаться ненаблюдаемыми.
Короткий чек-лист
- Согласовать карту статусов и завершение задач
- Зафиксировать список заказов и связи
- Проверить обмен в обе стороны
- Проверить конфликт и частичный сбой
- Убедиться в сохранности сумм и оплат
- Назначить ответственного за журнал
Ссылки и исходный код
В материале раскрыты запросы: интеграция Битрикс24 Бизнес.Ру, автоматизация закупок, статусы заказов поставщику, канбан закупок.