G_ZARPL
Краткое описание :
Постденоминационные проблемы - Дать возможность в классификаторе вводить и видеть суммы с копейками.Описание :
Суммы вычетов на работника и ребенкаЧто измененно :
Дать возможность в классификаторе "Суммы вычетов на работника и ребенка" вводить и видеть суммы с копейками.
Как измененно :
Переделан интерфейс классификатора, редактирование теперь происходит в том же окне. Во все поля теперь можно вводить дробные суммы.
При первом запуске Галактики ERP, после установки обновления, будет проведена конвертация целочисленного поля для ввода дробных сумм.
G_ZARPL
Краткое описание :
Максимальное количество месяцев для сторнирования налогов на ФОТОписание :
Расчёт налогов на ФОТЧто измененно :
Максимальное количество месяцев для сторнирования, которые учитываются при расчете = 23. Но в настройке: "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Взносы и налоги на ФОТ \ Налоги \ Единый социальный налог/Страховые взносы \ Количество месяцев сторнирования ЕСН/Страховых взносов в расчетном" можно установить любое значение, что может вводить пользователей в заблуждение. Необходимо либо ограничить возможность ввода большего числа месяцев в настройке либо выводить предупреждение при расчете, если в данной настройке указано более 23-х месяцев.
Как измененно :
Для РФ. При выборе значения для настройки "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Взносы и налоги на ФОТ \ Налоги \ Единый социальный налог/Страховые взносы \ Количество месяцев сторнирования ЕСН/Страховых взносов в расчетном" в случае превышения допустимого числа месяцев для сторнирования выдается предупреждение "Не предусмотрено сторнирование годовых налогов на ФОТ более, чем за N месяцев", где N - максимально допустимое значение с учетом даты отчетного периода (сторнирование не может выходить за границы прошлого года). Это значение и будет установлено в данном случае для настройки.
В параметрах расчета зарплаты (на закладке "Налоги на ФОТ") также при выборе количества месяцев для сторнирования выдается аналогичное предупреждение.
G_ZARPL
Краткое описание :
Не учитывается остаток с прошлого месяца по алг 97 признак 2Описание :
Расчет подоходного налогаЧто измененно :
1.В текущем периоде есть доплата по алг 97 признак 2 с остатком предыдущего месяца. Добавлена доплата с таким же ВО с началом расчета и датой назначения текущего месяца.
При расчете льготируется только новая запись и не учитывается остаток с прошлого месяца.
2.Отчетный период февраль.
У работника по основному месту работы есть два вычета
код скидки 97 с алгоритмом 97 пр.0 сумма вычета 125.02 общий размер вычета 125.02 назначен с 01/02/2017
код скидки 98 с алгоритмом 97 пр.2 вычет за месяц 52.77 общий размер вычета 52.77 остаток 52.77 назначен с 01/02/2017
Кроме того есть вычеты не участвующие в расчетах с алгоритмом 97 пр.2.
код скидки 98 начало расчета с 01/07/16 по 31/07/16 за месяц 52.75 всего 52.75
код скидки 98 начало расчета с 01/08/16 по 31/08/16 за месяц 52.76 всего 105.51
код скидки 98 начало расчета с 01/09/16 по 30/09/16 за месяц 52.77 всего 158.28
код скидки 98 начало расчета с 01/02/17 по за месяц 52.76 всего 211.04
код скидки 98 начало расчета с 01/11/16 по 30/11/16 за месяц 52.76 всего 263.80
код скидки 98 начало расчета с 01/12/16 по 31/12/16 за месяц 52.76 всего 316.56
код скидки 98 начало расчета с 31/01/17 по за месяц 52.76 всего 369.32
Суммы активных вычетов полностью использованы на льготирование доходов по совместительству.
Тем не менее, по основному месту работы тоже предоставляется вычет на сумму вычета с алгоритмом 97 пр.0.
Причем в результаты расчета эта сумма записывается с кодом 98.
Как измененно :
1.Доработана функция предоставления вычетов при расчете заработной платы.
Теперь записи по имущественным и социальным вычетам учитываются в порядке следования даты назначения.
Т.е. в первую очередь предоставляются вычеты по той записи, у которой дата назначения меньше.
Если дата назначения не заполнена учитывается дата начала расчета.
2. Доработана функция предоставления вычетов с алгоритмом 97 пр.0 при расчете заработной платы с учетом смежных лицевых.
Теперь сумма ограничивается
Примечание. Ошибка проявлялась при условии, что кроме данного вычета, у работника имеется несколько записей о вычетах с алгоритмом 97 пр.2,
в том числе не участвующие в расчетах.
G_ZARPL
Краткое описание :
При расчете ЗП пенсионеру сумма для удержания налога в результатах расчета разбивается на 2-ве части.Описание :
Расчет удержаний (6-НДФЛ)Что измененно :
При расчете ЗП пенсионеру сумма для удержания налога в результатах расчета разбивается на 2-ве части.
Причем сумма удержание налога по первой(большей) части верная, а по второй равна 0. Данная ситуация никак не влияет на формирования 2-ндфл.
Как измененно :
Доработан учет сумм из реестров при формировании результатов расчета заработной платы по НДФЛ для материальной помощи.
Теперь в тех случаях, когда мат.помощь облагается полностью, в качестве дохода принимается полная сумма, а не пересчитывается обратным расчетом, как было ранее.
Таким образом, сумма для удержания налога в результатах расчета не разбивается на 2-ве части.
G_ZARPL
Краткое описание :
ВУ с системным кодом 191 заменяется на удержание из настройки "Вид удержания для реально перечисленной заработной платы"Описание :
Расчет удержаний (общие вопросы)Что измененно :
ВУ с ситемным кодом 191 заменяется на удержание из настройки "Вид удержания для реально перечисленной заработной платы". Подробное описание и отчет о системе во вложении.
Как измененно :
Исправлен учет алиментов с кодом 191 при расчете зарплаты.
ВУ с ситемным кодом 191 не заменяется на удержание из настройки "Вид удержания для реально перечисленной заработной платы".
G_ZARPL
Краткое описание :
Расчет НДФЛ - не считать возвратом отрицательные суммы, полученные в результате контроля удержания по налогуОписание :
Расчет удержаний (6-НДФЛ)Что измененно :
С точки зрения законодательства правильнее рассчитывать налог с включенной настройкой "Контролировать удержание по налогу". Однако сейчас в результате работы этой настройки формируются записи удержания НДФЛ с отрицательной суммой налога и нулевой суммой дохода - по умолчанию такие записи считаются возвратом налога и впоследствии попадают в строку 090 6-НДФЛ, хотя на самом деле возвратом они не являются. Предлагается автоматически проставлять признак "не является возвратом" в таких записях - для правильного формирования 6-НДФЛ.
Пример.
Работнику 15.10.16 выплатили аванс 10000, налог не удерживали.
При окончательном расчёте выясняется, что больше дохода у него нет (например, больничный с 16.10). Т.е. в окончательную зарплату 02.11.16 он ничего не получает.
Должны ли мы в день зарплаты рассчитать и перечислить за него налог 1300?
Ранее мы предполагали, что да - должны рассчитать и перечислить и делали соответствующие доработки (ПиР 180.9682). Однако клиент не согласен с таким подходом, аргументация такая:
**********
Проблема в том, что работник уже получил и аванс и отпускные. Выплаты зарплаты, как таковой нет (Сумма к получению = 0).
Чтобы перечислить НДФЛ, нужно, чтобы работник сначала вернул аванс,и получил его снова, уже как зарплату за минусом НДФЛ. Без этого, получится, что предприятие заплатит НДФЛ "из своих", а работник останется должен предприятию сумму НДФЛ.
Однако, как мы помним, предприятие в данном случае является налоговым агентом, а работник должен быть должен не предприятию, а государству. И если налоговый агент не смог удержать НДФЛ, работник рассчитывается с государством сам.
Кроме того, налоговый агент не может платить НДФЛ за счет своих средств, как получится, если делать так, как вы предложили. Это прямо запрещено в НК (гл.23, ст.226, п.9):
"9. Уплата налога за счет средств налоговых агентов не допускается. При заключении договоров и иных сделок запрещается включение в них налоговых оговорок, в соответствии с которыми выплачивающие доход налоговые агенты принимают на себя обязательства нести расходы, связанные с уплатой налога за физических лиц."
**********
Для того, чтобы не удерживать НДФЛ в данной ситуации, и предназначена настройка "Контролировать удержание по налогу".
Как измененно :
Доработана функция расчета заработной платы для значения "да" в настройке "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ Сторнирование и возврат \ Контролировать удержание по налогу".
1. В рамках первой итерации исправлена ошибка. Функция не всегда возвращала суммы НДФЛ.
Ошибка проявлялась при следующих сумма.
Начислено 24'522.68
7 Повременная оплата труда в окладах 4'523.81
106 Ежегодный оплачиваемый отпуск 14'665.84
107 Ежегодный оплачиваемый отпуск 5'333.03
Перечислено 21'922.87
180 Плановый аванс 4'524.00
181 Межрасчетные выплаты через кассу 17'398.87
2. В записях возврата налога, которые формируются за счет настройки, автоматически проставляется признак "не является возвратом" - для правильного формирования 6-НДФЛ.
3. Значение "возврат налога" переносится в базовые таблицы удержаний, в связи с чем дорабатывался просмотр и выбор значений в соответствующем поле режима редактирования "Удержаний" и "Архива удержаний".
G_ZARPL
Краткое описание :
В результаты расчета попадает удержание межрасчетного отпуска не с тем параметром, что в отпуске указан.Описание :
Расчет удержаний (общие вопросы)Что измененно :
В межрасчет рассчитан и выплачен реестром отпуск с определенным параметром.
При расчете зарплаты в начисления попадает тот же параметр, но в удержание попадает параметр из ЛС.
Настройка "Разбивать удержания" установлена в значение "по подразделениям, аналитике и параметру входящих оплат".
Если в отпуске задан параметр, то в удержание нужно брать его из отпуска (как и в случае с начислением), если же он не задан, то брать его из ЛС (опять же, как и в случае с начислением).
Собственно проблема не в ТХО, а в параметре.
ТХО, разумеется, могут быть разными (хотя это и не обязательно в общем случае).
Если отпуска считаются в разрезе разных параметров (которые потом входят в аналитический разрез межрасчетных реестров и ведомостей) и они явно задаются в отпуске, то, само собой разумеется, что эти параметры должны попадать и в начисления этого отпуска и в удержания этого отпуска.
На данный момент в начисление параметр попадает из отпуска, а в удержание из ЛС, что абсолютно нелогично.
Как измененно :
Доработана функция формирования записей о перечислении отпуска для значения "учет не ведется" настройки "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Межрасчетный период \ Учет межпериода при расчете зарплаты \ Учет выплат по реестрам".
Теперь в результаты расчета удержаний переносится параметр из функции расчета отпуска, если он там есть.
G_ZARPL
Краткое описание :
Пропадает сбор алименты почтой первой половины месяца в расчета за полный месяцОписание :
Расчет алиментов и исполнительных листовЧто измененно :
При условии, что в межпериод была перечислена вся сумма алиментов, заданная готовой суммой, то при окончательном расчете сумма сбора за перечисление алиментов в межпериод не попадает в удержания.
Как измененно :
Сумма сбора за перечисление алиментов в межпериод попадает в удержания при окончательном расчете, если вся сумма алиментов была перечислены в межпериод.
В поле "Сумма сбора" сохраняется сбор, рассчитанный при окончательном расчете, без учета сбора, рассчитанного в межпериод.