В процессе работы с программой 1С:Зарплата и управление персоналом 8 (редакция 3.1) бухгалтеры и расчетчики часто сталкиваются с ситуацией, когда сотрудник в середине месяца переводится из одного подразделения в другое. Если такому сотруднику начисляется сдельный заработок, возникает сложность: система должна корректно соотнести суммы выработки с конкретным подразделением и периодом работы. Однако по умолчанию программа часто распределяет общую сумму сделки пропорционально отработанному времени, что не всегда соответствует фактическим данным из первичных документов.
В этой статье мы подробно разберем, почему возникает такая проблема, рассмотрим типовые способы ее решения через настройки программы и проанализируем программный метод корректировки алгоритма расчета.
Рассмотрим стандартную ситуацию: сотрудник переведен в другое подразделение с 27-го числа. До этой даты он работал в "Подразделении 1", после — в "Подразделении 2". В систему введены два документа Данные для расчета зарплаты, в которых зафиксирована выработка по каждому подразделению отдельно. Однако при формировании документа Начисление зарплаты и взносов программа создает две строки (согласно кадровым периодам), но суммы в них оказываются "усредненными".
Причина кроется в настройке Вида начисления. Если для показателя СдельныйЗаработок установлен флаг "Все накопленные значения за месяц", алгоритм 1С работает следующим образом:
Это приводит к тому, что реальная выработка, зафиксированная документами, "размывается" по месяцу. Чтобы добиться точного распределения, нам необходимо изменить логику подбора данных.
Первый и самый простой способ — изменить настройки самого начисления. Проанализируем, как это влияет на расчет.
В настройках вида расчета (раздел Настройка — Начисления) выберите ваш вид сдельной оплаты. На вкладке "Определение данных" или в настройках используемого показателя необходимо переключить режим накопления. Вместо "Все накопленные значения за месяц" выберите вариант: "Значения накапливаемых показателей подбираются — по соответствию даты регистрации интервалу начисления".
При такой настройке система будет смотреть на Дату (или период), указанную в документе Данные для расчета зарплаты. Если дата документа попадает в интервал с 1 по 26 число, вся сумма из этого документа упадет в первую строку начисления (по первому подразделению). Если дата 27-е и позже — во вторую.
Важный нюанс: у этого метода есть существенный риск. Если дата регистрации показателя (дата документа) совпадает с днем, когда сотрудник отсутствовал (например, болел или был в отпуске), программа может "не увидеть" этот показатель для конкретного сотрудника, и сумма вообще не попадет в расчет. Чтобы избежать этого, административно установите правило: вносить документы выработки либо датой последнего рабочего дня в подразделении, либо последним числом месяца, предварительно убедившись, что сотрудник числится в состоянии Работа.
Если ваша цель — корректное отражение затрат в бухгалтерском учете, можно пойти по пути уточнения аналитики в самом документе Данные для расчета зарплаты.
Выясним, как настроить шаблон ввода данных (раздел Настройка — Шаблоны ввода исходных данных):
После этой настройки в табличной части документа появится колонка "Подразделение". Если вы явно укажете подразделение в документе выработки, система при формировании документа Отражение зарплаты в бухучете подтянет именно эту аналитику, даже если в самом Начислении зарплаты строки распределились пропорционально времени. Это наиболее надежный способ для корректного формирования проводок.
Если типовые настройки не удовлетворяют требованиям бизнеса (например, когда нужно жесткое соответствие периодам без риска потери данных из-за отсутствий), можно внести изменения в программный код. Рассмотрим пример модификации общего модуля МенеджерРасчетаЗарплаты.
Проанализируем ситуацию: показатели подбираются за весь месяц из-за установленного флага ПоказательВЦеломЗаМесяц. Мы можем изменить логику в процедурах ЗначениеОперативногоПоказателя и ФильтрПолученияОперативныхПоказателейСотрудников, чтобы система принудительно ограничивала период поиска данных датами начала и окончания конкретной строки начисления (интервала), а не всего месяца.
Пример изменения логики в коде:
// В процедуре фильтрации оперативных показателей
Если ПоказательВЦеломЗаМесяц Тогда
// Стандартный код:
// ОтборПоказателей.ДатаНачала = НачалоМесяца(СтрокаНачисления.ДатаНачала);
// ОтборПоказателей.ДатаОкончания = КонецМесяца(СтрокаНачисления.ДатаОкончания);
// Модифицированный код для точного распределения:
ОтборПоказателей.ДатаНачала = СтрокаНачисления.ДатаНачала;
ОтборПоказателей.ДатаОкончания = СтрокаНачисления.ДатаОкончания;
КонецЕсли;
Внимание: Такое изменение является глобальным и затронет все начисления, использующие накапливаемые показатели. Рекомендуется реализовывать подобные правки через Расширения конфигурации, добавляя проверку на конкретный идентификатор начисления или показателя (например, только для СдельныйЗаработок), чтобы не нарушить расчет премий или доплат за ночные часы.
Подведем итог и составим алгоритм действий для корректного учета сделки при переводах:
СдельныйЗаработок.Данные для расчета зарплаты. Один — до даты перевода, второй — после.Таким образом, комбинируя правильную настройку видов начислений и административный контроль за вводом документов, можно добиться точного распределения сумм без необходимости сложного программирования. Однако в крупных организациях с большим объемом данных программная доработка через расширение может стать единственным способом автоматизации этого процесса.