Находка
Разделить переговоры и учёт: варианты предложения остаются в CRM, а согласованный заказ передаётся в 1С по определённому событию.
В оптовой компании одна продажа может пройти через несколько расчётов, спецификаций, согласований и дат оплаты. Если просто включить двусторонний обмен, организационная путаница никуда не исчезнет. Она начнёт быстрее передаваться между программами.
Где возникает ручная работа
Менеджеры готовят КП, координатор оформляет документы, бухгалтерия работает с оплатами в 1С. Параллельно живут таблицы плановых платежей. Когда состав заказа меняется, приходится уточнять, какая версия действующая и что уже можно передавать дальше.
В проектном разборе принципиальным оказался момент создания заказа. Промежуточное предложение ещё нельзя считать окончательным обязательством. Значит, обмен должен запускаться по договорённости о процессе, а не просто по нажатию «сохранить».
Какое правило предложено
Предварительные КП, условия и согласования ведутся в CRM. После подтверждения согласованный состав становится заказом в учётной системе. Отдельно определяется, кто создаёт контрагента, где ведутся товары и что можно изменять с другой стороны.
Это защищает смысл данных. Если справочник принадлежит 1С, менеджерская запись в CRM не должна незаметно превращаться в нового учётного контрагента. Направления обмена устанавливаются для каждого типа данных.
Что проверялось на стенде
На тестовой копии проверены передача контрагента и номенклатуры из 1С в CRM, а также создание заказа по сделке. Отдельные прогоны показали, насколько важны сопоставление статусов и ограничения выборки.
Это не заявление о полном запуске всех оплат, резервов и складских операций в рабочей компании. Такие участки требуют собственных проверок. Стенд нужен именно для того, чтобы обнаружить последствия до переноса на рабочие данные.
Что получает руководитель на этапе проектирования
Согласованную границу между продажей, документами и учётом. Понятно, где живёт действующий заказ, какое событие запускает передачу и кто разбирает исключение. Затем эти правила можно закреплять в обмене и рабочих экранах.
Если проблема знакома, на первой встрече полезнее показать один реальный заказ с изменениями, чем перечислять все желаемые интеграции. По нему видно, где системе не хватает правила.
У вас похожая ситуация?
Покажите один рабочий пример. Обсудим, где проходит разрыв и какое решение стоит проверить первым.
Разобрать путь заказа в компании ↗