Возможность округления среднемесячного количества часов

1. gmv 23.06.20 13:22 Сейчас в теме
В нашей организации есть сотрудники, работающие по графикам суммированного учета рабочего времени. На начало года им был оформлен график учета рабочего времени. В нем среднемесячное число часов получилось равным без округления 164,91667, но производственный отдел на предприятии принял решение об округлении этого значения до 164,9. Форма документа графики позволяет сделать такие правки и сохранить их. Что и было сделано. Однако при расчетах доплат за ночные часы в качестве среднемесячного кол-ва часов все равно берется не округленное значение.
Какие изменения должны быть внесены в программу, что учитывались внесенные в графики правки. Возможно что-то делаем неправильно или не доделываем.
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
4. GSokolov 320 23.06.20 21:05 Сейчас в теме
(1) Ну, вообще-то установление своего представления о математической величине среднемесячного числа часов сродни биллю, внесённому когда-то в шате Индиана США, о том что число Пи равно четырём. Вы уж тогда, действительно, вводите своё значение, но не называйте его среднемесячным числом часов.
Svetlana_E; +1 Ответить
2. Ivanov_OM 38 23.06.20 13:33 Сейчас в теме
Там, где производится заполнение реквизита объекта нужно поставить округление:
Объет.СреднееЧислоЧасов = Окр(Объет.СреднееЧислоЧасов,1);

Иначе в данных объекта хранит неокругленное значение, а на форме отображается округленное
3. Svetlana_E 5 23.06.20 16:34 Сейчас в теме
Графики тут вообще не помогут. А главное, есть очень простой способ: поменяйте формулы начислений, введя свой показатель для организации. Вводите его на 01 января.

Вместо
СтоимостьЧаса* ВремяВЧасах * ПроцентДоплатыЗаРаботуВНочноеВремя / 100
используйте
Оклад/ВашПоказатель* ВремяВЧасах * ПроцентДоплатыЗаРаботуВНочноеВремя / 100


Я так сделала в ЗГУ для военнослужащих. У них есть свой похожий предопределенный показатель СреднемесячноеКоличествоЧасовДляОплатВС, который просто считается неверно. Мы ввели свой показатель и все считается как часы - и никуда лезть не надо
5. gmv 24.06.20 07:09 Сейчас в теме
Svetlana_E, спасибо огромное. Да, так можно сделать. Просто и изящно, но у нас лишь для части сотрудников расчет ведется по среднемесячному кол-ву часов, а для части по норме. Тем не менее спасибо.
Ivanov_OM, тоже спасибо. С формулой-то все понятно. Только где то место, где надо округлить. Если на форме графика, то да там все отлично округляется, но в расчете все равно считается не от округленных величин. Надо искать и править. Думала может быть кто-то сталкивался с такой проблемой здесь, чтобы по-быстрее поправить.
GSokolov, допускается округление среднемесячного кол-ва часов до 1 знака после запятой, что и было расписано в приказах предприятия. А как это будет считаться в программе, тех кто принял такое решение совсем не волнует, это проблема программы и не более.
6. Svetlana_E 5 24.06.20 07:56 Сейчас в теме
(5)
у нас лишь для части сотрудников расчет ведется по среднемесячному кол-ву часов, а для части по норме.


Вот это непонятно. Если вы используете одно начисление, то как может считаться по-разному... А кроме того - ну сделайте 2 разных начисления, м.б 2 разных вида времени, усложните формулу, введите условие, чтобы она могла считать и так, и так. Не зная подробнее ваших условий(кому как считать), сложно советовать что-то конкретное. Это совсем несложно и это, с моей точки зрения, намного правильнее, чем лезть в конфигурацию. ЗУП(ЗГУ) сейчас обладает столькими возможностями для "точечной" настройки, что можно реализовать даже очень сложные алгоритмы.
7. GSokolov 320 24.06.20 09:17 Сейчас в теме
(5)
А как это будет считаться в программе, тех кто принял такое решение совсем не волнует, это проблема программы и не более.
Это проблема качества принимаемых решений. Вот для чего, с какой целью приняли округление этой величины, когда она программой подсчитывается автоматически? В чём глубокий смысл? Чтобы бухгалтеру, программисту или администратору 1С жизнь мёдом не казалась?
8. gmv 24.06.20 21:32 Сейчас в теме
Я уже давно перестала искать смысл в решениях тех, кто наделен полномочиями их принимать. Бороться с такими бедами себе дороже, обычно делаю как просят, а там пусть сами разбираются с результатами своих "умничаний". Но это болтология, а делать надо.
9. GSokolov 320 25.06.20 16:24 Сейчас в теме
(8) Я как-то не обратил внимания, что это графики с СУРВ. Среднемесячное число часов для расчёта ЧТС из оклада определяется вообще-то не по графику, даже если оно там есть, а по производственному календарю для соответствующей продолжительности рабочей недели и в 2020 году составляет 164,25 часа для 40-часовой. Графики работников ведь по ТК РФ за учётный период должны соответствовать по рабочему времени производственному календарю. Если в графике кол-во рабочих дней и часов в год отличается от ПК, этот показатель в графике как-то там ещё дополнительно нормируется. И в расчёте зарплаты используется другой, уже результирующий показатель - СтоимостьЧаса. Точность его в программе - 5 знаков после запятой. Вот его в Показателях Начислений можно изменять.
Однако, устанавливать оплату по окладу в случае СУРВ - верх непредусмотрительности. Там должна использоваться оплата по ЧТС. В этом случае ничего не нужно пересчитывать и заморачиваться с округлением.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот