G_SUMDIVIDE
Краткое описание :
Доплата при замещенииОписание :
Рабочая корзина (обработка сигнала)Что измененно :
После утверждения приказа о временном заместительстве и добавлении в этом приказе доплаты за заместительство процентом от оклада до замещения сотрудника, который замещает, возникает следующая проблема при предварительной разноске.
Поскольку оклад и остальные параметры в доплате совпадают со значением в лицевом счете, доплата воспринимается и обрабатывается не как доплата по замещению, а как доплата по основному назначению: значение оклада, должности и т.д. при предварительной разноске берется на дату начала сторнирования доплаты с учетом переходов в межпериод. Получаем в предварительном просмотре не старый оклад, а новый.
Нужно, чтобы для таких доплат параметры переносились в результат предварительной разноски без изменений, даже если их значение совпадает со значением в лицевом счете.
Как измененно :
Добавлен дополнительный признак доплаты, описывающий способ выбора значений из доплаты при предварительной разноске. Признак можно просмотреть и переключить по F3 при редактировании постоянных доплат (поле "Выбор значений", возможные значения: "из постоянной доплаты при условии различия с ЛС", "из постоянной доплаты").
Для доплат с выбором значений "из пост. доплаты при условии различия с ЛС" предварительная разноска переносит данные в предварительный просмотр с учетом переходов, если значения совпадают со значениями в лицевом счете; и без изменений, если значения не совпадают. Для доплат с выбором значений "из пост. доплаты" параметры всегда переносятся в предварительный просмотр без изменений.
Доплаты, создаваемые в Рабочей корзине из приказов по заместительству или совместительству, создаются с признаком выбора значений "из постоянной доплаты".
# ИНСТРУКЦИЯ ПО НАСТРОЙКЕ:
Для доплат, созданных до установки данного обновления, значения будут браться по умолчанию "из постоянной доплаты при условии различия с ЛС" (для сохранения прежнего поведения системы). Если для таких доплат потребуется другая обработка, то признак нужно будет переключить вручную.
G_SUMDIVIDE
Краткое описание :
Не работает настройка ввода ШПЗ с клавиатуры в окне отпусковОписание :
Предварительная разноскаЧто измененно :
Не работает настройка ввода ШПЗ, ТХО и Параметра "Ввод с клавиатуры в окне редактирования".
Заполненные при расчете отпуска значения не переносятся. В дебет попадает значение из классификатора или из лицевого счета, в зависимости от значения настройки "Приоритет формирования дебета по начислениям".
Как измененно :
Исправлено. Настройка ВО для ШПЗ, ТХО, Параметра "Ввод с клавиатуры в окне редактирования" отрабатывает корректно:
значения параметров, введенные в окне расчета и корректировки отпуска, переносятся в результаты предварительной разноски.
G_SUMDIVIDE
Краткое описание :
Очередная проблема по расчету больничного по правилам 2010г.Описание :
Расчет больничныхЧто измененно :
Установлено значение нет в настройке:
"Настройки Галактики \ Управление персоналом \ Общие настройки \ Больничные,
отпуска, расчеты по среднему \ Больничные \ Особенности расчета \ Учет истории
увольнений при расчете по правилам 2010 года".
Получилось, что у совместителя есть запись в истории с 01.01.2011 по
31.03.2011, потом он был повторно принят.
Так вот несмотря на то, что по основному счету повторных приемов не было и
работает он с 2009 года, доход по совместительству за указанный период не учтен
(хотя был учтен доход по другим совмещениям за более ранний период). Вопрос
почему?
Ведь если бы совместительство было оформлено доплатой - вы бы взяли ее в расчет.
Как измененно :
Доработан расчет больничных листов со значением "нет" в
настройке:
"Настройки Галактики \ Управление персоналом \ Общие настройки \ Больничные,
отпуска, расчеты по среднему \ Больничные \ Особенности расчета \ Учет истории
увольнений при расчете по правилам 2010 года".
С этим значением настройки для смежных ЛС учитывается история основного ЛС.
Собственная история приемов и увольнений для смежного лицевого счета в данном
случае значения не имеет.
G_SUMDIVIDE
Краткое описание :
Проблема в разноске видов оплат с вход. "Период оплачиваемых неявок"Описание :
Предварительная разноскаЧто измененно :
Проблема в разноске видов оплат с вход. "Период оплачиваемых неявок".
1. Настройки вида оплаты: в расчет " + ", за период опл.неявок "+".
2. Назначаем сотруднику постоянную доплату
3. Сотрудник работает на вахтовом режиме работы, и на февраль по этому режиму приходится "межвахтовый отдых", т.е. по графику у сотрудника в феврале только выходные дни. Но его отправили на следующую вахту раньше (29/02/2012).
4.В табеле нет рабочих дней, кроме оплачиваемого отклонения.
5. Делаю разноску, и 36 ВО в просмотре отсутствует
6. Теперь меняю график. Ставлю Рабочий день 01.02.
7. Делаю разноску, и 36 ВО появляется:
Как измененно :
Доработана функция "Предварительная разноска" для доплат, имеющих настройку "+" в поле "Период оплачиваемых неявок".
Ранее такие доплаты не попадали в расчет, если в плановом графике работника не было рабочих дней.
Теперь такие доплаты в расчет попадают при наличии оплачиваемой неявки.
G_SUMDIVIDE
Краткое описание :
При расчете больничного по беременности и родам по периодам
данные совм. не учитОписание :
Расчет больничныхЧто измененно :
При расчете больничного по беременности и родам по периодам
данные совм. не учитываются.
Хотя данные по совместителю видны в отладочном протоколе, в распечатку расчета
они не попадают.
см вложение.
Как измененно :
При расчете больничного по беременности и родам по периодам
данные совместителей учитываются.
Данные по совместителю видны в отладочном протоколе, в распечатку расчета тоже
попадают.
G_SUMDIVIDE
Краткое описание :
ТХО в результаты расчета попадает из ЛС, а нужно из Вида ОплатыОписание :
Предварительная разноскаЧто измененно :
ТХО в результаты расчета попадает из ЛС, а нужно из Вида Оплаты
ТХО нужно для формирования разной аналитики на затратных счетах по разным видам оплат.
Пример во вложении.
Как измененно :
Исправлена обработка выбора ТХО для вида оплаты в предварительной разноске. При вводе ночных через корректировку в табеле ТХО в результаты расчета попадает не из ЛС, а из Вида Оплаты, т.к. в классификаторе ВО стоит значение ТХО = из классификатора вида оплат= . ТХО нужно для формирования разной аналитики на затратных счетах по разным видам оплат).
G_SUMDIVIDE
Краткое описание :
Разные результаты предварительной разноски при одинаковых доплатах.Описание :
Предварительная разноскаЧто измененно :
Разные результаты предварительной разноски при одинаковых доплатах.
сотрудницы Денисовой в одном лицевом счете начисляется зарплата по основному месту работы работы по пятидневке и по совмещению по 0,5 ставки по шестидневке, т.е. разные графики в доплатах.
Она была в командировке, поэтому при расчете по пятидневке у нее 16 рабочих дней, а по шестидневке - 19 рабочих дней.
Доплата за должность доцента по шестидневному графику №204 расчитывается неправильно.
При расчете доплаты за должность доцента по шестидневному графику проставляется 15 рабочих дней 120 часов вместо 19 рабочик дней 56 часов, хотя абсолютно аналогичная по настройкам в классификаторе доплата №247 6.5% расчитывается правильно.
что интересно, алгоритм один и тот же, график тоже один и тот же №279, а результат разный. смотрели в таблице doplata, никаких различий.
Во вложенных файлах Сводный отчет, доплаты, и для наглядности результаты предварительной разноски.
Как измененно :
\r\nРG_SUMDIVIDE
Краткое описание :
Неверно разбиваются виды оплат в предварительной разноскеОписание :
Предварительная разноскаЧто измененно :
При параметре = не разбивать, по окладу формируется лишняя запись.
Как измененно :
Исправлено формирование предварительной разноски с параметром "не разбивать". Ошибка проявлялась при наличии перехода в межпериод.
Теперь, при разноске с указанным параметром, для основной оплаты формируется только одна запись за месяц.
G_SUMDIVIDE
Краткое описание :
Больничный по уходу не должен перекрывать основной отпускОписание :
Формирование табеляЧто измененно :
Ситуация:
Человеку оформлен основной отпуск с 27.06.2011 по
01.07.20011. С 16.06.2011 по 29.06.2011 у него лист
нетрудоспособности по уходу за ребенком до 3-х лет. По
законодательств больничный не должен перекрывать
отпуск. Т.е. в табеле мы должны видеть 27, 28, 29 -
"О". Сейчас любой больничный забивает отпуск. Если в
настройке типа отпуска поставить "Отменяет выплату
больничных", тогда работает правильно с такими
больничными, но и отменяет обычные больничные, чего
быть не должно. Необходимо, чтобы для больничных по
уходу отпуск перебивал дни и в листке
нетрудоспособности несмотря на введенные даты
накладывающиеся на отпуск считал правильно количество
дней, которые будут отражены в табеле.
Как измененно :
Согласно существующей реализации больничных "по уходу" в системе ГАлактика - такими больничными являются листки нетрудоспособности, с кодом больше 50. При пересечении таких больничных с отпусками, они не сдвигают отпуска. После выполненной доработки, на период пересечения таких больничных, в табеле сейчас будет отражаться условное обозначение отпуска, а не больничного.
G_SUMDIVIDE
Краткое описание :
функция не всегда учитывает настройку - проблемы с приказамиОписание :
Переводы с начала месяцаЧто измененно :
Установлена настройка "Автообновление данных "Кадров""-"Табельные номера"=НЕТ.
Для замены табельного номера используется сервисная функция "Переводы с начала месяца". Тогда после замены табельного номера в модуле Управление персоналом меняется номер у назначения (данное поле недоступно пользователям для просмотра). В итоге, при работе с приказами с РПД=3,5,6,9,10,13,40,41,50,60,62,65,70,72,90,91
возникает путаница при выборе сотрудника из списка: в списке у сотрудника один табельный номер, а после выбора в приказе светится другой.
Как измененно :
Теперь при замене табельного номера в назначениях сотрудника учитывается значение настройки "Автообновление данных "Кадров""-"Табельные номера". Таким образом, после замены табельного номера сотрудника табельные номера в карточке и в назначении (скрытое поле) будут совпадать, и противоречие при выборе сотрудника в приказе не возникнет.
G_SUMDIVIDE
Краткое описание :
34 Доп. входимость не обрабатывает несколько переходов в межпериодОписание :
Предварительная разноскаЧто измененно :
у сотрудника было 2 перехода в октябре: один с 1
октября постоянный с повышением оклада. второй - с 1 по
31 октября временный с изменением аналитики.
если внести в систему сначала временный переход с
изменением аналитики, затем постоянный переход и
изменением оклада, то ошибка проявляется.
если сначала внести постоянный переход с изменением
оклада, затем внести временный переход с изменением
аналитики, то ошибка не проявляется.
если у сотрудника будет только один временный переход с
изменением аналитики, то ошибка также не
проявляется.
еще у 2 сотрудников ту же проблему удалось решить
наоборот: сначала создали временный переход с
изменением аналитики, потом постоянный с изменением
оклада.
Как измененно :
Доработана функция "Предварительная разноска" для доплат,
у которых установлена дополнительная входимость
(34) Для затрат не учитывать переходы c датой окончания.
Теперь для таких доплат не имеет значения последовательность ввода постоянных и временных переходов.
G_SUMDIVIDE
Краткое описание :
расчет б/листов по беременности и родам, а так же по уходу за ребенкомОписание :
Расчет больничныхЧто измененно :
При расчете б/листов по беременности и родам, а так же по уходу за ребенком (мужчинам и женщинам), суммарный размер доплаты до среднего заработка и государственного пособия не может превышать двух должностных окладов за
каждый месяц расчетного периода нетрудоспособности с учетом районного коэффициента и процентной надбавки,
применяемых в соответствии с законодательством к з/плате работников.
Если суммарный размер доплаты до
среднего заработка и государственного пособия меньше двух окладов работника, то никаких ограничений до двух
окладов применяться не должно.
Пример:
У работника основной заработок за два года составил 1782722,06 рубля за два предыдущих года.
Текущий оклад у работника 40000 рублей.
Должно получиться:
1782722,06/730=2442,08 (средняя) * 30 дней болезни = 73262,40
Из этих сумм 36082,20 - за счет ФСС, 37180,50 - за счет предприятия
Таким образом, ограничение по нашему алгоритму не должно отрабатывать, потому что сумма 2-х окладов
составляет 80000 рублей.
Если бы оклад работника был 30000 рублей, то работник получил бы 36082,20 - за счет ФСС, плюс
23917,8 - за счет предприятия, т.е. 60000 рублей.
Как измененно :
Добавлено новое значение "да, но не более суммы по алгоритму" настройки "Настройки Галактики \ Управление персоналом \ Общие настройки \ Больничные, отпуска, расчеты по среднему \ Больничные \ Ограничения \ Оплачивать превышение ограничения пособия".
2. Доработан расчет больничных листов. При выборе нового значения настройки рассчитывается превышение ограничения до среднего заработка. Если сумма больничного с учетом превышения больше суммы, которая рассчитана по алгоритму, сумма ограничивается суммой по алгоритму, который привязан к виду оплаты для превышения.
3. Доработана справка о расчете больничных с ограничением.
Примечание.
Напомним, что, если к виду оплаты, которым оплачивается превышение, привязан алгоритм 2, то превышение оплачивается по алгоритму, который используется для значения настройки "да" .
Пользовательский алгоритм заказчика будет следующим:
if(uch_summa>0 ,uch_summa,(SumAlgNo(3) + SumAlgNo(3) * GET_RK(UCH_DATAN,UCH_DATOK)/100)*2)