G_ZARPL
Краткое описание :
системные удержанияОписание :
Расчет удержаний (общие вопросы)Что измененно :
После обновления в средине сентября у клиента началось ==размножаться==== постоянное удержание с кодом 201.
Клиент использовал 201 код для удержания взносов.
Просьба доработать, чтоб удержание работало как и раньше, чтоб расчитанная по проценту сумма удерживалась 1 раз
Как измененно :
Доработан расчет видов удержаний процентом от зарплаты с системными кодами 200-205 при значении "нет" в настройке "... \ Разбивать удержания".
Теперь и при таких значениях в результатах расчета зарплаты формируется только одна запись.
G_ZARPL
Краткое описание :
Расчет нескольких скидок с заполненным остаткомОписание :
Расчет начислений (общие вопросы)Что измененно :
Для сотрудника заведено две постоянных доплаты с типом "Скидка" - "имущественный вычет" (алг.97) и "Вычет за счет взносов"(пользователький алгоритм и тип "Скидка" (сумма скидки соответствует сумме удержания взносов в НПФ)).
В случае если для доплаты "Вычет за счет взносов" заполнен остаток, расчет скидки идет неверно.
Как измененно :
Доработан алгоритм применения сумм с типом "Скидка" при условии, что для данного алгоритма заполнена дополнительная входимость (5) Уточнение к типу оплаты не разбивать.
Теперь при таких условиях в результатах расчета заработной платы общая сумма скидки ограничивается суммой за месяц, рассчитанной по алгоритму.
Наличие остатка в постоянной доплате и других скидок не влияет на расчет.
G_ZARPL
Краткое описание :
Не считается социальный вычет с кодом 640Описание :
Расчет подоходного налогаЧто измененно :
Если в классификаторе годовых ограничений задано ограничение для кода вычета 640, назначаем работнику постоянную доплату 640 и при расчете она есть. Всё хорошо
Но не все клиенты ведут классификатор. Те, у кого пусто (или есть записи, но без заданного кода пользователя 640), столкнулись с тем, что вид 640 вообще не считается, пока не задашь в классификатор запись с кодом 640
Не должно быть такой связки, если в каталоге пусто, то вид оплаты 640 должен считаться, но не учитывать ограничение
Как измененно :
Для Беларуси доработана функция предоставления социальных вычетов с кодом вычета 640.
Теперь годовая сумма вычетов не ограничивается,если для какого - либо года в классификаторе годовых вычетов нет записи или есть запись с нулевой суммой.
G_ZARPL
Краткое описание :
Неверно рассчитывается почтовый сбор, если его оплачивает организацияОписание :
Расчет удержаний (общие вопросы)Что измененно :
Неверно рассчитывается почтовый сбор, если его оплачивает организация.
Рассмотрим на конкретном примере.
Сотруднику введено постоянно удержание
Сотруднику начислили компенсацию за уголь.
После расчета идем в постоянное удержание и видим странные суммы: сумма сбора удвоилась
Как измененно :
Исправлена ошибка расчета почтового сбора для случая, когда у работника атрибуты начисления не совпадают с атрибутами отнесения затрат лицевого счета.
Теперь сумма сбора рассчитывается корректно.
Ошибка проявлялась при значении, отличном от "нет", в настройке "... \ Управление персоналом \ Расчеты с персоналом \ Режимы расчетов \ Разбивать удержания"
G_ZARPL
Краткое описание :
Не отрабатывает функция, если доплата без даты окончанияОписание :
Алгоритмы пользователяЧто измененно :
Не отрабатывает функция PDopProcDate, если доплата без даты окончания.
Как измененно :
Изменения коснулись работы функций PDopProcDate и SrPrDopl. Если доплата содержит пустое значение даты окончания, то при анализе пересечения периода действия доплаты с переданным периодом вместо этого пустого значения даты подставляется дата окончания отчетного или будущего периода.