G_SUMDIVIDE
Краткое описание :
Функция, по расчету доплаты для текщего ЛС по
среднедневному заработоку другого ЛСОписание :
Алгоритмы пользователяЧто измененно :
Нужна функция, которая позволяла бы сделать такой расчет:
доплата за совмещение сотруднику Иванову, чтобы расчет был по среднему
заработку за 3 месяца сотрудника Петрова, за которого оформляется совмещение.
Среднедневной заработок сотрудника Петрова должен считаться в постоянной
доплате сотрудника Иванова. И хотелось бы, чтобы выводился протокол расчета
(наподобии выходного пособия, отпуска)
Как измененно :
Разработана функциональность, позволяющая формировать и
рассчитывать постоянную доплату работнику, временно замещающего другого
работника.
Временное замещение может оформляться Приказом РПД-3 "Временное замещение
БЕЗ ОСВОБОЖДЕНИЯ от своих обязанностей" или без оформления приказа, а просто
заведением постоянной доплаты с указанием замещаемого сотрудника.
Доработка состоит из следующих этапов:
1. При утверждении РПД-3 на "Временное замещение БЕЗ ОСВОБОЖДЕНИЯ от своих
обязанностей", в котором предварительно сформирована доплата за замещение,
формируется сигнал а Рабочую корзину. При обработке Рабочей корзины создается
Доплата в модуле Заработная плата. При формировании доплаты формируется ссылка
на замещаемого сотрудника. В интерфейсе постоянных доплат добавлено поле
"Замещает сотрудника", в котором отображается ФИО замещаемого сотрудника. Кроме
того, это поле можно корректировать и заполнять независимо от наличия приказа.
2. Доработан функционал по расчету заработной платы при расчете Доплаты по
среднему за замещение. Расчет среднего заработка осуществляется по алгоритму,
указанному в классификаторе видов оплат с учетом данных ЗАМЕЩАЕМОГО сотрудника,
если он указан в соответствующем поле интерфейса постоянных доплат.
3. В процессе расчета доплаты выдается справка о расчете среднедневного
заработка, в которой указывается ФИО замещаемого сотрудника и процент доплаты.
При необходимости так же выводится протокол о расчете среднедневного заработка
с аналогичной информацией.
G_SUMDIVIDE
Краткое описание :
Больничный - неправильно ограничивается СДЗ для переходящих на след. год пособий по БиРОписание :
Применение ограничений по больничным листамЧто измененно :
Больничный по БиР начинается в 2014 г., а заканчивается в 2015 - см. вложенный файл 1.
Либо больничный целиком 2015 г., но он является продолжением больничного 2014 г. - см. вложенный файл 2.
Тогда при расчёте больничного для месяцев 2014 г. применяется ограничение СДЗ 2014 г. (1479.45), а для месяцев 2015 г. - ограничение 2015 г. (1632.88). Это неверно, в 255-ФЗ сказано так:
3.3. Средний дневной заработок для исчисления пособия по беременности и родам, ежемесячного пособия по уходу за ребенком ... не может превышать величину, определяемую путем деления на 730 суммы предельных величин базы ... на два календарных года, предшествующих году наступления отпуска по беременности и родам, отпуска по уходу за ребенком.
Т.е. в обоих примерах во всех месяцах должно учитываться ограничение 2014 года 1479.45.
Дополнение: в форме расчёта "Альтернативный вариант (FastReport)", в отличие от БТ, ограничение во всех м-цах показано правильно 1479.45 (колонка "Огран."). Но реально суммы месяцев 2015 г. рассчитаны с ограничением 1632.88.
Как измененно :
Доработан выбор ограничения СДЗ для пособий по БиР по настройке на страну "Россия".
Теперь ограничение выбирается по дате начала заболевания, согласно законодательству.
G_SUMDIVIDE
Краткое описание :
При расчете ЗП Галактика стала падать по рантаймуОписание :
Предварительная разноскаЧто измененно :
При расчете ЗП Галактика стала падать по рантайму
Проблема стала проявляться после установки обновлений от 19.01.2015
При расчете ЗП по всему предприятию у клиента стали появляться ошибки (см. DOC-файл во вложении).
Дополнительно было установлено, что эти ошибки в логе драйвера сопровождались выдачей сообщений о том,
что значение параметра экземпляра Oracle OPEN_CURSORS=5000 превышено.
После увеличения значения параметра Oracle расчет ЗП все равно завершился падением по рантайму (Atlerror.log и скрин с ошибками -
во вложении).
Далее было установлено, что в процессе расчета ЗП процесс Atlexec.exe добирается до 2Гб оперативки, вследствие чего и происходит падение.
Т.к. в процессе расчета клиент ничего не менял, и до установки последних обновлений Галактики расчет по всему предприятию (порядка 4-5 тыс. человек) не
вызывал апокалипсиса, то, полагаем, это привнесено обновлениями системы.
Пока клиент перешел на расчет ЗП по подразделениям, но
1. Налицо явный рост использования системных ресурсов при работе одного и того же механизма после обновлений системы.
2. Расчет ЗП по подразделениям в основе своей клиента не устраивает.
3. Не понятно, каковы критические параметры, т.е. при расчете какого количества пользователей мы можем получить вываливание по рантайму.
Нет уверенности в том, что это не произойдет и при расчете ЗП по подразделению
Как измененно :
Исправлен рантайм в предварительной разноске, который происходил при обработке постоянных доплат.