Как использовать режим без начисления зарплаты в 1С:ЗУП 3 и организовать обмен для кадровой базы?

В конфигурации 1С:Зарплата и управление персоналом 3 предусмотрена функциональная опция Не использовать начисление зарплаты. При ее включении база переходит в чисто кадровый режим. Однако при попытке выстроить архитектуру с разделением на отдельную кадровую базу и расчетную базу специалисты сталкиваются с отсутствием типовых механизмов синхронизации формата «ЗУП — ЗУП». Разберем, какая методология заложена разработчиками в этот режим, почему нет готового обмена и какими способами можно организовать разделение кадровых и расчетных данных.

Назначение режима и методология функциональной опции

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

Основными сценариями использования такого режима являются:

1. Ведение расширенного кадрового и управленческого HR-учета: база используется для детализированного учета структуры компании, замещений, исполнения обязанностей (ВрИО), подбора, обучения, оценки и грейдирования персонала, в то время как расчет заработной платы и налогов выполняется во внешней ERP-системе или сторонней расчетной программе.
2. Интеграция с корпоративным контуром: кадровая база ЗУП выступает мастер-системой для корпоративного документооборота (1С:Документооборот) и систем контроля доступа (СКУД), где критически важна актуальная оргструктура и цепочки согласования, но отсутствует необходимость в данных о начислениях.
3. Унификация библиотек: подсистемы зарплаты и кадров унифицированы для всей линейки прикладных решений (1C:ERP, 1С:Комплексная автоматизация, 1С:ЗУП). Данная опция позволяет гибко отключать неиспользуемые блоки в зависимости от архитектуры предприятия.

Почему в 1С:ЗУП 3 отсутствует типовой обмен «ЗУП (кадры) — ЗУП (расчет)»

Выясним причину, по которой фирма «1С» не реализовала готовый механизм синхронизации между двумя идентичными конфигурациями ЗУП. В редакции 3.0 и 3.1 архитектура учета кардинально отличается от редакции 2.5:

1. Единые кадрово-расчетные документы: большинство ключевых документов (например, ПриемНаРаботу, КадровыйПеревод) совмещают в себе как кадровые реквизиты (подразделение, должность, график работы), так и расчетные (тарифная ставка, плановые начисления, аванс). Разделение этих данных на две разные базы разрывает логику проведения документов и нарушает ссылочную целостность.
2. Механизм автоматических перерасчетов: проведение кадровых документов задним числом регистрирует записи в регистрах сведений и инициирует внутренние механизмы перерасчета заработной платы. В двух раздельных базах этот механизм не может функционировать бесшовно.
3. Назначение формата EnterpriseData: стандартный протокол обмена предназначен для передачи нормативно-справочной информации и итоговых сводных проводок (ОтражениеЗарплатыВБухучете), но не для синхронизации незавершенных оперативных кадровых документов с целью их последующего досчета в другой базе.

Вариант 1. Единая база с разграничением прав доступа (рекомендуемый подход)

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

Разберем по шагам, как реализуется этот сценарий:

1. Настройка профилей групп доступа: кадровикам назначается типовой профиль Кадровик без прав на просмотр зарплатных данных и расчетных документов. При необходимости включается механизм ограничения доступа на уровне записей (RLS).
2. Многоэтапное проведение документов: в документах кадрового учета кадровик заполняет свою часть и ставит признак подтверждения кадровых данных. Расчетчик видит документ в расчетном списке, указывает условия оплаты труда и завершает расчет установкой флажка «Расчет утвердил».

Такой подход исключает рассинхронизацию справочников, устраняет дублирование ввода и сохраняет полную функциональность механизмов перерасчетов.

Вариант 2. Разработка правил синхронизации в «1С:Конвертация данных»

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

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

1. Синхронизация мастер-данных: настраиваем правила выгрузки для справочников ФизическиеЛица, Сотрудники, Подразделения, Должности и ШтатноеРасписание. Синхронизация выполняется по уникальным идентификаторам (GUID), СНИЛС или кодам.
2. Односторонняя передача кадровых приказов: кадровые документы транслируются из базы «Кадры» в базу «Расчет». При переносе табличные части с начислениями не перезаписываются, чтобы не затирать расчетные данные, введенные в целевой базе.
3. Исключение расчетных регистров: регистры сведений и накопления расчетного блока формируются непосредственно в целевой базе при повторном проведении расчетчиком.

Вариант 3. Интеграция через HTTP-сервисы и API

Рассмотрим современный программный вариант интеграции. В кадровой базе настраивается публикация событий через HTTP-сервисы или брокеры сообщений. При изменении кадрового статуса сотрудника формируется JSON-пакет, передаваемый в расчетную базу.

Посмотрим на пример программной обработки входящего кадрового события в HTTP-сервисе расчетной базы:

Функция ОбработатьКадровоеСобытие(ДанныеЗапроса)
    
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(ДанныеЗапроса);
    ДанныеСобытия = ПрочитатьJSON(ЧтениеJSON);
    ЧтениеJSON.Закрыть();
    
    // Поиск физического лица по ключевому идентификатору (СНИЛС)
    ФизЛицо = Справочники.ФизическиеЛица.НайтиПоРеквизиту("СтраховойНомерПФР", ДанныеСобытия.СНИЛС);
    
    Если Не ЗначениеЗаполнено(ФизЛицо) Тогда
        // Создание нового физического лица при отсутствии
        ФизЛицоОбъект = Справочники.ФизическиеЛица.СоздатьЭлемент();
        ФизЛицоОбъект.Наименование = ДанныеСобытия.ФИО;
        ФизЛицоОбъект.СтраховойНомерПФР = ДанныеСобытия.СНИЛС;
        ФизЛицоОбъект.Записать();
        ФизЛицо = ФизЛицоОбъект.Ссылка;
    КонецЕсли;
    
    Возврат Новый HTTPСервисОтвет(200);
    
КонецФункции

Использование программных интерфейсов позволяет точно контролировать состав передаваемых реквизитов и гарантировать целостность данных в обеих системах.