Сотрудник работал в праздники с 1 по 3 мая. Выплати зарплату. Исправляю чтобы средний заработок не входил. Выяснилось что в связи с дополнительным нерабочим днем 24 июня средний для расчета праздничных не совпадает. Перерасчет не зарегистрирован, зарплата не перерасчитывается. Как поправить? Хотим чтобы остался вариант по которому считали и выплачивали и был еще один документ с перерасчетом.
Все комментарии (10)
Комментарии закрыты.
Здравствуйте! Да, в ПК появился новый нерабочий день в связи с указом президента, и этот день, в отличие от периода «карантинных» нерабочих дней. К сожалению, разъяснений пока нет, и разработчики этот день исключили из нормы. Если я правильно поняла, то у Вас неверно считается Стоимость часа из-за этого. Так? Какой у Вас релиз ЗУП?
релиз 3.1.13.220
Да, теперь стоимость часа — другая сумма.
Выяснился еще один нюанс — расчет праздничных включается в средний. В принципе я согласна — это праздники, а не Нерабочие дни. Это так?
Еще один момент — у этого сотрудника в мае еще и отпуск был. Естественно теперь сумма среднего поменялся. Перерасчет сделали в июне. И теперь сумма перерасчета тоже попала в средний. Вот это я считаю неправильно. Как вы считаете?
Ренее, когда 22.04.2019 планировалось провести голосование за поправки в конституцию, этот день тоже был в ПК обычным выходным, который исключается из нормы. Вероятно, порядок отражения нерабочих дней может зависеть от их основания. На данный момент нам остается ждать пояснений.
К сожалению, вручную отредактировать ПК, чтобы 26.06.2019 было нерабочим днем и при этом не исключалось из нормы — невозможно. Можно установить этот день рабочим, чтобы он не исключался из нормы, чтобы пока пересчет не происходил, а после если потребуется пересчитаете. Как правильно: исключить или нет я сказать не могу.
Выяснился еще один нюанс — расчет праздничных включается в средний. В принципе я согласна — это праздники, а не Нерабочие дни. Это так?
Тоже спорный момент. На данный момент в ЗУП все начисления за период нерабочих дней включаются в средний, это признано ошибкой: : https://bugboard.v8.1c.ru/error/000068477 и в будущих релизах ожидаем исправления.
Еще один момент — у этого сотрудника в мае еще и отпуск был. Естественно теперь сумма среднего поменялся. Перерасчет сделали в июне. И теперь сумма перерасчета тоже попала в средний. Вот это я считаю неправильно. Как вы считаете?
Конечно же сумма отпусных сама в средний включаться не должна. В одной теме мы разбираем один вопрос, согласно регламенту сайта. Задайте этот вопрос в отдельной теме, пожалуйста. И приложите сразу скриншоты по ситуации.
Исключить из среднего я не собираюсь. Я задаю вопрос как исправить, но чтобы остались 2 варианта расчета. Перерасчет не регистрируется. Как же отслеживать такие изменения?
Можно ли зарегистрировать перерасчет вручную?
Отдельно вопрос про отпуск задам.
Наталья, извините, я каетя потеряла нить вопроса. В исходном вопросе Вы пишите:
«Исправляю чтобы средний заработок не входил», в комментарии «Исключить из среднего я не собираюсь».
Расчет стоимости часа изменился в связи с измененем ПК, на это мы повлиять не можем, кроме как пока отметить в ПК 24.06 как рабочий. Тогда у Вас не будет меняться стоимость часа. Но не факт, что это верно! Скорее всего, по моим ожиданиям, норма так и останется уменьшенной (как было с 22.04).
«Я задаю вопрос как исправить, но чтобы остались 2 варианта расчет».
Не поняла о чем речь: два варианта расчета чего?
«Можно ли зарегистрировать перерасчет вручную?»
Да, можно как показано вот тут: Как зарегистрировать перерасчет, если обнаружена ошибка в стаже?
Давайте начнем заново.
Сотрудник работал в праздничные дни когда мы еще даже не знали что будет 2 дополнительных выходных дня и средний не будет включаться.
Теперь мы пересчитываем средний и заметили что и расчет праздничных изменился.
При этом перерасчет не зарегистрировался. Т.е. фактически мы могли и не заметить что теперь праздничные мы должны пересчитать. Нам нужно чтобы остался первый вариант расчета праздничных. Т.к. по нему мы и выплачивали. И так же нужно перерасчитать и доплатить. Как нам это отследить и исправить?
Добрый день! Вы имеете ввиду, пересчитать праздничные, чтобы перерасчет не повлиял на прошлый период, а лег текущим периодом. Верно?
В таком случае нужно «принудительно» зарегистрировать перерасчет. Можно добавить информацию в сервис вручную,как показано тут:Как зарегистрировать перерасчет, если обнаружена ошибка в стаже?.
Если же объем большой, то можно попробовать зарегистрировать перерасчет автоматически. Например, отменить проведение документа «Работа в выходные и праздники» и провести их заново. (Документ регистрирует только время, так что на расчетах прошлого периода это не отразится, а вот перерасчет зарегистрируется). Если не ведете документ «Табель»,то есть еще вариант заполнить и провести документ Табель помесячно на нужных сотрудников, а затем отменить его. При этом тоже должен зарегистрироваться перерасчет. И еще одно действие, которое регистрирует перерасчет — изменение графика. Можно скорректировать один любой день, записать, а потом вернуть как было и снова записать. Перерасчет будет зарегистрирован для всех сотрудников, работавших по этому графику.
Как отслеживать такие изменения?
Добрый день! Вы имеете ввиду изменения стоимости часа в связи с изменением «Производственного календаря»? Механизмов, чтобы это отслеживать это в ЗУП нет. Изменения в ПК в 2020 год из-за форс-мажора с коронавирусом, обычно ПК не меняется в течение года.
Вы оказались правы на счет 24.06:этот день теперь учитывается по аналогии с предыдущими нерабочими периодами, т.е. как нерабочий оплачиваемый день, не уменьшающий норму времени. А вот 01.07 обычный выходной день (уменьшающий норму времени). Вышло обновление производственного календаря, которое необходимо обновить вручную в разделе Администрирование (вместе с обновлением релиза автоматически оно не установится).
А поскольку ПК менялся, то сейчас Стоимость часа могла измениться у всех сотрудников, у кого расчет стоимости часа настроен «По норме производственного календаря». Каким отчетом посмотреть порядок пересчета окладов в стоимость часа по сотрудникам?
Понятно.