Как добавить товары в сделку через REST, не создавая их в каталоге: частая ошибка в crm.deal.productrows.set
2026-01-20 23:42
В автоматизации продаж часто нужно формировать состав сделки «на лету»: добавлять услуги, работы, доставки, пакеты сопровождения или разовые позиции. При этом бизнесу важно, чтобы эти позиции отражались в сделке (для суммы, отчетов и документов), но не засоряли каталог товаров тестовыми или разовыми наименованиями.
Именно под такую задачу обычно выбирают REST-метод crm.deal.productrows.set: он управляет товарными строками конкретной сделки и допускает добавление позиций без привязки к товару каталога.
Проблема пользователя
Пользователь настроил REST-робота: передавал PRODUCT_ID = 0 и заполнял PRODUCT_NAME, цену и количество, ожидая увидеть строки в сделке. Логика верная — но результат нулевой: в интерфейсе сделки товары не появлялись, а повторная проверка через REST показывала пустой список товарных позиций.
Дополнительно всплыл второй сценарий: при добавлении нескольких строк робот начал возвращать null, хотя одиночные варианты раньше удавалось завести.
Почему стандартных инструментов не хватает
В Битрикс24 «товары в сделке» и «товары в каталоге» — разные сущности. Встроенные механики чаще ориентированы на работу с каталогом: выбрать существующий товар, настроить единицы измерения и т. п. Но когда позиция разовая (например, «Сопровождение Битрикс24 1 квартал 2025») — создавать для нее отдельный товар в каталоге не хочется.
REST здесь идеален, но есть нюанс: робот принимает строго определенную структуру параметров. Малейшее расхождение по ключам JSON приводит к «тихим» результатам: метод может отработать без явной ошибки, но фактически не применить изменения.
Решение задачи
Ключевой момент — корректная структура параметров для crm.deal.productrows.set.
Что должно быть в запросе:
id — ID сделки
rows — массив товарных строк (важно именно это имя массива)
внутри каждой строки можно использовать PRODUCT_ID = 0, если позиция не из каталога, и тогда обязательно указывать PRODUCT_NAME, PRICE, QUANTITY (остальные поля — по необходимости)
В кейсе ошибка была как раз в структуре: вместо массива rows использовался другой ключ (частая путаница — productRows). Из-за этого робот получал валидный JSON, но метод не видел товарные строки и возвращал null. После замены ключа на корректный и повторного запуска товары появились в сделке сразу.
Отдельная проверка, которая помогает быстро отлавливать такие вещи: сначала вызвать crm.deal.productrows.get, убедиться, что список пустой, затем выполнить crm.deal.productrows.set и снова вызвать get, чтобы увидеть результат.
Пример логики и подхода
Ниже — эталонная форма параметров (как текст, без подсветки):
"PRODUCT_NAME": "Доп. сопровождение за ноябрь и декабрь",
"PRICE": 16000,
"QUANTITY": 1
}
]
}
В роботах удобно подставлять ID сделки через макрос (например, {{ID}}). А для диагностики — сохранять ответ приложения в лог, чтобы видеть, не превратился ли массив в null из-за неверного ключа или структуры.
Такие REST-настройки быстрее и безопаснее всего собирать и проверять в REST API - методы РЕСТ Битрикс24 и JSON в роботах и БП: там проще валидировать JSON, контролировать структуру и сразу тестировать запросы на реальных данных робота.
Результат
После правки структуры параметров:
товарные позиции корректно добавлялись в сделку
каталог товаров оставался «чистым» (позиции не создавались как товары)
при добавлении нескольких строк метод перестал возвращать null, потому что массив стал передаваться в ожидаемом формате
Вывод
Если нужно «добавить товары в сделку без каталога» в Битрикс24, crm.deal.productrows.set — правильный путь. Но успешность почти всегда упирается в точность JSON: критично использовать rows, корректно передавать id сделки и не путать структуру массива при нескольких позициях.
Когда задача завязана на REST-роботов и JSON-параметры, REST API - методы РЕСТ Битрикс24 и JSON в роботах и БП помогает сократить время на отладку: вместо догадок вы быстро видите, где «сломалась» структура, и доводите сценарий до стабильной работы.