G_ZARPL
Краткое описание :
Добавить поле "№ и/л" в системном виде удержания 188Описание :
Постоянные удержанияЧто измененно :
В последнее время сложилась практика перечисления исков и ущербов в пользу юридических и физических лиц на расчетный счет отдела судебных приставов. При этом требуется прилагать расшифровку с указанием суммы и номера исполнительного листа, по которому удерживался иск.
В системном виде удержания 188 в интерфейсе постоянных удержаний отсутствует поле "№ и/л", хотя в удержаниях 185, 186, 187, 190 оно присутствует. Требуется его добавление.
В интерфейсе расчетных удержаний (окно "Суммы удержанные", вызываемое из результатов расчета) поле "Номер исполнительного листа" отображается для всех видов удержаний, но называется "АВ". Требуется переименовать поле в "Номер исполнительного листа" (при настройке на Украину - "ИНН").
Также требуется перенос значения поля "№ и/л" после расчета зарплаты для ВУ 188 и 190 из постоянных удержаний в поле "номер исполнительного листа". А после перехода к следующему месяцу - в одноименное поле архива удержаний.
Как измененно :
В интерфейсе постоянных удержаний для 188 вида удержаний (исполнительные листы через банк) добавлено поле "№ и/л" (при настройке на Украину поле имеет название "ИНН" по аналогии с 190м ВУ).
В интерфейсе расчетных удержаний поле "АВ" переименовано в "Номер исполнительного листа" (при настройке на Украину - "ИНН").
Для видов удержаний 188 и 190 при расчете зарплаты значение поля "№ и/л" переносится в расчетные удержания, а после перехода к следующему месяцу - в архивные удержания.
G_ZARPL
Краткое описание :
Некорректно учитывается ПП межпериодаОписание :
Платежные порученияЧто измененно :
При формировании платежных поручений по налогам по результатам расчета зарплаты некорректно
учитывается сформированное в межпериод платежное поручение по налогу на ФОТ.
Описание проблемы во вложенном файле.
Проблема проявляется только на базе клиента. На копии базы, имеющейся у нас не проявляется.
Как измененно :
Исправлено - суммы из ранее сформированных платежных поручений
вычитаются только один раз.
G_ZARPL
Краткое описание :
Неправильно распределился налог по подразделениям.Описание :
Расчет подоходного налогаЧто измененно :
Неправильно распределился налог по подразделениям.
Имеем база в марте.
Начисления Подразделение 1
635 за 2 месяц
304 за 2
3490.91 за 3
Начисления Подразделение 2
137 за 2
420 за 2
3019.73 за 3
Удержание подоходного подразделения 1
325
251
Удержание подоходного подразделения 2
153
312
Все удержания 3 месяцем.
Вычетов , скидок нет.
Налог межпериода выплачено 312 на прочие удержания (в подразделение 1)
Почему 312 пошло не подразделение 1?
Установлены настройки:
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ НДФЛ межпериода \ НДФЛ межпериода при окончательном расчете" - "учитывать все расчеты межпериода"
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Режимы расчетов \ Разбивать удержания по подразделениям" - "входящих оплат"
Налог межпериода выплачено 312 на прочие удержания (в подразделение 1)
Аванса нет, но в операции - аванс - расчет стоит 325 р.
Проблемы получается 2 - почему 312 пошло не подразделение 1? И почему учлеся налог с аванса которого не было?
Как измененно :
Доработано формирование результатов расчета заработной платы по учету НДФЛ из интерфейсов "Начисления и выплаты" и Удержания и выплаты" для значений "учитывать все расчеты межпериода" и "учитывать отпуска, больничные, начисления и удержания межпериода" настройки
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ НДФЛ межпериода \ НДФЛ межпериода при окончательном расчете".
Теперь, при таких настройках, система заполняет подразделение отнесения затрат из соответствующего поля интерфейсов межпериода.
G_ZARPL
Краткое описание :
В продолжении 180.6755 - еще один случайОписание :
Расчет подоходного налогаЧто измененно :
В продолжении 180.6755 - еще один случай неправильной разбивки на отнесения затрат.
ЗП в мае
Человек в апреле работал в одном подразделении(1),соотв. другой ОКАТО.
с 14 мая переводится в другое(2).
с 28.05 возвращается обратно в 1.
16.05 ему дали премию за апрель.
Поскольку сумма начислена выплачена в 2-ом, то налог в реестрах ушел также по 2 подразделению.
Но при расчете зарплаты налог на эту сумму почему то оказывается в 1 подразделении.
Помогло только изменение prvidopl.datan , prvidopl.datok на 15.05.
Но и доход при этом попал на май, а надо за апрель.
Неправильное удержание по полям uder.cpodroz относится именно к начислению премии.
В той же ведомости на премию есть еще 28 аналогичных переводов, неправильно налог сел только у тех,
кто возвращается в подразделение 1 в мае - всего таких 4.
Установлены настройки:
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ НДФЛ межпериода \ НДФЛ межпериода при окончательном расчете" - "учитывать все расчеты межпериода"
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Режимы расчетов \ Разбивать удержания по подразделениям" - "входящих оплат"
Как измененно :
Доработано формирование результатов расчета заработной платы по учету НДФЛ из интерфейсов "Начисления и выплаты" и Удержания и выплаты" для значений "учитывать все расчеты межпериода" и "учитывать отпуска, больничные, начисления и удержания межпериода" настройки
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ НДФЛ межпериода \ НДФЛ межпериода при окончательном расчете".
Теперь, при таких настройках, система заполняет подразделение отнесения затрат из соответствующего поля интерфейсов межпериода.
G_ZARPL
Краткое описание :
Исключить неактуальную настройку, способную привести к неверным расчётамОписание :
Общие вопросы по компонентам Z_*Что измененно :
Настройка UP.ZAR.X_DATE2
"Настройки Галактики \ Управление персоналом \ Общие
настройки \ Больничные, отпуска, расчеты по среднему \
Отпуска \ Государственный праздник, приходящийся на
воскресенье, продлевает отпуск"
Для правильного расчёта для всех стран должна быть
установлена в значение "да". "true" <=> day(Xarpred.date2) = 2
Чтобы минимизировать затраты на "разбирательства" в
неверных результатах, следующих из значения "нет",
требуется вначале исключить её обработку из кода, затем
исключить саму настройку.
По исходникам - примерный перечень:
Func_zar.pas (пишется из настройки в буфер Xarpred.date2)
Lowproc.pas /UP.ZAR.X_DATE2
WrkTable.pas /UP.ZAR.X_DATE2
Algbifun.pas /day(Xarpred.date2)
Algbiotp.pas /day(Xarpred.date2)
Xarpred.vip
Createtune_z_sredn.vip
Как измененно :
Настройка "Настройки Галактики \ Управление персоналом \ Общие
настройки \ Больничные, отпуска, расчеты по среднему \ Отпуска \ Государственный праздник, приходящийся на воскресенье, продлевает отпуск" (UP.ZAR.X_DATE2).
Для правильного расчёта для всех стран должна быть установлена в значение "да".
Чтобы минимизировать затраты на "разбирательства" в неверных результатах, следующих из значения "нет", требуется исключить её обработку из кода, и саму настройку.
G_ZARPL
Краткое описание :
Детское пособие за вторым ребенком отображается как за первым.Описание :
Расчет начислений (общие вопросы)Что измененно :
Детское пособие за вторым ребенком отображается как за первым.
В расчетном листке некорректно отображается вид оплаты за вторым ребенком если у сотрудника есть две записи по детским пособиям.
Сотруднику введено пособие с признаком расчета за вторым ребенком.
Установлены общесистемные настройки с видами оплат для первого и второго ребенка.
Получаем протокол расчета из которого видно, что идет оплата отпуска по уходу за вторым и последующими детьми.
Рассчитываю ЗП сотруднику - в расчетном листке все правильно - код 196.
Т.к. сотруднику положено не только производить оплату в размере 40%, но и положена компенсация в размере 50 + РК 30% = 65 рублей
То теперь добавляю вторую оплату 65 рублей, для этого заношу еще одну строку.
Произвожу расчет - получаю протокол.
Далее рассчитываю ЗП и уже в расчетном листке отображается 195 код, а должен быть 196.
Как измененно :
Исправлено формирование результатов расчета заработной платы по детским пособиям.
Ошибка проявлялась в том, что расчет детского пособия из окна "Смежные данные" лицевого счета иногда обращал в ноль настройки видов оплат для детских пособий.
Все зависела от алгоритма расчета данного детского пособия.
G_ZARPL
Краткое описание :
Переход с 1го дня месяца. Не анализировать устаревший графикОписание :
Расчет планового аванса и удержанийЧто измененно :
На предприятии ведутся индивидуальные графики по каждому сотруднику. Часть таких сотрудников переводят с 1го дня месяца, например, на 5ти дневку. Индивидуальные графики по этой причине на текущий месяц заполнять нет смысла.
Пусть их заполнили выходными. При расчете
аванса в режиме "процентом от зарплаты за период" таким людям аванс не рассчитывается, в протоколе видим следующее
Для табельного номера 833415 Вид оплаты = 115 Внимание !
Проверьте дату начала и окончания ! или Количество дней болезни - 0 !
Для табельного номера 833415 Вид оплаты = 115 Внимание !
Проверьте дату начала и окончания ! или Количество дней болезни - 0 !
[i] Плановый аванс не назначался (таб. № 833415, )
Больничных и 115 вида оплаты у такого сотрудника нет.
При назначении аванса, например, "процентом от
зарплаты с учетом неявок в коэфф.отработанных дней" сумма рассчитывается.
У системы есть вся информация для проведения расчета аванса по таким людям в режиме "процентом от зарплаты за период".
Как измененно :
Доработан расчет планового аванса за период для следующего случая:
На предприятии ведутся индивидуальные графики по каждому сотруднику. Часть таких сотрудников переводят с 1-го дня месяца, на другой график. Индивидуальные графики по этой причине на текущий месяц заполнять нет смысла.
Их заполнили выходными. При расчете им аванс рассчитывается по общим правилам.
G_ZARPL
Краткое описание :
Расчет НДФЛ в межпериоде - ошибочно учитывается сальдо по матпомощиОписание :
Расчет удержаний с отпусков межпериодаЧто измененно :
Выплатили матпомощь в межпериод 4000 (вся прольготировалась). После расчёта зп в сальдо сформировалась запись об этих 4000 с признаком "после".
Теперь вводим отпуск и рассчитываем там удержания - НДФЛ рассчитывается с (суммы отпуска+4000).
Т.е. в отпуске заново рассчитывается НДФЛ с межпериодной выплаты,
причём уже без льготы (т.к. в сальдо есть запись об использовании льготы).
То же самое при расчёте удержаний в больничном, или в любой другой выплате в межпериод.
Получается, что после расчёта зарплаты уже невозможно рассчитать НДФЛ в межпериоде.
Это доставляет существенные неудобства клиенту. А если, например, отпуск
рассчитывается по текущему м-цу, то необходимо именно рассчитать зарплату перед расчётом отпуска.
В этой ситуации единственный выход - вручную удалять (обнулять)
сальдо.
Как измененно :
Исправлен расчет НДФЛ в межпериод. Теперь примененный вычет по материальной помощи сохраняется в базе данных. При расчете НДФЛ с других сумм межпериода облагаемая сумма материальной помощи не пересчитывается, а учитывается такой, какой она была при расчете НДФЛ.
В результате при расчете НДФЛ с отпусков, больничных и прочих начислений межпериода НДФЛ с материальной помощи межпериода программа не добирает.
G_ZARPL
Краткое описание :
Включение в расчет зарплаты сумм больн. за счет ФСС в рамках Пилотного проектаОписание :
Расчет начислений (общие вопросы)Что измененно :
Предприятие попадает под действие пилотного проекта.
Так как предприятие не выплачивает сотруднику больничный за счет средств ФСС, то и показывать эти суммы в расчетном листе не нужно.
Для этого предлагается добавить новую функцию, которая возвращала бы код подразделения с учетом уровня иерархии подразделений.
Как измененно :
Добавлена функция:
G_D_Kod(L: word): string;
Возвращает код подразделения из записи предварительного просмотра. L - уровень иерархии подразделений.
G_ZARPL
Краткое описание :
Некорректная работа настройки Учет выплат по реестрам на Оракл 11.2Описание :
Расчет начислений (общие вопросы)Что измененно :
Некорректное поведение системы при расчете зарплаты. Суммы, выплаченные по реестрам, не попадают в результаты расчета - вместо них попадает ноль.
Как измененно :
Ошибка исправлена, теперь суммы верные.
G_ZARPL
Краткое описание :
Потеря преемственности:Не льготируются выплаты будущих периодовОписание :
Расчет подоходного налогаЧто измененно :
Не льготируются выплаты будущих периодов.
Имеется льгота по подоходному с алг 97, признак 2
При расчете отпуска будущего периода на происходит льготирования по этой доплате.
Как измененно :
Исправлена ошибка предоставления скидок по подоходному налогу с алг 97, признак 2 для Беларуси. Льготируются выплаты будущих периодов.
Старая функциональность тоже должна работать, в том числе при доначислении сумм за прошлые периоды.
Потеря преемственности:Не льготируются выплаты будущих периодов.
G_ZARPL
Краткое описание :
runtime при формировании бухгалтерских справок по налогам на ФОТОписание :
Бухгалтерские справкиЧто измененно :
У клиента, на текущих обновлениях, при формировании бухгалтерских справок по налогам на ФОТ выдается ошибка:
runtime error 216 (попытка обращения к некорректному дескриптору).
Работа по данному вопросу уже ведется, запрашиваемые уточнения во вложении.
Как измененно :
Исправлено. Ошибка не проявляется.
G_ZARPL
Краткое описание :
Зависание при расчете удержаний в начислениях и выплатахОписание :
Расчет удержаний в режиме "Начисления и выплаты"Что измененно :
Зависание при расчете удержаний в начислениях и выплатах
В начислениях и выплатах рассчитать удержания
Как измененно :
Исправлено зависание при расчете удержаний в начислениях и выплатах.
В рамках данного решения доработан расчет НДФЛ с учетом скидок с алгоритмом 97.признак 2 для РБ.