При работе с документом «Отражение зарплаты в бухучете» в конфигурации «Зарплата и управление персоналом 3.1» (ЗУП 3.1) разработчики часто сталкиваются с необходимостью сопоставить суммы налога (НДФЛ) с конкретными способами отражения в бухгалтерском учете. Сложность заключается в том, что в табличной части НДФЛ отсутствует колонка СпособОтражения, которая есть в таблице Начисления. Это создает трудности при формировании детальных отчетов или кастомных выгрузок в сторонние системы учета.
В данной статье мы подробно разберем, как технически объединить эти данные, рассмотрим алгоритмы распределения и выясним, какие нюансы платформы 1С помогут нам решить эту задачу эффективно.
Прежде чем приступать к написанию кода или запроса, проанализируем, почему данные разделены. В системе 1С:ЗУП 3.1 начисления привязаны к конкретным способам отражения (счетам затрат, субконто), тогда как НДФЛ рассчитывается в целом по физическому лицу за налоговый период. Однако для целей бухгалтерского учета налог должен быть «разнесен» по тем же аналитическим разрезам, что и доходы, которые его породили.
Рассмотрим основные варианты связи табличных частей:
ИдентификаторСтроки в начислениях и ИдентификаторСтрокиНачисления в НДФЛ. Если они заполнены, это дает прямую связь.Проанализируем ситуацию, когда у физического лица есть несколько способов отражения (например, часть зарплаты идет на 20 счет, часть на 26). Чтобы корректно сопоставить НДФЛ, нам необходимо вычислить «вес» каждого способа отражения в общей сумме дохода сотрудника.
Рассмотрим пошагово алгоритм реализации этой логики в запросе:
Шаг 1. Получение базы распределения. Сгруппируем таблицу Начисления по ФизическоеЛицо и СпособОтражения, вычислив общие суммы дохода для каждой пары.
Шаг 2. Вычисление общего итога. Сгруппируем ту же таблицу только по ФизическоеЛицо, чтобы получить общую сумму начислений сотрудника за месяц.
Шаг 3. Соединение с таблицей НДФЛ. Присоединим таблицу НДФЛ к нашим сгруппированным данным и применим формулу пропорции.
Пример логики запроса для реализации распределения:
// 1. Получаем начисления в разрезе способов отражения
ВЫБРАТЬ
Отражение.ФизическоеЛицо КАК ФизическоеЛицо,
Отражение.СпособОтражения КАК СпособОтражения,
СУММА(Отражение.Сумма) КАК СуммаНачисления
ПОМЕСТИТЬ ВТ_БазаНачислений
ИЗ
Документ.ОтражениеЗарплатыВБухучете.Начисления КАК Отражение
ГДЕ
Отражение.Ссылка = &Ссылка
СГРУППИРОВАТЬ ПО
Отражение.ФизическоеЛицо,
Отражение.СпособОтражения;
// 2. Распределяем НДФЛ
ВЫБРАТЬ
Т_НДФЛ.ФизическоеЛицо,
Т_База.СпособОтражения,
Т_НДФЛ.Сумма * (Т_База.СуммаНачисления / Т_Итог.ОбщаяСумма) КАК НДФЛ_Распределенный
ИЗ
Документ.ОтражениеЗарплатыВБухучете.НДФЛ КАК Т_НДФЛ
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_БазаНачислений КАК Т_База
ПО Т_НДФЛ.ФизическоеЛицо = Т_База.ФизическоеЛицо
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (
ВЫБРАТЬ ФизическоеЛицо, СУММА(СуммаНачисления) КАК ОбщаяСумма
ИЗ ВТ_БазаНачислений СГРУППИРОВАТЬ ПО ФизическоеЛицо
) КАК Т_Итог
ПО Т_НДФЛ.ФизическоеЛицо = Т_Итог.ФизическоеЛицо
Важно помнить, что в запросе деление может привести к ошибкам, если ОбщаяСумма равна нулю. Проанализируем этот момент: всегда добавляйте проверку ГДЕ Т_Итог.ОбщаяСумма <> 0.
Если ваша конфигурация ЗУП 3.1 обновлена до актуальных версий, обратите внимание на скрытые реквизиты табличных частей. Разберем, как их использовать. Реквизит ИдентификаторСтроки в таблице Начисления является уникальным ключом внутри документа. В таблице НДФЛ поле ИдентификаторСтрокиНачисления (в некоторых релизах название может отличаться, например, СвязьСНачислением) указывает на ту самую строку дохода, из которой был исчислен налог.
Этот способ является наиболее точным, так как он заложен в логику типового механизма заполнения документа. Если мы используем программную обработку документа, мы можем связать таблицы напрямую:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| НДФЛ.Сумма КАК СуммаНалога,
| Начисления.СпособОтражения КАК СпособОтражения,
| НДФЛ.ФизическоеЛицо КАК ФизическоеЛицо
|ИЗ
| Документ.ОтражениеЗарплатыВБухучете.НДФЛ КАК НДФЛ
| ЛЕВОЕ СОЕДИНЕНИЕ Документ.ОтражениеЗарплатыВБухучете.Начисления КАК Начисления
| ПО НДФЛ.Ссылка = Начисления.Ссылка
| И НДФЛ.ИдентификаторСтрокиНачисления = Начисления.ИдентификаторСтроки
|ГДЕ
| НДФЛ.Ссылка = &Ссылка";
Рассмотрим ситуацию, когда ИдентификаторСтрокиНачисления не заполнен. Такое бывает при ручной корректировке документа или в старых версиях. В этом случае система неизбежно откатывается к методу пропорционального распределения по физическому лицу.
При математическом распределении (умножении суммы налога на коэффициент доли дохода) мы почти всегда будем получать дробные числа. Поскольку учет ведется в копейках, возникает проблема округления. Если просто округлить каждую строку, итоговая сумма распределенного НДФЛ может не совпасть с исходной суммой в документе.
Выясним, как решается эта задача в профессиональной разработке на 1С:
ЦЕЛ(Сумма * Коэффициент * 100) / 100.Рассмотрим пример. Допустим, НДФЛ сотрудника 100 рублей. У него два начисления с равными весами (50/50). После применения сложного коэффициента у нас получается 49.995 и 49.995. Если просто округлить, мы можем получить 50.00 + 50.00 (правильно) или 49.99 + 49.99 = 99.98 (ошибка). Всегда контролируйте остаток!
Проанализируем еще один важный разрез — статьи финансирования. В бюджетных организациях или компаниях с раздельным учетом НДФЛ должен распределяться не только по способам отражения, но и по источникам средств. В документе «Отражение зарплаты в бухучете» эти данные обычно синхронизированы. Если вы объединяете таблицы, убедитесь, что в соединение (JOIN) включено поле СтатьяФинансирования, если оно заполнено в обеих частях. Это позволит избежать «пересортицы» налогов между разными бюджетами внутри одного сотрудника.
Подведем итог. Для качественного объединения двух табличных частей в ЗУП 3.1 мы рекомендуем использовать комбинированный подход: сначала пытаться связать строки по ИдентификаторуСтроки, а для строк, где связь не установлена, применять алгоритм пропорционального распределения по суммам начислений текущего периода с обязательной корректировкой копеек в конце расчета.