В работе с 1С:ЗУП 3.1 мы часто сталкиваемся с необходимостью тонкой настройки расчетов, особенно когда дело касается стимулирующих выплат и налогового учета. Одна из таких ситуаций — это начисление стимулирующей выплаты к отпуску, которая должна иметь специфический код дохода НДФЛ, отличный от того, что предлагается программой по умолчанию, а также сложную формулу расчета.
Рассмотрим две ключевые проблемы, поднятые в нашей теме:
Проблема выбора кода дохода НДФЛ 2002 для "Единовременной выплаты к отпуску" в 1С:ЗУП 3.1.
Сложности настройки формулы расчета такой выплаты, зависящей от базы начислений и количества отработанных месяцев.
Разберем каждую из этих проблем пошагово, предлагая возможные решения и подходы.
1. Изменение кода дохода НДФЛ для единовременной выплаты к отпуску
Наши бухгалтеры часто утверждают, что определенные виды начислений должны иметь конкретный код дохода НДФЛ, исходя из их внутренней классификации или требований налоговых органов. В данном случае, речь идет о стимулирующей выплате к отпуску, для которой они настаивают на коде дохода 2002 ("Суммы премий, выплачиваемых за производственные результаты и иные подобные показатели"). Однако, типовой функционал 1С:ЗУП 3.1 для начисления с назначением "Единовременная выплата к отпуску" по умолчанию может устанавливать код 4800 ("Иные доходы") или вовсе не давать выбрать 2002.
Почему возникает такая ситуация? В 1С:ЗУП 3.1, когда мы устанавливаем для начисления "Назначение начисления" как "Единовременная выплата к отпуску", программа внутренне ограничивает доступные для выбора коды дохода НДФЛ. Это происходит на уровне кода конфигурации, в модулях, отвечающих за работу с планами видов расчета.
Причины и классификация кодов дохода НДФЛ
Прежде чем перейти к решениям, давайте проясним разницу в подходах к кодам дохода НДФЛ:
Код 2002: Этот код обычно предназначен для премий, которые выплачиваются за производственные результаты, трудовые достижения и другие подобные показатели, предусмотренные трудовыми или коллективными договорами. Если стимулирующая выплата к отпуску по своей сути является премией за достижение каких-либо показателей (например, за отсутствие больничных за год, за выполнение плана), то бухгалтеры могут обоснованно настаивать на этом коде.
Код 4800: Это универсальный код, который применяется для доходов, не имеющих специального кода в справочнике ФНС. К таким доходам часто относят различные единовременные доплаты, которые не связаны напрямую с производственными показателями и не являются компенсациями. Единовременные доплаты к ежегодному отпуску, выплачиваемые вместе с отпускными, могут быть отнесены к этому коду, если они не являются премиями за трудовые заслуги.
Коды 2720/2721/2760: Если выплата классифицируется как материальная помощь к отпуску, то она имеет свои особенности налогообложения. Например, материальная помощь (коды 2760 или 2720/2721) не облагается НДФЛ в сумме до 4000 рублей в год (п. 28 ст. 217 НК РФ). С суммы превышения НДФЛ начисляется в общем порядке. Этот вариант нужно рассматривать, если выплата действительно является материальной помощью.
Итак, если бухгалтеры настаивают на коде 2002, мы должны убедиться, что это соответствует экономической сути выплаты и налоговому законодательству. Предположим, что их требование обосновано.
Варианты решения проблемы с кодом дохода НДФЛ
Мы рассмотрим несколько подходов к решению этой задачи, от наименее инвазивных до требующих модификации конфигурации.
Метод 1: Модификация модуля менеджера (решение, предложенное на форуме)
Этот метод является прямым вмешательством в код конфигурации и позволяет "открыть" выбор кода 2002 для нужного назначения начисления. Это решение требует определенных навыков программирования и понимания архитектуры 1С.
Откройте конфигурацию в режиме "Конфигуратор". Это стандартный первый шаг для любых изменений в коде.
Найдите модуль менеджера планов видов расчета "Начисления". В дереве объектов конфигурации перейдите к ветке "ПланыВидовРасчета" -> "Начисления" -> "Модуль менеджера".
Найдите секцию, отвечающую за отбор кодов дохода НДФЛ. Обычно это происходит в процедуре, которая заполняет параметры выбора или описание начисления. На форуме предложено искать в районе строки 2000. Мы будем искать место, где к объекту Описание.ПараметрыВыбора.КодДоходаНДФЛ.Отбор_Код добавляются значения.
Добавьте нужный код в список разрешенных. Как правило, мы увидим строки, подобные следующим:
Мы должны добавить нашу строку для кода 2002. В данном случае, можно добавить её рядом с существующими:
Описание.ПараметрыВыбора.КодДоходаНДФЛ.Отбор_Код.Добавить("4800");
Описание.ПараметрыВыбора.КодДоходаНДФЛ.Отбор_Код.Добавить("2000");
Описание.ПараметрыВыбора.КодДоходаНДФЛ.Отбор_Код.Добавить("2002"); // Добавляем код 2002 для выбора
Комментарий //Гена, предложенный в сообщении форума, полезен для идентификации нашего изменения.
Сохраните изменения и обновите базу данных. После внесения изменений, мы должны сохранить конфигурацию и обновить базу данных, чтобы изменения вступили в силу.
Важно: Этот метод имеет свои риски:
Снятие с поддержки: Любая модификация типовой конфигурации без использования расширений делает её нетиповой, что может усложнить процесс обновления. При каждом обновлении мы будем вынуждены либо повторять изменение, либо адаптировать его под новую версию.
Потенциальные ошибки: Неправильное изменение кода может привести к непредсказуемым ошибкам в работе программы.
Ответственность: Мы должны иметь письменное распоряжение от бухгалтеров или руководства на выполнение таких изменений, чтобы избежать дальнейших недоразумений и распределить ответственность.
Метод 2: Групповое изменение реквизитов
Если модификация конфигурации нежелательна, мы можем рассмотреть метод группового изменения реквизитов. Этот подход не меняет логику выбора кода дохода, но позволяет изменить его для уже созданных начислений или документов.
Создайте начисление. Мы создаем начисление "Единовременная выплата к отпуску" с нужным назначением. Программа по умолчанию установит код 4800 или другой разрешенный.
Используйте "Групповое изменение реквизитов". После того как начисление создано и, возможно, даже проведено, мы можем воспользоваться стандартной обработкой "Групповое изменение реквизитов" (обычно доступна через "Все функции" или "Администрирование" -> "Обслуживание" -> "Корректировка данных").
Выберите объект для изменения. Мы выбираем "Начисления" или "Документы" (если начисление уже в документе).
Установите новый код дохода. В списке реквизитов найдите "КодДоходаНДФЛ" и установите его значение на "2002".
Этот метод менее инвазивен, но он не решает проблему выбора кода при создании нового начисления или документа, а лишь корректирует его постфактум. Также, как и в первом случае, мы должны иметь письменное распоряжение.
Метод 3: Создание нового начисления с другим назначением (если применимо)
Если стимулирующая выплата к отпуску действительно по своей сути является премией, мы можем рассмотреть вариант создания нового вида начисления с назначением "Премия". Для таких начислений код 2002 обычно доступен по умолчанию.
Создайте новый вид начисления. Перейдите в "Настройка" -> "Начисления" и создайте новое начисление.
Установите "Назначение начисления" как "Премия". Это позволит системе корректно интерпретировать выплату и предоставить соответствующие опции, включая выбор кода дохода 2002.
Настройте параметры расчета. Укажите, что начисление выполняется "Ежемесячно" или "Разово" и настройте формулу, если она не типовая.
Обеспечьте ввод данных. Возможно, потребуется создать документ "Премия" или "Разовое начисление" для ввода этой выплаты.
Этот подход является наиболее "чистым" с точки зрения типовой конфигурации, но он требует переосмысления сути выплаты: является ли она "единовременной выплатой к отпуску" или "премией"? Если это премия, связанная с отпуском, то данный метод может быть оптимальным.
2. Настройка сложной формулы расчета стимулирующей выплаты к отпуску
Вторая часть нашей задачи связана с настройкой сложной формулы для этой стимулирующей выплаты. Нам дана следующая логика:
"Размер выплаты работника определяется из суммы фактической заработной платы за последний календарный год (12 календарных месяцев) / 12. Для вновь принятых работников расчётная сумма определяется как сумма заработной платы, начисленная за отработанный период / фактическое количество отработанных дней."
Давайте проанализируем эту формулу и посмотрим, как мы можем реализовать ее в 1С:ЗУП 3.1.
Анализ формулы и ее особенностей
На первый взгляд, формула кажется похожей на расчет среднего заработка, но есть нюансы:
Разные размерности: В первом случае мы получаем среднемесячную сумму ("сумма за 12 месяцев / 12"), во втором – среднедневную ("сумма за период / количество отработанных дней"). Это указывает на необходимость двух разных подходов к расчету или очень гибкой формулы.
Ограничение по 12 месяцам: Для "старых" сотрудников берется 12 месяцев. Для "новых" – фактический отработанный период.
Специфическая расчетная база: Необходимо четко определить, какие именно виды начислений входят в "сумму фактической заработной платы". Это может отличаться от типовой базы для среднего заработка.
Типовой "Средний заработок общий" в 1С:ЗУП 3.1, используемый для отпусков, имеет свою жестко определенную логику и не подходит для такой специфической формулы. Поэтому нам потребуется создавать собственное начисление и настраивать его расчет.
Пошаговая настройка в 1С:ЗУП 3.1
Создание или модификация вида начисления.
Переходим в "Настройка" -> "Начисления" и создаем новое начисление, например, "Стимулирующая выплата к отпуску".
Назначение начисления: Выбираем "Прочие начисления и выплаты" или "Материальная помощь к отпуску". Это даст нам максимальную гибкость в настройке формулы и определении расчетной базы, в том числе возможности повлиять на учет в среднем заработке, если это потребуется. Если мы выбираем "Единовременная выплата к отпуску", мы возвращаемся к проблеме с кодом НДФЛ, описанной выше. Если мы ее уже решили модификацией, то можем использовать это назначение.
Расчет и зависимость: Указываем, что начисление выполняется "Разово" или "По отдельному документу".
Настройка формулы расчета.
На закладке "Основное" в карточке начисления находим ссылку "Редактировать формулу". Здесь мы будем конструировать нашу логику. Однако, простая формула может быть недостаточной для двух разных случаев (старые/новые сотрудники) и ограничения в 12 месяцев.
Пример формулы (базовая часть):
БазаНачислений / СвойПоказательМесяцев
Здесь БазаНачислений будет собирать сумму фактической заработной платы, а СвойПоказательМесяцев – количество отработанных месяцев с ограничением в 12.
Определение расчетной базы (БазаНачислений).
Переходим на закладку "Расчетная база" в карточке начисления. Здесь мы указываем, какие виды начислений будут формировать "сумму фактической заработной платы".
Выбираем виды начислений: Добавляем в список все начисления, которые должны входить в "фактическую заработную плату" согласно требованиям бухгалтеров (оклады, премии, доплаты и т.д.).
Указываем период отбора: Мы выбираем "за последние 12 месяцев" или другой нужный период, чтобы соответствовать "за последний календарный год".
Важно: Для большинства предопределенных начислений возможность изменения порядка учета в среднем заработке может быть недоступна. Самостоятельное определение порядка учета в среднем заработке возможно для начислений с назначением "Прочие начисления и выплаты", "Материальная помощь" и "Материальная помощь к отпуску". Это еще одна причина использовать эти назначения.
Расчет СвойПоказательМесяцев (Количество отработанных месяцев с ограничением).
Это наиболее сложная часть. Нам нужно получить количество месяцев, отработанных сотрудником, с учетом ограничения в 12 месяцев и с даты приема для новых сотрудников.
Создание собственного показателя: В "Настройка" -> "Показатели расчета зарплаты" мы можем создать новый показатель, например, КоличествоОтработанныхМесяцевДляВыплаты. Однако, его значение нужно будет где-то рассчитывать и вводить.
Варианты получения значения для СвойПоказательМесяцев:
Ввод вручную: Для простоты, этот показатель можно вводить вручную через документ "Данные для расчета зарплаты", используя "Шаблон ввода исходных данных". Мы создаем шаблон, где указываем этот показатель и период, за который он вводится. Это требует ручного контроля и ввода данных.
Расширение или внешняя обработка: Если автоматизация критична, нам потребуется разработать расширение конфигурации или внешнюю обработку. Эта разработка будет анализировать данные о приеме сотрудника, его отработанном времени за последние 12 месяцев (или с даты приема) и на основе этого рассчитывать СвойПоказательМесяцев, который затем будет либо записываться в регистр сведений, либо передаваться в формулу напрямую. Это самый гибкий, но и самый трудоемкий путь.
Использование предопределенных показателей (с ограничениями): Мы можем попробовать использовать существующие показатели, такие как ОтработаноДнейВПределахГрафика или ОтработаноЧасовВПределахГрафика, но их придется адаптировать к месяцам и ограничивать. Это может потребовать сложной логики в формуле начисления, включающей функции округления или преобразования дней в месяцы, и все равно не решит проблему ограничения "не более 12".
Особенности для "вновь принятых работников".
Формула для вновь принятых: "сумма заработной платы, начисленная за отработанный период / фактическое количество отработанных дней."
Эта часть формулы отличается от первой и требует расчета среднедневного заработка. Это указывает на то, что, возможно, нам потребуется либо:
Два разных вида начисления: Один для "старых" сотрудников (по среднемесячному принципу), другой для "новых" (по среднедневному принципу). Мы бы тогда определяли, какое начисление применять, основываясь на дате приема или стаже сотрудника.
Сложная логика в одной формуле: Формула начисления может содержать условия, проверяющие стаж сотрудника. Например:
Если РазницаДат(ДатаПриема, ДатаНачалаПериодаРасчета, Месяц) <= 12 Тогда
// Формула для новых: БазаНачислений / КоличествоОтработанныхДней
Иначе
// Формула для старых: БазаНачислений / 12
КонецЕсли;
Для реализации этого потребуется создание дополнительных показателей, таких как КоличествоОтработанныхДней, и соответствующих настроек расчетной базы для них. Количество отработанных дней может быть получено из стандартных данных учета времени.
Общие рекомендации по настройке сложных формул
Тестирование: Мы должны тщательно протестировать все варианты расчета на тестовой базе с разными сценариями (старые сотрудники, новые, сотрудники, уходившие в отпуск без сохранения зарплаты и т.д.).
Документирование: Все изменения, особенно касающиеся кода конфигурации или сложной логики расчета, должны быть подробно документированы.
Консультации с бухгалтерией: Мы должны поддерживать тесный контакт с бухгалтерами, чтобы убедиться, что наши настройки соответствуют их требованиям и налоговому законодательству.
Таким образом, мы видим, что решение задачи по стимулирующей выплате к отпуску в 1С:ЗУП 3.1 требует внимательного подхода как к настройке налогового учета (код НДФЛ), так и к сложной логике расчета, возможно, с использованием модификаций конфигурации или расширений.