Закрепить выбранные реквизиты сторон карточки

Робот «Закрепить выбранные реквизиты сторон карточки» сохраняет явно выбранные реквизиты клиента и своей компании с проверкой владельцев и ожидаемого состояния.

Видимая часть формы настройки в Битрикс24. Скриншот показывает поля действия; он не подтверждает выполнение учебного примера.

Для кого и какую задачу решает

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

Подготовленные ID сами по себе не делают реквизиты выбранными в карточке. Робот закрепляет конкретные наборы обеих сторон и проверяет их принадлежность. Стороны сделки он не меняет, поэтому их нужно выбрать заранее.

Параметры и подготовка

Поле	Как заполнить
Тип: сделка 2 или новый счёт 31 (ENTITY_TYPE_ID)	Обязательное поле
ID карточки (ENTITY_ID)	Обязательное поле
REQUISITE_ID (REQUISITE_ID)	Обязательное поле
BANK_DETAIL_ID (BANK_DETAIL_ID)	Обязательное поле
MC_REQUISITE_ID (MC_REQUISITE_ID)	Обязательное поле
MC_BANK_DETAIL_ID (MC_BANK_DETAIL_ID)	Обязательное поле
Прежний выбор JSON или NONE (EXPECTED_LINK)	Обязательное поле
Уникальный ключ операции (OPERATION_KEY)	Обязательное поле

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

Как использовать

1. Укажите тип 2 для сделки либо 31 для нового счёта и ID карточки. Прочитайте её текущий выбор реквизитов.
2. Передайте положительные REQUISITE_ID клиента и MC_REQUISITE_ID продавца. Банковские ID могут быть 0, если банковский выбор не нужен.
3. В EXPECTED_LINK передайте все четыре прежних ID либо буквальное NONE, если записи выбора нет. Нулевые ID внутри существующей записи не равны отсутствию записи.
4. Задайте уникальный OPERATION_KEY. После выполнения сверьте подтверждённые ID и changed/replayed; при неизвестном исходе проверьте карточку до повторной попытки.

Как заполнить JSON-поля

Прежний выбор JSON или NONE (EXPECTED_LINK)

{
  "REQUISITE_ID": 71,
  "BANK_DETAIL_ID": 0,
  "MC_REQUISITE_ID": 72,
  "MC_BANK_DETAIL_ID": 0
}

Ровно четыре прежних ID из чтения выбранных реквизитов карточки, без добавочных ключей. ID неотрицательные. Если записи выбора не было, вместо JSON передайте буквальное NONE. {} и [] не подходят.

Это объект с именованными полями. Не заменяйте его массивом []. Имена полей и их регистр должны совпасть с приведённым форматом.

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

Учебная сделка 101 уже имеет клиента и свою компанию. Нужно выбрать реквизиты 81 и 82 без банков: REQUISITE_ID=81, BANK_DETAIL_ID=0, MC_REQUISITE_ID=82, MC_BANK_DETAIL_ID=0. Если прежний выбор существовал, EXPECTED_LINK должен содержать ровно его четыре ID. При совпавшем ожидании робот закрепляет новый выбор; при несовпадении останавливается.

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

Что возвращает и как продолжить процесс

• «ID карточки» (entityId).
• «REQUISITE_ID» (REQUISITE_ID).
• «BANK_DETAIL_ID» (BANK_DETAIL_ID).
• «MC_REQUISITE_ID» (MC_REQUISITE_ID).
• «MC_BANK_DETAIL_ID» (MC_BANK_DETAIL_ID).
• «Выбор изменён» (changed).
• «Сохранённое подтверждение» (replayed).

changed=N означает, что нужный выбор уже установлен. replayed=Y означает сохранённое подтверждение этой операции, проверенное по текущим данным. Выходные четыре ID описывают подтверждённый выбор, а не новый набор найденных кандидатов.

Выход «Статус выполнения» проверяйте перед передачей результата дальше. При отрицательном статусе прочитайте «Пояснение ошибки» и направьте процесс на исправление исходных данных. Успешный статус подтверждает выполнение действия; содержательные признаки результата проверяйте отдельно.

Ограничения и разбор ошибок

Принимает тип карточки 2/31 и ID, REQUISITE_ID/MC_REQUISITE_ID (оба положительные), BANK_DETAIL_ID/MC_BANK_DETAIL_ID (0: без банковского выбора), EXPECTED_LINK: NONE либо полный JSON из этих четырёх прежних ID, OPERATION_KEY. Стороны уже должны быть выбраны в карточке; их не меняет. Проверяет принадлежность реквизитов и банков, признак своей компании, свежее ожидание и результат чтением. Уже нужный выбор: no-op. Ключ блокирует повторную отправку при неизвестном результате; для нового изменения нужен новый ключ. Возвращает подтверждённые ID, changed/replayed. Нет атомарной блокировки параллельных изменений; повтор требует сверки.

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