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