Оплата работы в выходные дни

Вопрос задал Ирина Ф.

Ответственный за ответ: Щелкунова Юлия (★9.81/10)

Здравствуйте! Конфигурация 1С ЗУП 3.1.15.97. При расчете повышенной оплаты за работу в выходные дни непонятным образом рассчитывается среднедневная ставка. В настройках стоит флажок использовать «Среднемесячное количество часов(дней) в месяце», почасовой расчет не используется. Получается, что для расчета оклад делится на среднемесячное количество дней = 22,7333333525. Откуда берется такое значение? Если установить флажок — использовать «Норму времени по графику сотрудника», то берется 23 дня (для декабря).

Все комментарии (5)

  1. Здравствуйте. Это значение берется из графика работы (сумма дней во всех месяцах/12). Проверьте, правильно ли заполнены графики на год.

  2. Добрый день! Графики проверяли, график — пятидневка, там стоит среднемесячное количество часов 164,91667 и среднемесячное количество дней 20,667.

  3. Здравствуйте! Для проверки, приложите, пожалуйста:
    -скриншот расчета, где будет видно Стоимость часа
    -скриншот графика работы сотрудника (среднемесячное кол-во часов). У него не менялся график работы в течение месяца?
    -Скриншот из регистра «Плановый ФОТ итоги» с отбором по этому сотруднику. Чтобы было видно колонку «Совокупная тарифная ставка».

  4. Добрый день! Дело в том, что у нас было принято решение посчитать не по среднемесячному количеству дней, а с флажком — использовать «норму дней по графику». Перед этим проверили все: большая часть сотрудников работает по пятидневке (в графике стоят правильные значения среднемесячного количества дней и часов), почасовая оплата не используется, поэтому считается среднедневная ставка. Совокупная тарифная ставка правильная (оклад + надбавка). Я решила сделать скриншоты в копии базы, и вот после обратного переключения флажка на «среднемесячное количество часов(дней) в месяце», получился правильный расчет, т.е. с использованием среднемесячного количества дней = 20, 667, как в графике. Получается, что для исправления ошибки нужно переключить способ расчета на другой, а потом вернуть обратно. Это подтвердилось и в в рабочей базе. Каким образом получалось значение 22,73333 осталось неизвестным.

    1. Здравствуйте! Хорошо, что проблема решилась! 🙂
      В чем могла быть причина, к сожалению, затрудняюсь сказать, не получив информации из базы «до».

Комментарии закрыты.