Как избежать задвоения плана счетов ЕПСБУ при переносе данных в 1С:БГУ 2.0

← На главную

При объединении баз или переносе данных в конфигурации «Бухгалтерия государственного учреждения 2.0» (БГУ 2.0) через инструмент «Конвертация данных 2.1» специалисты часто сталкиваются с критической проблемой: план счетов ЕПСБУ задваивается. Это приводит к тому, что в переносимых документах подставляются некорректные счета-дубли, нарушается логика учета (например, забалансовый счет создается как балансовый), и процесс загрузки прерывается с ошибками.

В этой статье мы подробно разберем, почему стандартные механизмы поиска «по коду» не работают в БГУ 2.0, и проанализируем пошаговый алгоритм настройки правил конвертации объектов (ПКО) для корректного сопоставления счетов.

В чем причина дублирования счетов в БГУ 2.0?

Давайте разберем ситуацию. В обычной «Бухгалтерии предприятия» (БП 3.0) большинство счетов являются предопределенными, и их сопоставление происходит по внутреннему имени. В БГУ 2.0 ситуация иная: счета ЕПСБУ не являются предопределенными элементами (за исключением служебных 00 и 000). План счетов заполняется динамически при первом запуске базы или через классификаторы.

Рассмотрим основные причины, по которым поиск дает сбой:

Разные внутренние идентификаторы (GUID): Если базы создавались независимо, то даже у идентичных счетов (например, 101.34) GUID-ы будут разными. Поиск по «внутреннему идентификатору» в таких условиях всегда будет создавать новый объект.
Неуникальность кодов: Это ключевая особенность БГУ. В плане счетов могут существовать несколько записей с одним и тем же визуальным кодом. Например, счета 17 и 18 могут повторяться для разных целей (забалансовые счета). Если в правилах поиска (ПКО) указан только Код, система может найти первый попавшийся счет или создать дубль из-за несовпадения других скрытых реквизитов.
Поле «Порядок»: В платформе 1С для планов счетов существует служебное поле Порядок. Оно определяет иерархию и часто критично для поиска, но по умолчанию в ПКО оно может не использоваться как поле поиска.

Шаг 1: Правильная настройка ПКО для плана счетов

Проанализируем настройки правила конвертации объектов (ПКО) для плана счетов ЕПСБУ. Нам необходимо отойти от стандартного поиска по одному полю. В настройках ПКО на закладке «Настройки поиска» следует выполнить следующие действия:

Отключите флаг «Искать объект приемника по внутреннему идентификатору объекта источника», если вы уверены, что базы «не родственные» (создавались не из одного бэкапа).
Установите флаг «Продолжить поиск по полям поиска, если по идентификатору объект приемник не найден».
В списке реквизитов (ПКС) отметьте как «Поля поиска» следующую комбинацию:
- Код
- Забалансовый (это критически важно для разделения счетов с одинаковыми кодами)
- ВидСчета
- Наименование (опционально)

Шаг 2: Реализация сложного поиска через обработчик «Поля поиска»

Если стандартные галочки не помогают, нам потребуется написать алгоритм сопоставления вручную. Рассмотрим пример кода, который нужно разместить в обработчике «Поля поиска» в ПКО плана счетов. Этот метод гарантирует, что система найдет нужный счет даже при сложных условиях.


// Пример в обработчике "Поля поиска" (ПКО ЕПСБУ)
Если НомерВариантаПоиска = 1 Тогда
    // Пытаемся найти счет по комбинации ключевых полей
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ЕПСБУ.Ссылка
        |ИЗ
        |   ПланСчетов.ЕПСБУ КАК ЕПСБУ
        |ГДЕ
        |   ЕПСБУ.Код = &Код
        |   И ЕПСБУ.Забалансовый = &Забалансовый
        |   И ЕПСБУ.ВидСчета = &ВидСчета";
    
    Запрос.УстановитьПараметр("Код", СвойстваПоиска.Получить("Код"));
    Запрос.УстановитьПараметр("Забалансовый", СвойстваПоиска.Получить("Забалансовый"));
    Запрос.УстановитьПараметр("ВидСчета", СвойстваПоиска.Получить("ВидСчета"));
    
    РезультатЗапроса = Запрос.Выполнить();
    Если НЕ РезультатЗапроса.Пустой() Тогда
        Выборка = РезультатЗапроса.Выбрать();
        Выборка.Следующий();
        СсылкаНаОбъект = Выборка.Ссылка;
    КонецЕсли;
КонецЕсли;

Использование такого подхода позволяет нам четко идентифицировать объект в базе-приемнике. Обратите внимание, что реквизиты Забалансовый и ВидСчета должны быть переданы из источника (у них должны стоять галочки «Передавать в данные выбора»).

Шаг 3: Синхронизация по полю «Порядок»

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

Шаг 4: Предотвращение создания новых объектов

Если ваша задача — только сопоставить данные и вы уверены, что план счетов в обеих базах идентичен по наполнению, установите в ПКО настройку «Не создавать новый объект в приемнике, если он не найден». Однако будьте осторожны: если в приемнике действительно отсутствует какой-то редкий счет, используемый в документах, загрузка документа не удастся.

Важный нюанс: Если вы используете эту настройку, обязательно проверьте, чтобы в ПКС для счетов не было установлено обязательное заполнение, иначе ошибка возникнет еще на этапе парсинга XML.

Почему «Выгрузка-загрузка XML» через GUID — плохой выбор?

Рассмотрим ситуацию, упомянутую в обсуждении: использование стандартной обработки «Выгрузка и загрузка данных XML». Эта обработка работает исключительно по внутренним идентификаторам (GUID). Если вы переносите данные между базами, которые не являются копиями друг друга, эта обработка гарантированно создаст дубли всех счетов и справочников. Пользоваться ею в данном случае можно только после предварительного «выравнивания» GUID-ов, что является трудоемкой задачей.