Оплата из 1С в сделке Битрикс24: как вернуть в воронку факт прихода денег

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

Обратный поток «оплата в 1С → стадия сделки» закрывает этот разрыв. Разберу, как он устроен, где ломается сопоставление счёта со сделкой и где проходит граница между штатным обменом и доработкой.

Почему приход денег не виден в воронке

Стадию сделки в этой ситуации двигает не поступление, а человек. Менеджер помнит, что деньги пришли, и переносит сделку дальше — либо не помнит, и сделка висит открытой при закрытой оплате. Финансы в это время сводят приход по банку и 1С. Две картины выручки расходятся, и любой разговор о плане упирается в вопрос «а это уже оплачено или ещё обещание».

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

Как устроен обратный поток «оплата → стадия»

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

Приход раскладывается по стадиям. Частичная оплата в 1С переводит сделку в «Частично оплачено», полная — в «Оплачено полностью». Это разделяет предоплаты и закрытые суммы прямо в воронке, и РОП видит, сколько уже пришло по каждой сделке.

Рядом со сменой стадии в карточку из реестра документов 1С подгружаются печатные формы — счета, заказы, УПД. Подтверждение оплаты и первичка лежат в одном окне сделки, поэтому проверка не требует прыжков между системами.

Синхронизация статуса оплаты работает в трёх режимах — реальное время, по расписанию и ручной запуск. От режима зависит, насколько свежий приход видит РОП в воронке. Точные интервалы обмена «по расписанию» в открытых описаниях не названы, поэтому реальную задержку — минуты это или часы — я закладываю в техническое задание и проверяю на конкретной сборке.

Сопоставление счёта и сделки: где ломается атрибуция

Корректность всего обратного потока держится на единых идентификаторах. Контрагент и сделка должны узнавать друг друга в момент, когда прилетает оплата. Если этой связки нет, платёж не находит свою сделку либо садится не на ту.

Главный разрушитель отчётности здесь — дубли контрагентов. Один клиент заведён под разными ИНН и названиями, оплаты разносятся по разным карточкам, и привязка выручки к сделке и источнику рвётся. Никакая аналитика окупаемости на такой базе не соберётся: цифры по источникам будут смещены ровно на объём задвоенных контрагентов.

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

Граница штатного обмена и доработок

Здесь важно не питать иллюзий. При стандартной синхронизации из 1С в CRM обратно передаётся только статус сделки. Сумму реализации и незакрытый остаток по сделке штатный обмен не возит — для них нужны отдельные модули обмена документами. Обещания «полного цикла» у части подрядчиков расходятся с этой границей, поэтому глубину обратного потока — приходит ли сумма платежа, номер платёжного документа, дата — я проверяю по документации конкретной сборки и модуля.

Настройка обмена включает явное сопоставление полей платежа: статус, номер, дата, сумма, НДС. К нему добавляется прогон трёх-пяти сценариев обмена перед запуском. Типичные сбои, из-за которых деньги в воронке считаются неверно, повторяются из проекта в проект: односторонний обмен вместо двустороннего, рассинхрон НДС и валют, отсутствие журнала обмена, по которому можно разобрать спорный платёж. Всё это я закрываю на этапе настройки обмена 1С с Битрикс24, пока схема ещё на стенде.

Тем, кто уже возит номенклатуру и остатки, полезен разбор смежной задачи — что действительно нужно возить в обмене с 1С в опте: там про прямой поток, здесь — про один обратный поток денег.

Что обратный поток даёт для денег

Когда стадия сделки опирается на фактическое поступление из учётной системы, выручка привязывается к конкретной сделке и источнику без ручной сверки. Разделение частичных и полных оплат по стадиям показывает, сколько уже закрыто и сколько остаётся в предоплатах и остатках. Прогноз потока сделок начинает сверяться с реальными поступлениями, и продажи с финансами работают от одной картины выручки — так связку учёта и CRM описывает и зарубежная практика, механика та же для 1С и Битрикс24.

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

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

Как Бизнес-партнер 1С-Битрикс я собираю обратный поток так, чтобы стадия сделки означала деньги на счёте, а отчёт по выручке не требовал вечерней сверки выписки руками.