Отчёт по дебиторской задолженности из нескольких систем: как объединить 1С, CRM и банк в одну картину
Содержание 10 разделов
Когда продажи, расчёты и деньги живут в разных системах, вопрос «сколько нам должны» перестаёт быть простой выгрузкой. В 1С отражены документы и проводки, в CRM — договорённости менеджера и обещанные даты оплаты, в банке — фактическое движение денег. Каждая система описывает свою часть процесса и обновляется в собственном ритме. Поэтому механическое сложение таблиц почти неизбежно создаёт дубли, неподтверждённые оплаты и спорные остатки.
Рабочий отчёт начинается не с выбора диаграммы, а с определения правил: какая система отвечает за сумму обязательства, что считается оплатой, по какой дате возникает просрочка и как распределять один платёж между несколькими документами. Ниже — архитектура, которую можно адаптировать к типовой или доработанной 1С, любой CRM и нескольким расчётным счетам.
Разведите роли систем до начала интеграции
Одна и та же сделка выглядит по-разному для бухгалтерии, отдела продаж и казначейства. Если не назначить владельца каждого показателя, спор между цифрами просто переместится из Excel в BI-систему.
1С отвечает за учётное обязательство
Обычно именно в 1С следует брать организацию, контрагента, договор, документ расчётов, валюту, сумму реализации, корректировки и учтённую оплату. Это не означает, что любая запись в базе автоматически верна: закрытие периода, ручные операции и обмены тоже требуют контроля. Но для регламентированной суммы долга нужен один формально утверждённый источник. Если компания ведёт несколько баз, правило задают отдельно для каждой организации и вида расчётов.
CRM объясняет коммерческий контекст
CRM дополняет долг ответственным менеджером, сделкой, воронкой, причиной задержки, обещанной датой и результатом последнего контакта. Эти сведения полезны для взыскания, но не должны безусловно заменять учётную сумму. Например, перенос даты менеджером можно хранить как новое обещание клиента, сохраняя исходный срок оплаты для честного расчёта просрочки.
Банк подтверждает движение денег
Банковская выписка даёт дату, сумму, назначение, плательщика и идентификатор операции. Она нужна для оперативного обнаружения поступления, особенно если обмен с 1С выполняется позже. При этом «деньги пришли в банк» и «оплата корректно разнесена по документам» — разные состояния. Отчёт должен показывать оба и не погашать конкретный долг автоматически, если правило распределения неоднозначно.
Зафиксируйте единицу учёта задолженности
Документ, обязательство и платёж — не одно и то же
Удобная минимальная единица витрины — открытое обязательство: организация, контрагент, договор, документ-основание, дата возникновения, срок оплаты, валюта, исходная сумма и непогашенный остаток. Отдельно хранят платежи и таблицу их распределения. Такая модель поддерживает частичную оплату, один платёж на несколько реализаций, аванс, возврат и корректировку без перезаписи истории.
Если расчёты ведутся по договору в целом, искусственно распределять остаток по накладным нельзя. В этом случае гранулярность отчёта должна повторять настройку взаиморасчётов в 1С. Иначе красивый список просроченных документов будет расходиться с оборотно-сальдовой ведомостью, хотя общая сумма случайно совпадёт.
Aging считается от утверждённой даты
Для каждого обязательства нужна дата погашения: договорная, рассчитанная по условию отсрочки или введённая вручную по контролируемому процессу. Число дней просрочки считают на выбранную отчётную дату, а не на время последней загрузки. Интервалы aging — например, не наступил срок, небольшая, средняя и длительная просрочка — настраивают под цикл продаж компании. Границы должны храниться в настройках, чтобы их изменение не требовало переписывать запросы.
Соберите минимальный, но достаточный набор данных
Поля из 1С
Помимо суммы и дат выгружают стабильные идентификаторы объектов, организацию, контрагента, договор, документ расчётов, вид операции, валюту, подразделение и состояние проведения. Полезно передавать дату изменения записи: она позволяет забирать только новые и исправленные объекты. Для интеграции платформа 1С поддерживает несколько штатных механизмов, включая REST-интерфейс OData, HTTP-сервисы и другие способы, собранные в официальном разделе об интеграции прикладных решений. Выбор зависит от конфигурации, объёма и допустимой нагрузки.
Поля из CRM и банка
Из CRM нужны внутренний ID сделки, ответственный, компания, реквизиты или внешний ID контрагента, номер договора, плановая дата оплаты, стадия и дата последнего значимого действия. Из банка — уникальный ID операции, счёт получателя, дата проводки, сумма, валюта, ИНН или другой идентификатор плательщика и назначение. Телефон и название компании не подходят в качестве главного ключа: они меняются и записываются неодинаково.
Обязательно храните исходное значение рядом с нормализованным. Тогда ошибку сопоставления можно разобрать без повторного запроса к источнику. Для каждого поля полезно указать владельца и правило приоритета: например, ИНН берётся из 1С, менеджер — из CRM, дата банковского поступления — из выписки.
Постройте интеграцию через промежуточный слой
Сначала загрузка, затем нормализация
Надёжная схема состоит из трёх зон. В сырой слой данные попадают почти без изменений и с техническими полями: источник, время получения, версия и идентификатор загрузки. В нормализованном слое приводятся типы, валюты, даты и справочники. В итоговой витрине рассчитываются остаток, просрочка, интервал aging и управленческие признаки. Такое разделение позволяет повторить расчёт после изменения правил, не запрашивая всю историю заново.
Инкрементальная загрузка должна быть идемпотентной: повтор одной и той же порции не создаёт вторую запись. Удаления и отмены нельзя просто терять; их передают отдельным состоянием либо регулярно сверяют полным снимком. Для больших баз обмен запускают небольшими порциями, контролируют длительность запросов и не выполняют тяжёлые выборки в рабочее время без оценки нагрузки.
Снимок на дату сохраняет историю
Текущий остаток отвечает на оперативный вопрос, но не показывает, каким долг был в конце прошлого месяца. Поэтому вместе с событиями полезно хранить ежедневные или периодические снимки открытой задолженности. Тогда можно анализировать динамику, скорость погашения и миграцию суммы между интервалами просрочки. Исторический снимок не следует пересчитывать молча после каждой поздней корректировки: лучше хранить дату факта и дату получения изменения.
Настройте сопоставление без опасной магии
Иерархия ключей важнее нечёткого поиска
Сначала применяют точные связи: внешний ID, GUID 1С, номер договора в согласованном формате, ИНН вместе с организацией и банковским счётом. Затем — контролируемые составные правила. Нечёткое сравнение названий оставляют для очереди ручной проверки, а не для автоматического погашения. У каждого совпадения должны быть метод, степень уверенности и дата решения.
Особое внимание требуется группам компаний, обособленным подразделениям, агентским схемам и платежам от третьих лиц. Совпадение ИНН плательщика с контрагентом не всегда достаточно. Таблица соответствий должна поддерживать период действия: после реорганизации старые документы обязаны продолжать связываться по правилам, действовавшим на их дату.
Нераспознанный платёж остаётся отдельным состоянием
Если назначение не позволяет выбрать документ, платёж попадает в очередь разбора. В сводке его можно показать как поступление, ожидающее распределения, но нельзя уменьшать произвольную просрочку. После подтверждения создаётся явная связь между платежом и обязательством, а решение фиксируется в журнале. Это делает итог объяснимым для бухгалтера и менеджера.
Встройте проверки качества в каждую загрузку
Главная контрольная сумма — совпадение открытого остатка витрины с утверждённым отчётом 1С на одну дату и в одной аналитике. Дополнительно сравнивают число документов, суммы реализаций, оплат, авансов, корректировок и нераспределённых операций. Проверки выполняют по организации и валюте, иначе встречные отклонения могут скрыть друг друга.
- нет ли дублей по ключу источника и версии;
- не превышает ли распределённая оплата сумму платежа;
- не стал ли остаток отрицательным без допустимой операции;
- есть ли срок оплаты у документов, попадающих в aging;
- какова доля сделок и платежей без уверенного соответствия;
- не остановилась ли загрузка одного из источников.
Ошибку важно показывать рядом с отчётом, а не скрывать в техническом журнале. Если банковские данные обновились, а 1С недоступна, пользователь должен видеть время актуальности каждого источника и понимать, какие показатели предварительные.
Сделайте отчёт инструментом действий
Первый экран — сумма, риск и ответственность
На верхнем уровне показывают общий открытый долг, просроченную часть, распределение по интервалам, крупнейшие концентрации и динамику. Фильтры — организация, подразделение, менеджер, клиент, договор, валюта и дата снимка. Любая карточка должна раскрываться до документов, платежей и истории контакта, иначе менеджеры продолжат сверять цифры вручную.
Очередь работы полезнее ещё одной диаграммы
Практический список включает клиента, остаток, старейший срок, обещанную дату, последнее действие, ответственного и следующий шаг. Отдельные очереди нужны для нераспределённых платежей, отсутствующих сроков, спорных соответствий и долгов без владельца. Напоминания формируются по прозрачным правилам и не заменяют исходную сумму в учёте.
При необходимости такую витрину и регламент сверки можно оформить как отдельный проект — например, услугу по отчёту дебиторской задолженности из 1С в Битрикс24. До начала разработки всё равно стоит согласовать гранулярность взаиморасчётов и контрольный отчёт.
Внедряйте по проверяемым этапам
- Инвентаризация. Зафиксируйте базы, организации, виды договоров, банковские счета, CRM-поля и владельцев данных.
- Прототип. Возьмите ограниченный период и одну организацию, соберите обязательства и оплаты без сложной визуализации.
- Сверка. Сравните остаток с 1С, разберите каждое существенное отклонение и уточните правила.
- Коммерческий контекст. Подключите CRM, справочник соответствий и очередь нераспознанных записей.
- История и автоматизация. Добавьте снимки, расписание, уведомления и мониторинг задержек.
- Приёмка. Проверьте роли доступа, сценарий повторной загрузки, отмены документов и восстановление после сбоя.
Критерии готовности лучше формулировать числами процесса, но пороги выбирать по реальным данным компании: допустимое отклонение контрольной суммы, максимальная задержка загрузки и доля записей, требующих ручной привязки. Универсальные значения здесь только создают ложное ощущение точности.
Когда достаточно отчёта 1С, а когда нужна витрина
Если продажи и оплаты полностью отражаются в одной базе, единообразно ведутся договоры и всем пользователям доступен нужный разрез, штатного отчёта может быть достаточно. Внешняя витрина оправдана, когда есть несколько баз или юридических лиц, банк обновляется раньше учёта, менеджеры работают в CRM, нужна история снимков либо единая очередь взыскания.
Не стоит начинать с хранилища ради самого хранилища. Иногда главная проблема решается обязательным внешним ID в CRM и дисциплиной назначения платежа. Но если источников несколько, явная модель и журнал сопоставления надёжнее бесконечной ручной склейки файлов.