Совокупная тарифная ставка с учетом разовых начислений (краткосрочный перевод на другую оплату труда)
Коллеги, почему может неправильно считать сабж?
Сотрудник в середине месяца на одну неделю переводится на другой оклад.
В начале месяца у него сверхурочные часы. Но считает совокупную тарифную ставку неправильно, такое впечатление, что он прибавляет лишний оклад((((
График у сотрудника не меняется. Совокупная тарифная ставка считается по норме часов сотрудника.
По идее, нужно сложить оклад и все разовые. которые входят в совокупную тарифную ставку и поделить на норму часов. Нонет.
Подскажите, есть ли надежда добиться правильного расчета? Есть ли разборы такой ситуации?
Сотрудник в середине месяца на одну неделю переводится на другой оклад.
В начале месяца у него сверхурочные часы. Но считает совокупную тарифную ставку неправильно, такое впечатление, что он прибавляет лишний оклад((((
График у сотрудника не меняется. Совокупная тарифная ставка считается по норме часов сотрудника.
По идее, нужно сложить оклад и все разовые. которые входят в совокупную тарифную ставку и поделить на норму часов. Нонет.
Подскажите, есть ли надежда добиться правильного расчета? Есть ли разборы такой ситуации?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Могу опубликовать своё решение.
Применяется в крупной компании, выверено уже порядка 4 месяцев.
Суть. Сначала документ (Начисление з.п. и взносов) заполняется и рассчитывается типовым способом, потом запускается (кнопка) моя обработка.
Она, кому надо, альтернативно считает стоимость часа как сумма всех начислений, как основных (регистрирующих использование рабочего времени), так и других, какие вы отметите допреквизитом.
И делит на оплаченное время в часах.
Если эта новая стоимость часа отличается от типовой, доплата пересчитывается, фиксируется как "ручной расчет" и сотрудник полностью вторично пересчитывается (удержания, НДФЛ, взносы)
Главное отличие от типового решения - у меня не нормативная стоимость часа, а фактическая.
Потому что фактические начисления поделены на фактически оплаченное время.
Применяется в крупной компании, выверено уже порядка 4 месяцев.
Суть. Сначала документ (Начисление з.п. и взносов) заполняется и рассчитывается типовым способом, потом запускается (кнопка) моя обработка.
Она, кому надо, альтернативно считает стоимость часа как сумма всех начислений, как основных (регистрирующих использование рабочего времени), так и других, какие вы отметите допреквизитом.
И делит на оплаченное время в часах.
Если эта новая стоимость часа отличается от типовой, доплата пересчитывается, фиксируется как "ручной расчет" и сотрудник полностью вторично пересчитывается (удержания, НДФЛ, взносы)
Главное отличие от типового решения - у меня не нормативная стоимость часа, а фактическая.
Потому что фактические начисления поделены на фактически оплаченное время.
(6) Я в первую очередь делал для доплат при суммированном учете.
А там есть понятие учетного периода, он может быть более 1 месяца.
Я это всё учитываю и тяну начисления и время за учетный период доплаты, то есть за нужные месяцы.
Типовой механизм так не делает. Но так надо было нашей компании.
А там есть понятие учетного периода, он может быть более 1 месяца.
Я это всё учитываю и тяну начисления и время за учетный период доплаты, то есть за нужные месяцы.
Типовой механизм так не делает. Но так надо было нашей компании.
(9) И еще.
Начисления зарплаты уже могут быть сделаны другим документом. Ну скажем, по другому подразделению, в котором был сотрудник в части месяца.
Это тоже зачитывается.
Расширение для публикации готово.
В нем будут отрабатываться виды начислений "Оплата сверхурочных часов" и "Доплата за переработки при суммированном учете времени"
Как пройдёт модерацию - сюда выложу ссылку на него.
Начисления зарплаты уже могут быть сделаны другим документом. Ну скажем, по другому подразделению, в котором был сотрудник в части месяца.
Это тоже зачитывается.
Расширение для публикации готово.
В нем будут отрабатываться виды начислений "Оплата сверхурочных часов" и "Доплата за переработки при суммированном учете времени"
Как пройдёт модерацию - сюда выложу ссылку на него.
(10) Второй док понятно, как раз он и региструет сверхи за учётный период по графику. Но первый док - он же регистрирует сверхи в текущей СМЕНЕ, т.е. сверх графика. Противоречит логике оплата их по той же средней стоимости часа. Здесь как раз лучше использовать штатный расчёт.
Другими словами, среднечасовой расчёт годится только для дока регистрации переработок, а вот док учёта сверхурочных надо бы оставить штатному алгоритму.
Другими словами, среднечасовой расчёт годится только для дока регистрации переработок, а вот док учёта сверхурочных надо бы оставить штатному алгоритму.
(11) Пожалуй, на две команды разобью.
Первая будет ловить и пересчитывать "Оплату сверхурочных часов"
Вторая - Доплату при суммированном
Насчет логики оплаты. Если внутри месяца менялся ЧТС (оклад) - какой должна быть "базовая" стоимость часа для сверхурочки?
У нас случай был, что со 02 июля ЧТС (часовая тарифная ставка) выросла. Сотрудники стали возмущаться, что для среднего ЧТС была взята по состоянию на начало месяца (типовой механизм). Это было в 2023.
Вот поэтому и родилась моя доработка. Которая считает среднюю стоимость часа по факту, и устроила всех.
Это прошлой осенью я её обогатил на подтягивание прочих начислений в стоимость часа.
И еще. Эта доработка была просто "вау" для случаев, когда оплаты считаются во внешней программе (УАТ, ТЛЭ и другие) и в ЗУП грузятся в показатели расчета зарплаты. У сотрудников обычно нулевая плановая тарифная ставка.
А стоимость часа для той же доплаты при суммированном надо считать. Считает отменно.
Первая будет ловить и пересчитывать "Оплату сверхурочных часов"
Вторая - Доплату при суммированном
Насчет логики оплаты. Если внутри месяца менялся ЧТС (оклад) - какой должна быть "базовая" стоимость часа для сверхурочки?
У нас случай был, что со 02 июля ЧТС (часовая тарифная ставка) выросла. Сотрудники стали возмущаться, что для среднего ЧТС была взята по состоянию на начало месяца (типовой механизм). Это было в 2023.
Вот поэтому и родилась моя доработка. Которая считает среднюю стоимость часа по факту, и устроила всех.
Это прошлой осенью я её обогатил на подтягивание прочих начислений в стоимость часа.
И еще. Эта доработка была просто "вау" для случаев, когда оплаты считаются во внешней программе (УАТ, ТЛЭ и другие) и в ЗУП грузятся в показатели расчета зарплаты. У сотрудников обычно нулевая плановая тарифная ставка.
А стоимость часа для той же доплаты при суммированном надо считать. Считает отменно.
(13) Я реализовал более топорно, можно сказать костыль. После проведения зарплаты и взносов необходимо ввести разовое начисление, там сделал отдельную команду на форме. По этой команде происходит расчет часовой стоимости, данные для расчета часовой стоимости брал из "НачисленияУдержанияПоСотрудникам", "ОтработанноеВремяПоСотрудникам" и дальше уже по формуле рассчитывается сама доплата. Минус в том, что после этого необходимо пересчитать начисление зарплаты, чтобы заново рассчитались удержания с учетом этой доплаты. Поэтому интересна ваша доработка, жду
(10) Я к чему. Пока не выкладывайте свою обработку. Сделайте в коде ветвление по переключателю. Расчёт по среднечасовому намертво забейте для переработок - это нормально. А переключатель для ветвления - 95% пользователей, уверяю, захотят считать сверхурочные внутри смены штатно.
Здесь подробно изложил решение с картинками-скринами (пост №17):
Полная автоматизация. Хоть тысячи сотрудников. Никаких телодвижений, всяких вводов данных для расчёта зарплаты, внешних "ручных" расчётов и т.п. ЗУП сам посчитает дополнительную оплату за сверхурочные по изменениям в ТК РФ с сентября 2024 года. Не надо также трогать совокупную тарифную ставку - она останется, как и была, из оклада.
Полная автоматизация. Хоть тысячи сотрудников. Никаких телодвижений, всяких вводов данных для расчёта зарплаты, внешних "ручных" расчётов и т.п. ЗУП сам посчитает дополнительную оплату за сверхурочные по изменениям в ТК РФ с сентября 2024 года. Не надо также трогать совокупную тарифную ставку - она останется, как и была, из оклада.
И ещё. Мне сама идея чернения записи начисления не нравится. Ни к чему дополнительные движения пользователю. Лучше пусть будет не обработка, а расширение, которое рассчитанную сумму по среднечасовому выводит новым начислением, новой дополнительной записью "Доплата по среднечасовому" автоматически при вводе дока регистрации переработок.
Надо переделать структуру Вашей обработки.
Надо переделать структуру Вашей обработки.
ТЗ
Внутри дока регистрации переработок добавить код:
1. Справа добавить поле, в котором выбирается список начислений для числителя расчёта.
2. По периоду из шапки и данному сотруднику (или ФЛ ?) перебираются запросом во всех доках начисления зарплаты суммы и часы.
3. По п.2 находим среднечасовой для сверхурочных СЧС.
4. По уже расситанным штатно записям дока просто заводим новое начисление «Доплата по СЧС», один к одному по штатному алгоритму за исключением того, что часы умножаем не на предопределённый показатель СтоимостьЧаса… а на наш рассчитанный СЧС.
5. Тут надо подумать. Либо в п.4 выводим полные расчётные суммы, если оклад не выбрали в п.1. Либо на разницу со штатным алгоритмом, если выбрали. Сами решайте.
Внутри дока регистрации переработок добавить код:
1. Справа добавить поле, в котором выбирается список начислений для числителя расчёта.
2. По периоду из шапки и данному сотруднику (или ФЛ ?) перебираются запросом во всех доках начисления зарплаты суммы и часы.
3. По п.2 находим среднечасовой для сверхурочных СЧС.
4. По уже расситанным штатно записям дока просто заводим новое начисление «Доплата по СЧС», один к одному по штатному алгоритму за исключением того, что часы умножаем не на предопределённый показатель СтоимостьЧаса… а на наш рассчитанный СЧС.
5. Тут надо подумать. Либо в п.4 выводим полные расчётные суммы, если оклад не выбрали в п.1. Либо на разницу со штатным алгоритмом, если выбрали. Сами решайте.
Мне ответили так
Добрый день!
Указанная проблема записана в ошибку 60018258:
Если в формуле начисления используются показатели РасчетнаяБаза и СтоимостьДняЧасаСУчетомРазовыхНачислений, на вкладке "Расчет тарифной ставки" добавлены начисления, то в случае, когда начисление разбивается по периодам по причине кадровых изменений, стоимость дня (часа) может рассчитываться неверно.
Сроки исправления пока не определены.
Вы можете отслеживать статус своего обращения перейдя по ссылке HL-928617
С уважением, отдел тех. поддержки фирмы "1С"
Добрый день!
Указанная проблема записана в ошибку 60018258:
Если в формуле начисления используются показатели РасчетнаяБаза и СтоимостьДняЧасаСУчетомРазовыхНачислений, на вкладке "Расчет тарифной ставки" добавлены начисления, то в случае, когда начисление разбивается по периодам по причине кадровых изменений, стоимость дня (часа) может рассчитываться неверно.
Сроки исправления пока не определены.
Вы можете отслеживать статус своего обращения перейдя по ссылке HL-928617
С уважением, отдел тех. поддержки фирмы "1С"
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот