← На главную

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

Вариант 1. Универсальный обмен данными XML на основе правил конвертации (КД 2)

Если конфигурации сильно кастомизированы, имеют разные структуры реквизитов или обмен требуется запускать вручную по мере закрытия расчетного периода, классическим решением выступает разработка правил обмена в конфигурации 1С:Конвертация данных 2. Разберем этот процесс по шагам:

1. Выгружаем метаданные базы-источника и базы-приемника с помощью внешней обработки MD83Exp.epf (или соответствующей версии для используемой платформы) в отдельные XML-файлы.
2. Загружаем структуры метаданных обеих конфигураций в информационную базу «Конвертация данных, редакция 2».
3. Создаем правила конвертации объектов (ПКО) для документа отражения зарплаты, а также зависимых справочников (организации, статьи затрат, способы отражения, физические лица).
4. Настраиваем правила синхронизации ключевых реквизитов (полей поиска), чтобы избежать дублирования элементов.
5. Выгружаем готовый файл правил конвертации.
6. Для выполнения ручного обмена используем типовые внешние обработки V8Exchan82.epf или V8Exchan83.epf (обработка «Универсальный обмен данными в формате XML»). В базе-источнике выбираем файл правил, задаем период выборки документов и выгружаем данные в XML-файл, после чего в базе-приемнике загружаем полученный файл через ту же обработку.

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

Вариант 2. Штатная синхронизация через универсальный формат (EnterpriseData)

В современных типовых решениях на базе Библиотеки стандартных подсистем (БСП) ручное написание правил в КД 2 больше не требуется. Для регулярного взаимодействия между конфигурациями применяется универсальный формат EnterpriseData (КД 3). Рассмотрим особенности этого подхода:

1. В обеих конфигурациях переходим в раздел администрирования и открываем пункт Синхронизация данных.
2. Создаем новую настройку синхронизации, выбрав соответствующую программу-корреспондента.
3. В качестве канала связи выбираем общий каталог, сетевую папку, FTP-сервер или веб-сервис базы-приемника.
4. На этапе первоначальной настройки выполняем интерактивное сопоставление объектов: организаций, подразделений, статей затрат и способов отражения зарплаты в бухучете.
5. Настраиваем расписание регламентного задания для регулярной автоматической передачи данных без участия пользователя.

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

При переносе данных по зарплате специалисты часто сталкиваются с дублированием элементов справочников в базе-приемнике. Разберем основные причины этого поведения и способы их устранения:

1. Несовпадение ключевых реквизитов физических лиц: алгоритмы сопоставления по умолчанию ищут совпадения по комбинации «ИНН», «СНИЛС» либо «ФИО + Дата рождения + Документ, удостоверяющий личность». Наличие лишних пробелов, дефисов или отсутствие одного из реквизитов в одной из баз приводит к тому, что алгоритм создает новую запись. Для решения проблемы необходимо предварительно выверить персональные данные или выполнить интерактивное сопоставление в окне предварительного просмотра синхронизации перед первой загрузкой. Система сохранит соответствия в регистре сведений СоответствияОбъектовИнформационныхБаз.
2. Различия в наименованиях аналитики: справочники СтатьиЗатрат и СпособыОтраженияЗарплатыВБухучете сопоставляются по наименованию. Различие в регистре букв или концевой пробел приведут к дублю. Важно синхронизировать наименования этих объектов до запуска обмена.

Оптимизация: переход на сводный учет расчетов с персоналом

Если бухгалтерии не требуется детализированный пофамильный учет на счете 70, проанализируем возможность включения сводного режима. Это кардинально упрощает интеграцию и снижает нагрузку на систему:

1. В параметрах учета зарплаты бухгалтерской программы устанавливаем признак учета расчетов с персоналом Сводно по всем работникам.
2. В зарплатной базе документ отражения формируется либо сводно, либо алгоритм выгрузки сворачивает проводки по сотрудникам в одну общую сумму.
3. В результате отпадает необходимость переносить сотни и тысячи элементов справочников ФизическиеЛица и Сотрудники, база данных бухгалтерии не разрастается, а риск задвоения справочников сводится к нулю.

Архитектурные ограничения и тонкости реализации

При выборе способа интеграции важно учитывать технические ограничения платформы:

1. Почему не подходит РИБ: механизм распределенной информационной базы предназначен исключительно для репликации баз с идентичной конфигурацией и структурой данных. Использовать РИБ для выборочной передачи зарплатных документов в учетную базу нельзя, так как это приведет к конфликту метаданных, нумерации и неконтролируемой перезаписи справочников.
2. Ограничения прямого COM-соединения: технология COMConnector чувствительна к окружению. Она не поддерживается на серверах под управлением Linux, требует строго одинаковой версии платформы 1С на обеих сторонах и вызывает ошибки при несовпадении битности (32/64-разрядный клиент и сервер). Обмен через транспортные файлы или веб-сервисы гораздо надежнее.
3. Транзакционные блокировки: документ отражения зарплаты крупной организации может содержать десятки тысяч строк. Проведение такого документа способно вызвать длительные блокировки регистров бухгалтерии. Рекомендуется настраивать автоматический обмен на нерабочие часы или разбивать выгрузку по отдельным организациям и подразделениям.

Альтернативные варианты обмена

Для высоконагруженных систем или при нестандартной архитектуре баз можно использовать современные веб-технологии:

1. HTTP-сервисы: на стороне принимающей базы публикуется собственный HTTP-сервис. База-источник отправляет данные документа в виде JSON или XML-пакета. Приемник десериализует данные, программно формирует документ отражения зарплаты и проводит его. Метод полностью кроссплатформенный и не зависит от разрядности сервера.
2. Стандартный интерфейс OData: публикация базы на веб-сервере позволяет обращаться к документу отражения зарплаты и связанным объектам через стандартные REST-запросы (POST/PATCH), что исключает необходимость доработки конфигурации-приемника.