G_ZARPL
Краткое описание :
Неверное значение поля "источник данных"Описание :
Расчет начислений (общие вопросы)Что измененно :
Неверное значение поля "источник данных"
Была начислена мат.помощь к отпуску + районный коэффициент и сформирован реестр на общую сумму.
В архиве начислений, параметр "источник данных" различается для видов оплат по мат. помощи и РК.
Как измененно :
Доработана функция формирования результатов расчета заработной платы для районных коэффициентов и северных надбавок.
Теперь, если районные коэффициенты и северные надбавки начисляются в межпериод, поля источник данных и ссылка на источник заполняются, исходя из тех начислений, на которые начислялись указанные надбавки.
G_ZARPL
Краткое описание :
Не формировать отрицательный НДФЛ до конца налогового периодаОписание :
Расчет подоходного налогаЧто измененно :
У нас установлена настройка "возвращать налог за счет вычетов" = нет.
"вычеты переносятся на следующий месяц" = да.
С 04 месяца сотрудница начинает получать доход меньший вычету за месяц. С 05 месяца система формирует отрицательный НДФЛ.
Нужно настроить так, чтобы налог не возвращался за счет вычетов до окончания налогового периода (или до месяца увольнения или до декабря).
Как измененно :
Доработан расчет НДФЛ для РФ с настройкой "возвращать налог за счет вычетов" = нет.
"вычеты переносятся на следующий месяц" = да.
Учтен случай, когда работник несколько месяцев подряд получает доход меньше вычета за месяц. Теперь налог не возвращается за счет вычетов до окончания налогового периода.
Примечание :
Для того, чтобы НДФЛ возвращался в конце налогового периода или в месяце увольнения работника необходимо установить значение: "в декабре или в месяце увольнения" для настройки "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ Сторнирование и возврат \ Возвращать налог за счет вычетов".
G_ZARPL
Краткое описание :
Не сторнируется запись с нулевой суммой (вид оплаты, привязанный к неявке по невыясненным причинам НН)Описание :
Сторнирующие записиЧто измененно :
Не сторнируется запись с нулевой суммой (вид оплаты, привязанный к неявке по невыясненным причинам НН)
Пример:
Сотрудник заболел. Когда в табеле сотрудника проставляются дни неявки по невыясненным причинам (к неявке привязан вид оплаты №200 с алгоритмом №99, с доп.входимостью №29 с примечанием "разноска и расчет", и доп. входимостью №31 с примечанием "пересчитывать по дням" ), а затем в следующем месяце человек сдает больничный лист, то при вводе этого больничного происходит создание сторнирующей записи на дни неявки. Соответственно, при последующем расчете зарплаты должно произойти сторнирование ВО №200, и этот ВО должен отобразиться с "минусом" в результатах расчета, чего не происходит, т.к. сумма начисления по данному ВО равна нулю (хотя у ВО есть доп.входимость 29).
Сейчас сторнированный ВО №200 формируется при разноске в предварительном просмотре, но в результаты расчета не попадает. Если сумму начисления изменить на ненулевую, то в результаты расчета она попадет.
Как измененно :
Исправлена ошибка по формированию в результатах расчета записи за прошлый период с алгоритмом 99 и доп. входимостью №31 с примечанием "пересчитывать по дням" и пометкой "СБ".
Теперь такие записи попадают в результаты расчета, причем один раз.
G_ZARPL
Краткое описание :
Удержания по перечислению в банк в результатах расчетаОписание :
Расчет удержаний (общие вопросы)Что измененно :
Нужно исправить разбивку удержаний по перечислению зарплаты в банк ещё в одной ситуации.
Опишу ситуацию на примере.
Работнику рассчитан аванс за работу с 01/07/2014 по 15/07/2014:
Сформирован реестр на перечисление аванса в банк:
После этого работник принёс больничный с 10/07/2014 по 20/07/2014. Этот больничный был рассчитан в Галактике с выплатой "С зарплатой".
То есть, узнали о том, что работник находится на больничном, уже после выплаты аванса (аванс выплачен так, как будто работник не был на больничном). Такая ситуация возникает довольно часто, особенно на предприятиях с большим количеством сотрудников.
Затем, в конце месяца, была рассчитана зарплата за весь месяц.
Разбираем результаты расчета.
Рассмотрим удержания с кодом 220. По-идее, должно было сформироваться 3 записи удержаний с кодом 220:
1) перечисление больничного за счет предприятия в банк
Дата начала: 10/07/2014
Дата окончания: 14/07/2014
Сумма: 456,32
Доп. аналитики: заработная плата, начисленная(выплаченная)\Предприятие
2) перечисление больничного за счет ФСС в банк;
Дата начала: 15/07/2014
Дата окончания: 20/07/2014
Сумма: 608,42
Доп. аналитики: заработная плата, начисленная(выплаченная)\ФСС
3) удержание по перечислению зарплаты
Дата начала: 21/07/2014
Дата окончания: 31/07/2014
Сумма: 813,17
Доп. аналитики: заработная плата, начисленная(выплаченная)\ФСС
Фактически программой сформированы 2 записи, суммы в которых не соответствуют требованиям.
Запись с Доп. аналитиками "заработная плата, начисленная(выплаченная)\ФСС" вообще не сформировалась.
Из-за этой проблемы не удаётся корректно сформировать реестры по перечислению зарплаты в банк.
Как измененно :
Для Украины доработана функция формирования результатов расчета заработной платы по перечислению заработной платы в банк для следующей ситуации.
Работнику рассчитан аванс за работу с 01/07/2014 по 15/07/2014:
Сформирован реестр на перечисление аванса в банк:
После этого работник принёс больничный с 10/07/2014 по 20/07/2014. Этот больничный был рассчитан в Галактике с выплатой "С зарплатой".
Затем, в конце месяца, была рассчитана зарплата за весь месяц.
Теперь в результатах расчета формируется 3 записи удержаний с кодом перечисления заработной платы:
1) перечисление больничного за счет предприятия в банк
Доп. аналитики: заработная плата, начисленная(выплаченная)\Предприятие
2) перечисление больничного за счет ФСС в банк;
Доп. аналитики: заработная плата, начисленная(выплаченная)\ФСС
3) удержание по перечислению зарплаты
Доп. аналитики: заработная плата, начисленная(выплаченная)\ФСС