Каталог товаров в amoCRM: цены, сделки и учёт остатков

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

В официальной документации amoCRM «Товары» описаны как специальный список типа products; среди системных свойств есть артикул и цена. Функцию включают в общих настройках, после чего она появляется в разделе «Списки». Конкретный интерфейс и доступные возможности стоит проверить в рабочем аккаунте перед запуском проекта.

Что каталог должен решать, а что оставить учётной системе

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

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

Как подготовить структуру карточки товара

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

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

Цена в каталоге и цена в конкретной сделке

Базовая цена отвечает на вопрос «сколько стоит товар сейчас». Цена в сделке отвечает на вопрос «на какую сумму договорились с этим клиентом». Они могут различаться из-за скидки, курса, комплектации или договора. Поэтому полезно сохранять снимок согласованной цены в составе сделки или документа. Если завтра прайс изменится, вчерашнее предложение не должно молча переписаться.

Определите, где применяются скидки, доставка и налоги; кто может менять цену вручную; нужен ли лимит согласования. Для валютного каталога задайте источник курса и момент фиксации. Не храните «цена 10 000» без валюты, единицы измерения и даты, если это влияет на договор. При работе с несколькими прайсами по регионам или партнёрам проверьте, выдержит ли встроенная модель ваши правила; иногда расчёт должен оставаться во внешней системе.

Как связывать позиции со сделкой

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

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

Товары, счета и факт оплаты

В справке amoCRM по счетам и покупкам указано, что товары из карточки могут автоматически добавляться в счёт, а позиции счета можно редактировать. Это удобно, но перед рабочим запуском проверьте реальные шаблоны документов и налоговые правила вашей компании. Статус счета нельзя приравнивать к банковскому факту без интеграции и сверки.

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

Остатки и резервы: не обещать то, чего нет

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

Опишите поведение при отсутствии данных. Лучше показать «наличие требует подтверждения», чем устаревшее число как факт. Если интеграция временно недоступна, CRM должна обозначить время последнего обновления и запретить автоматическое обещание срока. Эти требования особенно важны, если каталог доступен клиенту через портал или чат-бота.

Синхронизация каталога с 1С или другой системой

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

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

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

Порядок запуска каталога без остановки продаж

1. Назначить источникРешить, где живут артикул, базовая цена, наличие и документы.
2. Очистить номенклатуруУбрать дубли, пустые ID и неоднозначные названия.
3. Собрать карточкуОставить поля, нужные продавцу и отчётам.
4. Проверить сделкиТестировать количество, скидку, услугу, счёт и возврат.
5. Включить обменНачать с части ассортимента и наладить журнал ошибок.

Пилотируйте на одной категории с несколькими менеджерами. Вручную сравните десять–двадцать позиций между системами и проследите полный путь до предложения и счета. Обучение должно объяснять не только «куда нажать», но и когда нельзя обещать цену или наличие без подтверждения.

Ошибки, которые обнаруживаются слишком поздно

Каталог импортировали с красивыми названиями, но без стабильных ID. Цены редактируют и в CRM, и в учётной системе. Старое КП меняется после обновления прайса. Удаление позиции ломает историю сделок. Менеджер видит устаревший остаток без отметки времени. Счёт создаётся дважды при повторном событии. Каждую ошибку можно предупредить, если сначала описать источник данных и проверить повторный запуск интеграции.