При работе в распределенной информационной базе (РИБ) конфигурации 1С:Зарплата и управление персоналом 3.1 часто возникает классическая коллизия: в разных узлах (базах) ведется учет по разным подразделениям одной и той же организации. Когда наступает время формирования проводок, бухгалтеры в каждой базе создают документ Отражение зарплаты в бухучете. Однако из-за механизмов синхронизации данные начинают перемешиваться, затираться или дублироваться, превращая учет в хаос. Разберем подробно, как настроить систему так, чтобы каждая база «видела» только свои данные и не мешала другим.
Если в настройках РИБ установлен «полный обмен», то любой объект, созданный в Базе 1, неминуемо попадет в Базу 2 через Центр. Главная проблема документа Отражение зарплаты в бухучете в версии 3.1 заключается в том, что по умолчанию он создается «в целом по организации». Если бухгалтер в Базе 1 нажмет кнопку «Заполнить», программа соберет данные по всем сотрудникам организации, которые есть в этой базе. При синхронизации этот документ попадет в Базу 2. Если там бухгалтер создаст свой документ и тоже нажмет «Заполнить», система может либо создать дубликат (если номера разные), либо перезаписать данные, если не настроены префиксы. Проанализируем ситуацию и перейдем к решениям.
Малоизвестный, но крайне эффективный способ — использование реквизита Подразделение в шапке документа Отражение зарплаты в бухучете. Рассмотрим этот механизм подробнее:
Важный нюанс: если оставить поле «Подразделение» пустым, программа попытается подтянуть данные по всей организации. Установка этого фильтра в шапке — первый шаг к изоляции данных внутри документа.
Чтобы документы из разных узлов не конфликтовали по номерам и не замещали друг друга, выясним, настроены ли уникальные префиксы. Проанализируем настройки в разделе Администрирование — Синхронизация данных.
Каждому узлу должен быть присвоен свой код (например, «Б1» для первой базы и «Б2» для второй). В этом случае документы будут иметь вид Б1-000001 и Б2-000001. В центральной базе они будут существовать как два независимых объекта. Это предотвратит ситуацию, когда База 2 «думает», что документ 000001 — это ее собственный документ, и затирает данные Базы 1 своими значениями.
Даже если у вас «полный обмен», современная платформа 1С позволяет наложить фильтры на уровне правил отправки данных. Разберем по шагам, как ограничить миграцию:
Таким образом, документ Отражение зарплаты в бухучете, созданный в Базе 1, физически не попадет в Базу 2, так как он не пройдет по фильтру подразделения при выгрузке из Центра. Это самое чистое решение с точки зрения архитектуры данных.
Если по каким-то причинам настроить фильтры обмена невозможно, воспользуемся механизмом ограничения прав на уровне записей (RLS). Посмотрим, как это поможет:
В каждой базе (База 1 и База 2) настроим профили групп доступа так, чтобы пользователи видели только свои подразделения. В 1С:ЗУП 3.1 при программном заполнении документа Запрос к базе данных учитывает права текущего пользователя. Если пользователь в Базе 1 не имеет прав на подразделения из Базы 2, то при нажатии кнопки «Заполнить» система просто «не увидит» данные чужих сотрудников, и документ будет заполнен корректно только «своими» данными.
Нужно учитывать, что справочник Способы отражения зарплаты в бухучете является ключевым для связи с 1С:Бухгалтерией. Разберем типичную ошибку: создание одинаковых по названию способов в разных базах вручную.
Это приведет к появлению дублей с разными внутренними идентификаторами (GUID). В результате в Центральной базе или при выгрузке в Бухгалтерию проводки могут «развалиться».
Рекомендация: создавайте все элементы справочника Способы отражения строго в Центральной базе, после чего дожидайтесь их появления в периферийных узлах через обмен. Никогда не создавайте их «на местах» вручную.
Если вы хотите программно убедиться, что документ заполняется только по нужному подразделению, можно проанализировать запрос в модуле менеджера документа. Обратите внимание на параметры, передаваемые в процедуру заполнения. Рассмотрим упрощенный пример логики фильтрации:
// Пример логики ограничения выборки данных
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЗарплатаДанные.Сотрудник,
| ЗарплатаДанные.Результат
|ИЗ
| РегистрРасчета.Зарплата КАК ЗарплатаДанные
|ГДЕ
| ЗарплатаДанные.Подразделение В ИЕРАРХИИ(&ОтборПодразделение)";
Запрос.УстановитьПараметр("ОтборПодразделение", Объект.Подразделение);
Именно использование конструкции В ИЕРАРХИИ при наличии заполненного подразделения в шапке документа гарантирует, что лишние данные не попадут в табличную часть Начисления.
Рассмотрим ситуацию, предложенную опытными участниками форума. Если территориально удаленные офисы имеют стабильный интернет-канал, использование РИБ для разделения по подразделениям часто является избыточным и проблемным.
Переход на тонкий клиент или RDP: работа в единой базе на веб-сервере полностью исключает проблемы синхронизации. В этом случае достаточно настроить RLS по подразделениям, и каждый офис будет работать в своем контуре, а отчетность (ПФР, ИФНС) будет формироваться в целом по организации без дополнительных усилий по консолидации данных.
Подводя итог: для корректной работы в РИБ наиболее эффективным сочетанием будет использование префиксов баз, заполнение подразделения в шапке документа и настройка фильтров миграции данных в правилах обмена. Это обеспечит чистоту учета и отсутствие дублей при передаче данных в бухгалтерию.