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

При разработке отчетов в Система Компоновки Данных (СКД) или создании произвольных запросов в программных продуктах «1С:Зарплата и Управление Персоналом» (редакция 3.1) разработчики часто сталкиваются с задачей детализации расчета удержаний. В частности, требуется получить не просто итоговые суммы удержаний по исполнительным листам, но и входящую расчетную базу, а также исчисленный с нее НДФЛ по конкретным сотрудникам или физическим лицам.

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

Архитектура хранения данных удержаний в ЗУП 3.1

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

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

Главный нюанс заключается в том, что в одном документе начисления (например, в документе Начисление зарплаты и взносов) может присутствовать сразу несколько сотрудников. Более того, у одного сотрудника может быть зафиксировано несколько исполнительных листов. Для того чтобы система «понимала», какое конкретно значение показателя относится к определенной строке расчетного листка, используется унікальный ключ — ИдентификаторСтроки.

Анализ частых ошибок при связывании регистров

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

ПО (ВложенныйЗапрос.РегистраторИзмерение = ВложенныйЗапрос1.Регистратор)

Проанализируем, к чему приводит такой подход. Если в документе начисления записано 10 строк удержаний по разным сотрудникам или исполнительным документам, соединение только по полю Регистратор свяжет каждую строку показателей со всеми 10 строками регистра расчета. В результате происходит декартово произведение (задвоение и размножение строк), а итоговые суммы в отчете становятся неверными.

Вторая распространенная ошибка — обращение к справочнику ПоказателиРасчетаЗарплаты по текстовому наименованию:

ВЫБОР 
    КОГДА ЗначенияПоказателейУдержаний.Показатель.Наименование = "Исчисленный по исполнительному листу НДФЛ" 
    ТОГДА ЗначенияПоказателейУдержаний.Значение 
КОНЕЦ

Выясним причину, почему так делать не рекомендуется:

1. Пользователь в режиме «1С:Предприятие» может случайно переименовать показатель.
2. В разных релизах или кастомизированных конфигурациях наименования могут незначительно отличаться.
3. Поиск по наименованию снижает производительность выполнения запроса СУБД.

Шаг за шагом: Составляем правильный запрос

Разберем по шагам, как написать корректный запрос для связывания таблиц.

Шаг 1. Сгруппируем показатели из регистра сведений ЗначенияПоказателейУдержаний по полям РегистраторИзмерение и ИдентификаторСтроки. Для проверки показателей используем системную функцию ЗНАЧЕНИЕ(...).

Шаг 2. Подготовим выборку из регистра расчета Удержания с отбором по физическому лицу и периоду регистрации.

Шаг 3. Выполним ЛЕВОЕ СОЕДИНЕНИЕ по двум обязательным полям: по регистратору И по полю ИдентификаторСтроки.

Рассмотрим готовый пример правильного текста запроса:

ВЫБРАТЬ
	ВложенныйЗапросПоказатели.РегистраторИзмерение КАК Регистратор,
	ВложенныйЗапросПоказатели.ИдентификаторСтроки КАК ИдентификаторСтроки,
	ВложенныйЗапросУдержания.ФизическоеЛицо КАК ФизическоеЛицо,
	ВложенныйЗапросПоказатели.НДФЛ КАК НДФЛ,
	ВложенныйЗапросПоказатели.Начислено КАК Начислено
ИЗ
	(ВЫБРАТЬ
		ЗначенияПоказателей.РегистраторИзмерение КАК РегистраторИзмерение,
		ЗначенияПоказателей.ИдентификаторСтроки КАК ИдентификаторСтроки,
		СУММА(ВЫБОР
				КОГДА ЗначенияПоказателей.Показатель = ЗНАЧЕНИЕ(Справочник.ПоказателиРасчетаЗарплаты.ИсчисленныйПоИсполнительномуЛистуНДФЛ)
					ТОГДА ЗначенияПоказателей.Значение
				ИНАЧЕ 0
			КОНЕЦ) КАК НДФЛ,
		СУММА(ВЫБОР
				КОГДА ЗначенияПоказателей.Показатель = ЗНАЧЕНИЕ(Справочник.ПоказателиРасчетаЗарплаты.РасчетнаяБазаИсполнительногоЛиста)
					ТОГДА ЗначенияПоказателей.Значение
				ИНАЧЕ 0
			КОНЕЦ) КАК Начислено
	ИЗ
		РегистрСведений.ЗначенияПоказателейУдержаний КАК ЗначенияПоказателей
	СГРУППИРОВАТЬ ПО
		ЗначенияПоказателей.РегистраторИзмерение,
		ЗначенияПоказателей.ИдентификаторСтроки) КАК ВложенныйЗапросПоказатели
		ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
			Удержания.Регистратор КАК Регистратор,
			Удержания.ИдентификаторСтроки КАК ИдентификаторСтроки,
			Удержания.ФизическоеЛицо КАК ФизическоеЛицо
		ИЗ
			РегистрРасчета.Удержания КАК Удержания
		ГДЕ
			Удержания.ПериодРегистрации = &ПериодРегистрации
			И Удержания.ФизическоеЛицо = &ФизическоеЛицо
		СГРУППИРОВАТЬ ПО
			Удержания.Регистратор,
			Удержания.ИдентификаторСтроки,
			Удержания.ФизическоеЛицо) КАК ВложенныйЗапросУдержания
		ПО ВложенныйЗапросПоказатели.РегистраторИзмерение = ВложенныйЗапросУдержания.Регистратор
			И ВложенныйЗапросПоказатели.ИдентификаторСтроки = ВложенныйЗапросУдержания.ИдентификаторСтроки

Альтернативные и наиболее надежные способы в ЗУП 3.1

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

Способ 1. Виртуальная таблица БазаУдержания

У регистра расчета Удержания существует виртуальная таблица БазаУдержания. Она автоматически рассчитывает сумму начислений, входящих в базовый результат конкретного удержания, без необходимости вручную агрегировать показатели.

Рассмотрим пример запроса к виртуальной таблице базы:

ВЫБРАТЬ
	УдержанияБаза.ФизическоеЛицо КАК ФизическоеЛицо,
	УдержанияБаза.Регистратор КАК Регистратор,
	УдержанияБаза.ВидРасчета КАК ВидРасчета,
	СУММА(УдержанияБаза.РезультатБаза) КАК РасчетнаяБаза
ИЗ
	РегистрРасчета.Удержания.БазаУдержания(&ПериодРегистрации, , , , ФизическоеЛицо = &ФизическоеЛицо) КАК УдержанияБаза
СГРУППИРОВАТЬ ПО
	УдержанияБаза.ФизическоеЛицо,
	УдержанияБаза.Регистратор,
	УдержанияБаза.ВидРасчета

Способ 2. Регистр накопления НачисленияУдержанияПоСотрудникам

Если задача состоит в построении отчета, аналогичного отчетам «Полный свод начислений, удержаний и выплат» или «Расчетный листок», рекомендуется обращаться к регистру накопления НачисленияУдержанияПоСотрудникам. Данные в нем уже оптимизированы для построения отчетов на СКД и сгруппированы по сотрудникам, организациям и физическим лицам.

Выясним преимущества работы с регистром НачисленияУдержанияПоСотрудникам:

• Высокая скорость работы отчетов на СКД.
• Готовые разрезы аналитики (подразделения, статьи финансирования, статьи расходов).
• Отсутствие необходимости сложного соединения таблиц по внутренним служебным GUID и идентификаторам строк.

Подводим итоги

При связывании регистра расчета Удержания и регистра сведений ЗначенияПоказателейУдержаний обязательно указывайте два условия связи: по полю Регистратор (или РегистраторИзмерение) и по полю ИдентификаторСтроки. Также старайтесь избегать обращения к элементам справочников по их наименованию, заменяя их на конструкцию ЗНАЧЕНИЕ(...).

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