Как организовать выборочный перенос данных с признаком БУ между базами 1С и избежать подводных камней?

← На главную

При подготовке баз данных для внешнего аудита, контролирующих органов или разделения контуров учета часто возникает задача регулярной выгрузки информации из рабочей информационной базы в аналогичную базу-приемник. В конфигурации 1С:Комплексная автоматизация типовым требованием является перенос только тех документов, которые имеют признак отражения в регламентированном учете (крыжик БУ). Рассмотрим детально, с какими сложностями сопряжена такая выборочная синхронизация, как правильно обрабатывать изменения задним числом и какие архитектурные альтернативы существуют.

Главный подводный камень: снятие признака БУ задним числом

Проанализируем базовый сценарий: документ был создан, проведен по бухгалтерскому учету и успешно перенесен в базу аудиторов. Спустя некоторое время пользователь в рабочей базе снимает флаг БУ или распроводит документ по регламентированному учету. Если процедура обмена настроена стандартным образом по фильтру наличия флага, в базу-приемник этот документ больше не попадет. В результате в базе аудиторов останется устаревшая версия документа, которая продолжит формировать проводки и искажать отчетность.

Если документ помечается на удаление физически, платформа 1С регистрирует это событие автоматически. Но снятие признака БУ пометкой на удаление не является. Следовательно, в базе-приемнике такой объект необходимо либо удалять, либо программно снимать с него признак БУ и отменять проведение.

Реализация механизма выгрузки удаления через план обмена

Разберем по шагам, как решить проблему рассинхронизации с помощью механизма планов обмена и подписок на события. Чтобы база-приемник узнала о необходимости удалить объект или очистить его движения, нам необходимо принудительно зафиксировать событие удаления для узла плана обмена.

Создадим подписку на событие ПередЗаписью или ПриЗаписи для интересующих документов.
Сравним текущее состояние реквизита в объекте с ранее записанным значением в базе данных.
Если признак БУ изменился со значения Истина на Ложь, зарегистрируем в плане обмена объект типа УдалениеОбъекта.

Посмотрим на пример программной реализации такой регистрации изменений в подписке на событие:


// В обработчике подписки на событие ПередЗаписьюДокумента
Если НЕ Источник.ЭтоНовый() Тогда
    СсылкаНаДокумент = Источник.Ссылка;
    СтарыйФлагБУ = СсылкаНаДокумент.ОтражатьВРеглУчете; // Имя реквизита зависит от версии КА
    НовыйФлагБУ = Источник.ОтражатьВРеглУчете;
    
    Если СтарыйФлагБУ И НЕ НовыйФлагБУ Тогда
        // Флаг сняли: в базе-приемнике документ должен быть удален
        УзелОбмена = ПланыОбмена.ОбменСБазойАудита.НайтиПоКоду("AUDIT");
        Если ЗначениеЗаполнено(УзелОбмена) Тогда
            ОбъектУдаления = Новый УдалениеОбъекта(СсылкаНаДокумент);
            ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, ОбъектУдаления);
        КонецЕсли;
    КонецЕсли;
КонецЕсли;

При очередной выгрузке механизм сериализации сформирует сообщение обмена, содержащее элемент УдалениеОбъекта. При загрузке в базу-приемник документ будет корректно помечен на удаление или физически удален в зависимости от настроек правил конвертации данных.

Проблема партионного учета, остатков и расчета себестоимости

Рассмотрим следующий критический аспект. В конфигурации 1С:Комплексная автоматизация управленческий и регламентированный контуры тесно переплетены. Если в исходной базе часть цепочки товародвижения (например, поступление или перемещение) оформлена без признака БУ, а реализация — с признаком БУ, база-приемник столкнется с нехваткой складских остатков.

Попытка провести загруженные документы в базе аудиторов стандартным образом приведет к ошибкам:

Возникнут отрицательные остатки по регистрам товаров на складах и партий товаров.
Документы отгрузки откажутся проводиться из-за контроля остатков.
Процедура Закрытие месяца завершится аварийно или сформирует искаженную себестоимость, которая не совпадет с цифрами в рабочей базе.

Выясним причину: расчет себестоимости в КА представляет собой сложную систему линейных уравнений (СЛАУ), учитывающую все движения предприятия. Если массив данных урезан, математический расчет себестоимости неизбежно выдаст другой финансовый результат.

Выгрузка готовых движений вместо перепроведения

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

Выгружаются наборы записей регистра бухгалтерии и связанных регистров накопления.
В базе-приемнике у загруженных документов отключается автоматическое проведение. Запись наборов движений выполняется напрямую.
Регламентные операции закрытия месяца в базе-приемнике не запускаются повторно — результаты закрытия также переносятся в виде готовых проводок из базы-источника.

Такой подход гарантирует 100% идентичность бухгалтерской отчетности между рабочей базой и копией для аудиторов.

Цепочки взаиморасчетов и нормативно-справочная информация

Проанализируем еще две сопутствующие проблемы, возникающие при выборочном обмене:

Разрыв цепочек взаиморасчетов. Если банковская выписка проведена по БУ, а документ основания (заказ или реализация) остался только в управленческом учете, нарушится автоматический зачет авансов. На счетах 60 и 62 возникнут развернутые сальдо и некорректные курсовые разницы. При переносе необходимо строго отслеживать связанные цепочки документов.
Целостность НСИ. Документы содержат ссылки на контрагентов, договоры, номенклатуру, статьи расходов. Выгрузка справочников должна выполняться либо полностью, либо по ссылке при записи документов. Иначе появление "битых" ссылок приведет к невозможности формирования стандартных бухгалтерских отчетов (ОСВ, карточки счетов).

Альтернативные архитектурные решения

Постоянная поддержка выборочного обмена между двумя сложными базами уровня ERP/КА требует значительных ресурсов на доработку и мониторинг. Рассмотрим альтернативные варианты, которые часто оказываются более надежными и простыми в эксплуатации:

Регулярное создание полной копии с последующей очисткой. Создаем копию базы данных средствами СУБД (например, еженедельно или ежемесячно). В созданной копии запускается регламентный скрипт, который программно удаляет документы без признака БУ и очищает нерелевантные управленческие регистры. Это снимает проблему отслеживания изменений задним числом.
Использование механизма RLS (ограничение доступа на уровне записей). Создается полная копия рабочей базы, в которой для аудиторов настраивается отдельный профиль групп доступа с правилами RLS по реквизиту отражения в регламентированном учете. В этом случае синхронизация между базами не требуется вовсе — аудиторы видят только разрешенные данные в актуальном слепке базы.