Связка amoCRM и 1С: как вернуть в сделку факт оплаты и отгрузки, чтобы окупаемость считалась по поступившим деньгам

Почему окупаемость по счетам расходится с окупаемостью по деньгам

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

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

Как устроен двусторонний обмен: деньги и отгрузка приходят из 1С

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

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

Где штатный виджет ограничивает передачу отгрузок

Здесь важно понимать границу коробочного решения. Штатный виджет amoCRM работает только с облачными конфигурациями 1С:Бухгалтерии — 1cfresh, БизнесСтарт, БухОбслуживание. Коробочные версии официально не поддерживаются.

Второе ограничение важнее для атрибуции. Из коробки обмен построен вокруг счёта: контрагент ищется по ИНН/КПП и подтягивается из 1С автоматически, новый контрагент создаётся в 1С после выставления счёта. Точки отгрузки и факта оплаты в сделку по такой логике не доходят — виджет закрывает связку по счетам. Для расчёта окупаемости по деньгам этого мало: в сделку должна возвращаться сумма поступившей оплаты, и до этого шага штатный виджет не дотягивается.

Что дорабатывается под торговые и производственные конфигурации

Чтобы связать не только бухгалтерию, но и торговые и производственные базы — Управление торговлей, Комплексную автоматизацию, ERP, Управление нашей фирмой, — интеграцию делают под конкретную базу. Инструменты разные: REST API, виджет, отдельный модуль или коннектор. Это работа на разработку под ваш учёт: готовый виджет из каталога такие конфигурации не покрывает.

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

От денежного факта в сделке к сквозной аналитике и ROMI

Дальше денежный факт из сделки уходит в аналитику. Передача фактических продаж и «денежных» статусов — оплаченные заказы, подписанные договоры, поступившие оплаты — даёт сквозную аналитику по всей воронке, от рекламного клика до поступивших денег.

Одна деталь, без которой цепочка не замыкается: для оптимизации рекламы в Яндекс.Директе по деньгам в сделке нужен проброшенный идентификатор пользователя — аналог ClientID Яндекс.Метрики. Без него денежный факт не связать с рекламным источником: сумма оплаты есть, а какой кампанией она приведена — неизвестно. Как этот идентификатор доводится до обучения автостратегий на оплаченных сделках, я разбирал в материале про офлайн-конверсии из amoCRM в Директ.

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

Сценарии, от которых зависит точность расчёта

Перед тем как строить ROMI на денежном факте, стоит проверить несколько сценариев. Частичные оплаты, авансы и возвраты определяют, какой суммой сделка попадёт в расчёт окупаемости. Обмен должен корректно проводить эти движения из 1С в статус и сумму сделки: аванс — это ещё не полная оплата, возврат уменьшает засчитанную выручку. Если эти движения игнорируются, окупаемость снова считается по приблизительным цифрам.

Публичные цифры интеграторов — сокращение времени обработки заказов, экономия часов у маркетинга — идут от заинтересованных сторон и к деньгам напрямую не привязаны. Их стоит проверять на своей базе, а не переносить в свой расчёт как данность.

И главная проверка: замкнута ли цепочка 1С → amoCRM → аналитика именно по деньгам. Одни статусы сделки эту цепочку не замыкают — в аналитику должна доходить сумма поступившей оплаты. Когда этот путь собран под вашу конфигурацию и проверен на частичных оплатах и возвратах, окупаемость рекламы наконец считается по деньгам, которые реально пришли на счёт.