При интеграции 1С:Бухгалтерии с CRM-системами, такими как Битрикс24, часто возникает задача сквозного отслеживания взаиморасчетов в разрезе конкретных сделок. Ситуация усложняется тем, что первичный документ создается в CRM, затем загружается в виде счета на оплату в 1С, после чего бухгалтер оформляет документы отгрузки и оплаты. Рассмотрим архитектурные особенности конфигурации, проанализируем ограничения платформы и разберем проверенные способы решения задачи.
Прежде чем выбирать способ реализации, выясним причину, по которой нельзя просто добавить аналитику на счет учета расчетов. На счетах 62.01 («Расчеты с покупателями и заказчиками») и 62.02 («Расчеты по авансам полученным») в типовой конфигурации уже задействованы все три доступных субконто:
Платформа 1С:Предприятие имеет системное ограничение: на счете бухгалтерского учета поддерживается не более трех субконто. Добавить четвертое субконто Сделка невозможно. Кроме того, документ СчетНаОплатуПокупателю не делает проводок в бухгалтерском учете и не может служить расчетным документом для субконто.
Также важно учитывать требования дальнейшей выгрузки данных через интерфейс OData в системы управленческого учета. Стандартные дополнительные реквизиты объекта хранятся в табличных частях, а дополнительные сведения — в независимом регистре сведений ДополнительныеСведения. Фильтрация и выборка по ним через стандартный протокол OData сопряжены со сложностями построения запросов с составными ключами и низкой производительностью.
Разберем основные практические подходы к организации учета по сделкам и хранения внешнего идентификатора.
Проанализируем классический методический подход, который позволяет получить детальный учет по сделкам без изменения метаданных конфигурации. В типовом решении субконто Договоры позволяет вести расчеты обособленно по каждому основанию.
Для сохранения общей аналитики и одновременного разделения расчетов по сделкам используем иерархическую структуру справочника ДоговорыКонтрагентов:
СчетНаОплатуПокупателю, РеализацияТоваровУслуг и банковских выписках указывается именно этот конкретный подчиненный договор сделки.Преимущества подхода: взаиморасчеты, зачеты авансов, переуступка долга и факторинг замыкаются строго в рамках сделки (договора). Стандартная оборотно-сальдовая ведомость по счету 62 с группировкой по иерархии договоров сразу показывает как общий итог по контрагенту, так и детализацию по каждой отдельной сделке.
Если специфика учета требует ведения расчетов строго по одному общему договору, настроим связь через цепочку документов и расширение конфигурации (CFE). Разберем эту схему по шагам.
Шаг 1. Связывание реализации со счетом
В документе Реализация (акт, накладная, УПД) присутствует штатный реквизит шапки СчетНаОплату (тип ДокументСсылка.СчетНаОплатуПокупателю). Если реализация создается на основании счета или заполняется программно, этот реквизит связывает реализацию со счетом на уровне типовых механизмов без необходимости вводить дублирующие поля.
Шаг 2. Хранение внешнего идентификатора
Для корректной и быстрой отдачи данных по OData лучшим решением является добавление собственного объекта через расширение. Здесь возможны два варианта:
ИД_СделкиБитрикс (тип Строка) в документы СчетНаОплатуПокупателю и РеализацияТоваровУслуг. При публикации интерфейса OData эти реквизиты попадают напрямую в сущности документов, что исключает сложные запросы к дополнительным свойствам.СделкиБитриксПоОбъектам).
Объект (составной тип: ДокументСсылка.СчетНаОплатуПокупателю, ДокументСсылка.РеализацияТоваровУслуг).ИдентификаторСделки (тип Строка).InformationRegister_СделкиБитриксПоОбъектам, к которой легко применять стандартную фильтрацию $filter=ИдентификаторСделки eq 'ID_ИЗ_CRM'.
Посмотрим на пример заполнения реквизита при программном создании реализации на основании счета в коде обмена:
// Создание документа реализации на основании счета
ДокументРеализация = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
ДокументРеализация.Заполнить(СчетСсылка);
// Устанавливаем типовую связь
ДокументРеализация.СчетНаОплату = СчетСсылка;
// Заполняем реквизит расширения
ДокументРеализация.ИД_СделкиБитрикс = ИдентификаторСделкиБитрикс;
ДокументРеализация.Записать(РежимЗаписиДокумента.Запись);
Когда бухгалтерия запрещает дробить договоры, а в учете присутствуют сложные операции (автоматический зачет авансов по методу ФИФО, взаимозачеты через документ КорректировкаДолга, факторинговые схемы), бухгалтерские проводки по счету 62 неизбежно «перемешают» оплаты и отгрузки разных сделок одного договора.
В этом случае организуем управленческий учет взаиморасчетов независимо от регламентированного:
ВзаиморасчетыПоСделкам.Контрагент, ИдентификаторСделки, ДокументРасчетов и ресурс Сумма.ОбработкаПроведения документов движения расчетов (платежи, реализации, корректировки) формируем записи в этот регистр. При проведении платежа анализируется счет или явное указание сделки, и долг гасится адресно по сделке.Именно данные этого регистра выгружаются через стандартный интерфейс OData в управляющую базу, обеспечивая стопроцентную точность управленческой задолженности без перегрузки и переделки плана счетов бухгалтерского учета.