Почему в 1С:Бухгалтерия 2.0 нет плана обмена с ЗУП и как настроить выгрузку?

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

Исторический механизм обмена в БП 2.0

Посмотрим на то, как изначально задумывался и реализовывался обмен данными во времена актуальности БП 2.0. В этой конфигурации действительно нет привычных современному разработчику узлов и планов обмена для ЗУП. Полноценная автоматическая двусторонняя синхронизация с отслеживанием измененных объектов (регистрацией изменений на узлах) появилась лишь в следующем поколении программ — на базе БП 3.0 с использованием формата обмена EnterpriseData.

Во времена БП 2.0 интеграция между зарплатной и бухгалтерской базами работала исключительно через односторонние файловые выгрузки и загрузки. Разберем подробнее алгоритм действий:

1. Обмен осуществлялся путем формирования файла в формате XML по правилам конвертации.
2. Выгрузка шла не по измененным объектам, а с жестким фильтром по периоду (например, за конкретный месяц).
3. Чтобы в БП 2.0 вообще появился механизм принятия таких файлов, необходимо было зайти в настройки программы.
4. В параметрах учета (или константах) требовалось установить флаг Использовать обмен с программами на платформе 8.2. Также важно было проверить параметр ведения учета зарплаты, указав, что он ведется во внешней программе.
5. После этого пользователю становилась доступна специальная кнопка или обработка «Загрузить из ЗУП», через которую считывался сгенерированный XML-файл.

Почему современная ЗУП 3.1 не передает проводки в БП 2.0?

Теперь проанализируем более глубокую проблему: почему актуальная версия ЗУП 3 (3.1) не может штатно обмениваться данными со старой Бухгалтерией 2.0. Выясним причину, которая кроется в кардинальной смене архитектуры 1С.

В старой версии ЗУП 2.5 бухгалтерские проводки (счета дебета и кредита, субконто) формировались непосредственно в самой зарплатной базе. Старая БП 2.0 умела принимать эти готовые проводки и просто записывала их у себя. Однако в современном поколении ЗУП 3.1 разработчики полностью изменили этот подход: программа больше не формирует бухгалтерские проводки на своей стороне.

Вместо формирования проводок в новой ЗУП создается специальный документ ОтражениеЗарплатыВБухучете. По задумке вендора, этот сводный документ должен выгружаться в современную Бухгалтерию (БП 3.0). И уже там, на стороне бухгалтерской программы, при проведении этого документа формируются проводки на основе настроенных в БП способов отражения зарплаты.

Так как БП 2.0 является морально устаревшей системой, она не знает о существовании документа ОтражениеЗарплатыВБухучете и не умеет штатно генерировать проводки по новой логике.

Как настроить обмен между ЗУП 3.1 и БП 2.0: рабочие сценарии

Поскольку официальной поддержки синхронизации между актуальной ЗУП 3.1 и БП 2.0 не существует, рассмотрим практические пути выхода из этой ситуации. На практике компании используют один из трех подходов:

1. Ручной ввод данных. Если компания небольшая (в штате 2-5 сотрудников) и начисления стандартные, бухгалтерам проще заносить сводные суммы вручную в конце месяца, используя документ ОперацияБух (операция, введенная вручную).
2. Разработка индивидуальных правил обмена. Используя инструмент «Конвертация данных 2.0», программисты пишут кастомные правила. Эти правила «на лету» трансформируют информацию из нового документа отражения в ЗУП 3.1 в понятные для БП 2.0 готовые бухгалтерские проводки.
3. Внешние обработки загрузки. Создаются или покупаются готовые внешние обработки. Они парсят выгруженный из ЗУП файл, сопоставляют справочники (сотрудники, подразделения, статьи затрат) и программно создают документы в БП 2.0.

Рассмотрим пример того, как в такой внешней обработке или в правилах конвертации (в обработчике «ПослеЗагрузки») может выглядеть код маппинга (сопоставления) подразделений при формировании проводок:

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

КонецЕсли;

Нюансы кастомного обмена: проблема подразделений

Проанализируем самую частую проблему при настройке нетипового обмена между этими базами — рассинхронизацию справочников подразделений. В ЗУП подразделения носят строгий регламентированный и кадровый характер (отдел кадров, бухгалтерия, цех сборки). В Бухгалтерии же справочник ПодразделенияОрганизаций чаще всего используется для финансового анализа, распределения доходов и затрат по центрам финансовой ответственности (ЦФО).

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

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