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. Не понятно, каковы критические параметры, т.е. при расчете какого количества пользователей мы можем получить вываливание по рантайму.
Нет уверенности в том, что это не произойдет и при расчете ЗП по подразделению
Как измененно :
Исправлен рантайм в предварительной разноске, который происходил при обработке постоянных доплат.