G_ZARPL
Краткое описание :
Неверный расчет пенсионного взноса при превышении облагаемой базыОписание :
Расчет обязательных взносов (удержаний)Что измененно :
При превышении облагаемой базы максимального ограничения и наличии начислений в прошлых месяцах за текущий неверный расчет пенсионного взноса с сотрудника.
Как измененно :
При разбиении удержаний по "входящим оплатам" и наличии начислений в прошлых месяцах за текущий и удержанных пенсионных взносов с сотрудника без учета максимального ограничения, производится сторнирование разницы удержанных пенсионных взносов и рассчитанных взносов с учетом максимального ограничения с начислений, начисленных в прошлом за текущий. Для данного удержаний поле "Вид оплаты" не будет заполнено.
Если же значение настройки "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Режимы расчетов \ Разбивать удержания" не равно "нет", и не нужно разбивать удержание с ВУ 175, то необходимо в КВУ для 175 ВУ указать "учитывать в подразделении на начало месяца" или "учитывать в подразделении на конец месяца". В данном случае 175 ВУ разбиваться не будет и расчет будет произведен верно с учетом удержанных пенсионных взносов в прошлых месяцах за текущий.
G_ZARPL
Краткое описание :
Разбивать пенсионный взнос 1% (ВУ 175) по подразделениямОписание :
Расчет обязательных взносов (удержаний)Что измененно :
аВ связи с частыми переводами работников в межпериоде а возникает необходимость в разбивке удержаний по разным подразделениям предприятия и включения их с разбивкой в свод (отчет ОВР, например), как и начисления.
Используем настройку Разбивать удержания-по подразделениям переходов межпериода, но удержание 175 не разбивается (хотя в настройках ву стоят параметр: разбивать по подразделениям отнесения затрат)
Просьба внести изменения и разбивать код 175 "Удержания в Пенсионный фонд", аналогично другим удержаниям.
Как измененно :
Для Беларуси доработана функция расчёта удержания в пенсионный фонд с учётом а значений настройки "...\ Управление персоналом \ Расчеты с персоналом \ Режимы расчетов \ Разбивать удержания".
Теперь удержания разбиваются и для следующих значений: "по подразделениям переходов межпериода" и "по подразделениям постоянных переходов"
а
а
G_ZARPL
Краткое описание :
неверно считается НДФЛОписание :
Расчет подоходного налогаЧто измененно :
Неверно считается НДФЛ для значения отличного от "нет" в настройке "...\ Налог на доходы \ Раздельный расчет по обособленным подразделениям" и наличием скидки.
Как измененно :
Исправлена неверная работа системы при расчете НДФЛ для значения отличного от "нет" в настройке "...\ Налог на доходы \ Раздельный расчет по обособленным подразделениям" и наличием скидки больше дохода за месяц.
Примечание.Анализ базы данных показал, что у работника для 5-го месяца в записи НДФЛ для повременной оплаты неправильно заполнена сумма дохода.
В связи с этим обстоятельством, до расчёта заработной платы необходимо выполнить функцию Галактика ERP \ Персонал \ ЗП \ =Настройка= \ Сервисные функции \ Налог на доходы физических лиц \ Контроль и корректировка удержаний (через запуск внешнего интерфейса Z_Service::FindIncorrectUder)
G_ZARPL
Краткое описание :
Неверный расчет НДФЛОписание :
Расчет подоходного налогаЧто измененно :
Установлены настройки:
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ Раздельный расчет по обособленным подразделениям" = "из дополнительных аналитик"
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ Сторнирование и возврат \ Возвращать налог за счет вычетов" = "нет"
Текущий месяц - сентябрь, в августе удержано налога больше на 546 руб.
Если установить количество месяцев для сторнирования - 2, то на текущих обновлениях, август "выравнивает", то все равно добирает эти 546 руб. в сентябре.
Влияет настройка "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ Сторнирование и возврат \ Возвращать налог за счет вычетов".
Если установить ее в значение "да", то НДФЛ считает правильно, в значение "в декабре или месяце увольнения" - аналогично "нет", т.е. добирает лишний.
Как измененно :
Исправлена неверная работа системы при расчете НДФЛ для значения отличного от "нет" в настройке "...\ Налог на доходы \ Раздельный расчет по обособленным подразделениям" при наличии стандартных вычетов и отсутствии дохода за месяц.
Теперь в таких случаях НДФЛ считается правильно для всех значений настройки "...\ Налог на доходы \ Сторнирование и возврат \ Возвращать налог за счет вычетов".
G_ZARPL
Краткое описание :
Неправильно считается НДФЛ при наличии вычетаОписание :
Расчет подоходного налогаЧто измененно :
В межрасчетный период начислено 10600. При наличии вычета на ребенка 1400, система правильно выполняет расчет межрасчетной выплаты. Также в межпериод перечислены суммы выплаты и подоходного налога. При расчете аванса с галочкой "РАСЧЕТ АВАНСА В РЕЖИМЕ ЗА ПЕРИОД" , когда у работницы есть 1 рабочий день, система неправильно выполняет расчет НДФЛ. Не учитывается вычет из расчётов сежпериода, в результате чего образуется долг, которого не должно быть.
Как измененно :
Для России доработана функция расчёта заработной платы с параметром "РАСЧЕТ АВАНСА В РЕЖИМЕ ЗА ПЕРИОД".
Теперь, дополнительно анализируются реестры на перечисление НДФЛ.
Если в учётных суммах операций к реестру присутствует вычет, то он отнимается от суммы положенных вычетов и не применяется к суммам, участвующим в расчёте аванса.
Примечание. Доработка актуальна при любых значениях настройки "...\ Расчеты с персоналом \ Налог на доходы \ Раздельный расчет по обособленным подразделениям"
G_ZARPL
Краткое описание :
Новый алгоритм похожий на NachD(O)Описание :
Расчет начислений (общие вопросы)Что измененно :
Вышло письмо Конституционного суда 26п от 28.06.18., что нужно при расчете оплаты ночных (праздничных, выходных) учесть компенсационные и стимулирующие выплаты. Поэтому начали обращаться клиенты с просьбой настроить алгоритм расчета оплаты с учетом доплат.
Если у сотрудника меняется режим работы, то при оплате ночных (праздничных, выходных) это тоже нужно учесть.
Получается, нужно собрать суммы (основная оплата+некоторые доплаты) за период по каждому переходу, разделить на количество часов из входящей оплаты и умножить на количество часов ночных (праздничных, выходных) и на процент.
Подошла функция NachD(O), но она дает нужный результат только если период во входящей оплате (основная, доплаты) не полностью совпадает с периодом оплаты ночных. Если период полностью совпадает собранная сумма не пересчитывается. Нужно чтобы пересчитывалась независимо от того полностью совпадает период или нет. Предлагаю для этого разработать новую функцию похожую на NachD(O), которая будет всегда делить сумму входящего начисления на количество часов из него и умножать на количество часов в рассчитываемой оплате.
Как измененно :
Доработана функция NACHD для начислений с совпадающими периодами. Добавлена дополнительная проверка на совпадение времени.
Теперь сумма пересчитывается и в том случае, если периоды совпадают, но количество дней/часов в расчётной оплате меньше, чем в той, которая входит в неё.
В протокол расчётного алгоритма NACHD добавлена соответствующая информация
G_ZARPL
Краткое описание :
Настройка "Разбить пособие на основную и дополнительную суммы" для БеларусиОписание :
НастройкаЧто измененно :
Настройка "Разбить пособие на основную и дополнительную суммы" для Беларуси
Путь: Настройки Галактики -> Управление персоналом -> Больничные, отпуска,
расчеты по среднему -> Больничные -> Продолжительность.
Использование настроек "Разбить пособие на основную и дополнительную суммы"
и "Количество дней для основной суммы" противоречит Белорускому
законодательству. Следует сделать их неактивными при настройке на Беларусь.
Как измененно :
Скрыты настройки "Разбить пособие на основную и дополнительную суммы" и "Количество дней за счет работодателя" для Республики Беларусь.
G_ZARPL
Краткое описание :
Нужна возможность рассчитывать алименты фиксированной суммой, равной доле от прожиточного минимума, с последующей индексацией по мере его измененияОписание :
Алименты, исполнительныеЧто измененно :
Нужна возможность рассчитывать алименты фиксированной суммой, равной доле от прожиточного минимума, с последующей индексацией по мере его изменения.
Расчетчик зарплаты получил исполнительный документ с решением суда о том, что в случае этого сотрудника алименты нужно рассчитывать как половина детского прожиточного минимума региона (респ. Татарстан) на каждого из 3 детей. Согласно 117 ст. семейного кодекса индексацию размера алиментов организация, которая получила исполнительный документ, должна выполнять сама.
Как измененно :
В типах удержаний алименты, добавлено новое поле "Каталог" с возможностью выбора каталога для расчета ежемесячной суммы удержания (Прожиточный минимум (ПМ), Базовая величина (БзВ)) либо оставлять поле "Каталог" "пусто". Поле "Количество базовых величин" сдвинуто вправо. В зависимости от выбора значения поля "Каталог" изменяется наименование в поле "Количество базовых величин" на "ПМ" или "БзВ" , если поле "Каталог" пусто, то значение в поле "Количество базовых величин" становится равным 0, а само поле скрывается и в расчете не участвует . Если в настройках указана страна Беларусь, то Прожиточный минимум (ПМ) изменяется на "Бюджет прожиточного минимума (БПМ)".