G_ZARPL
Краткое описание :
расчет пенсионного с отпусков при наличии двух отпусков (в отчётном и в будущем периоде)Описание :
Отпуска будущих периодовЧто измененно :
РБ. Отчетный период - январь.
В отчетном периоде предоставили отпуск с 10.02.18 по 10.02.18, рассчитали отпуск, рассчитали удержания - все хорошо.
Рассчитали зарплату, все нормально.
Далее в закладке будущий период назначили еще один отпуск тому же сотруднику с 18.02.18 по 20.02.18, рассчитали.
Рассчитываем удержания - не считает пенсионный, пенсионный 0.
Как измененно :
РБ, расчёт удержаний в пенсионный фонд для отпуска будущего периода выполняется корректно.
G_ZARPL
Краткое описание :
Расчёт в "Удержаниях и выплатах" - проверка наличия отпусковОписание :
Расчет сумм в режиме "Удержания и выплаты"Что измененно :
Исторически сложилось разграничение типов в классификаторе отпусков по коду отпуска:
1...20 - основные отпуска (очередной и т. п.), где 2 - отпуск по уходу за ребенком
21 - административный отпуск (за свой счет)
22...39 - учебный отпуск
40 и выше - компенсация за неиспользованный отпуск
Периодически возникают вопросы и замечания от клиентов о неудобстве такого разграничения. Одним не хватает диапазона кодов до 20, другим (при переходе на Галактику из других систем) просто не хочется менять привычные коды.
Необходимо при расчёте сумм в режиме "Удержания и выплаты" отказаться от проверки номерного значения кода для разделения компенсации от отпуска (40 и выше) и перейти на проверку поля "тип отпуска" из классификатора в значении "компенсация".
Как измененно :
При формировании суммы "Выплачено" учитываются отпуска не по значению кода (меньше 40), а по значению поля "тип отпуска" для этого кода в классификторе отпусков. Учитываются отпуска, для которых это значение не "компенсация".
G_ZARPL
Краткое описание :
Необходим анализ кода расчёта удержаний - обращение к отпускамОписание :
Расчет удержаний (общие вопросы)Что измененно :
Исторически сложилось разграничение типов в классификаторе отпусков по коду отпуска:
1...20 - основные отпуска (очередной и т. п.), где 2 - отпуск по уходу за ребенком
21 - административный отпуск (за свой счет)
22...39 - учебный отпуск
40 и выше - компенсация за неиспользованный отпуск
Периодически возникают вопросы и замечания от клиентов о неудобстве такого разграничения. Одним не хватает диапазона кодов до 20, другим (при переходе на Галактику из других систем) просто не хочется менять привычные коды.
Ведутся работы по отказу от проверки номерного значения кода для разделения компенсации от отпуска (40 и выше) и переходу на проверку поля "тип отпуска" из классификатора в значении "компенсация".
В ходе анализа в исходном коде udnalog.pas (Procedure GetUder -> procedure ProcessVacations) нашёлся участок обработки, в котором проверяется условие (OtpuskR^.Kotpus < 40). Но код, похоже, устаревший. Необходимо принять решение - производить ли в этой функции замену на "подгрузку" и проверку классификатора отпусков.
if OtpuskR^.Kotpus < 40 then
begin
CurMonthR^.Summa:=CurMonthR^.Summa+OtpuskR^.SbFzp+OtpuskR^.SbFmp;
if (OtpuskR^.SbFzp<> 0 ) or (OtpuskR^.SbFmp <> 0) then
begin
KlOtpuskR^.Kotpus := OtpuskR^.Kotpus;
{$ifdef _KLCACHE_}
if not GetKlOtpuskCache.Read(OtpuskR^.Kotpus, KlOtpuskR) then
{$else}
if klOtpuskF^.GetEqual(tiklOtpusk01) <> tsOk then
{$endif}
KlOtpuskR^.IsRabDn := 0;
CurMonthR^.Kotpus := KlOtpuskR^.IsRabDn;
end;
if OtpuskR^.DatOk > CurMonthR^.DatOk then
CurMonthR^.DatOk := OtpuskR^.DatOk;
if ((OtpuskR^.DataN < CurMonthR^.DataN) or
(d_day(CurMonthR^.DataN) = 0)) and
(d_day(OtpuskR^.DataN) <> 0) then
CurMonthR^.DataN := OtpuskR^.DataN;
end;
Как измененно :
Удален ненужный код в исходном коде udnalog.pas (Procedure GetUder -> procedure ProcessVacations)
if OtpuskR^.Kotpus < 40 then
begin
CurMonthR^.Summa:=CurMonthR^.Summa+OtpuskR^.SbFzp+OtpuskR^.SbFmp;
if (OtpuskR^.SbFzp<> 0 ) or (OtpuskR^.SbFmp <> 0) then
begin
KlOtpuskR^.Kotpus := OtpuskR^.Kotpus;
{$ifdef _KLCACHE_}
if not GetKlOtpuskCache.Read(OtpuskR^.Kotpus, KlOtpuskR) then
{$else}
if klOtpuskF^.GetEqual(tiklOtpusk01) <> tsOk then
{$endif}
KlOtpuskR^.IsRabDn := 0;
CurMonthR^.Kotpus := KlOtpuskR^.IsRabDn;
end;
if OtpuskR^.DatOk > CurMonthR^.DatOk then
CurMonthR^.DatOk := OtpuskR^.DatOk;
if ((OtpuskR^.DataN < CurMonthR^.DataN) or
(d_day(CurMonthR^.DataN) = 0)) and
(d_day(OtpuskR^.DataN) <> 0) then
CurMonthR^.DataN := OtpuskR^.DataN;
end;
G_ZARPL
Краткое описание :
Неправильно рассчитываются алименты для работников, уволенных в последний день месяцаОписание :
Расчет алиментов и исполнительных листовЧто измененно :
Неправильно рассчитываются алименты для работников, уволенных в последний день месяца.
Как измененно :
Алименты не пересчитываются, если дата окончания алиментов равна дате окончания начислений, с которых расчитываются алименты.
G_ZARPL
Краткое описание :
Арифметическое округление Социальных отчисленийОписание :
Расчёт налогов на ФОТЧто измененно :
В Казахстане внесены изменения в Постановление Правительства Республики Казахстан от 21 июня 2004 года № 683 "Об утверждении Правил исчисления и перечисления социальных отчислений". Касательно уплаты социальных отчислений в связи с внесением изменений в Постановление Правительства Республики Казахстан от 21 июня 2004 года № 683 "Об утверждении Правил исчисления и перечисления социальных отчислений".Постановлением Правительства Республики Казахстан от 29 сентября 2017 года №603 "О внесении изменений и дополнений в некоторые решения Правительства Республики Казахстан" (вступило в силу 5 октября 2017 года), в связи с неоднократными обращениями работодателей и предпринимателей были внесены изменения в Постановление Правительства Республики Казахстан от 21 июня 2004 года № 683 "Об утверждении Правил исчисления и перечисления социальных отчислений"
Так, в соответствии с правилами, при исчислении социальных отчислений суммы, исчисленные в тиынах, округляются до 1 тенге в большую сторону. Это означает, что независимо сколько тиын получается при расчете, сумма СО увеличивается на 1 тенге.
Как измененно :
РК. Если в классификаторе налогов на ФОТ для социальных отчислений ("Дополнительный признак" = "О") установлено округление итоговой суммы до целых НДЕ, то это округление производится всегда в бОльшую сторону.
G_ZARPL
Краткое описание :
В результаты расчета попадает удержание межрасчетной выплаты не с тем параметром. продолжение 101.161164Описание :
Расчет удержаний (общие вопросы)Что измененно :
В межрасчет рассчитаны и выплачены реестром суммы с определенным параметром.
Операции - Начисления и выплаты - Расчет.
Настройка "Разбивать удержания" установлена в значение "по подразделениям, аналитике и параметру входящих оплат".
При расчете зарплаты в начисления попадает тот же параметр, но в удержание попадает параметр из ЛС.
Если в межрасчетной выплате задан параметр, то в удержание нужно брать его из межрасчетной выплаты (как и в случае с начислением), если же он не задан, то брать его из ЛС (опять же, как и в случае с начислением).
Если межрасчетные выплаты считаются в разрезе разных параметров (которые потом входят в аналитический разрез реестров и ведомостей) и они явно задаются в интерфейсе межрасчетной выплаты, то, само собой разумеется, что эти параметры должны попадать и в Результаты расчета в начисления и в удержания с этой выплаты (перечисление в банк).
На данный момент в начисление параметр попадает из межрасчетной выплаты, а в удержание из ЛС, что абсолютно нелогично.
Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Межрасчетный период \ Учет межпериода при расчете зарплаты \ Учет выплат по реестрам
учет не ведется.
Проблема не только по реестрам, но и по платежным ведомостям, т.е. когда удержание=181
Если в Начислениях и выплатах рассчитать НДФЛ, то в результаты расчета потом 182/183 ВУ попадет также с параметром из ЛС, а не из Начисления-выплаты.
Как измененно :
Доработана функция формирования сумм удержания "из Начислений и выплат" в результатах расчета заработной платы для значений "учет не ведется" в настройках учета реестров и платежных ведомостей.
Теперь параметр удержаний принимает значение параметра из начисления в том случае, если не определены другие настройки классификатора видов удержаний.
Кроме того, в результаты расчета передается и сумма начисленная.
Примечание. Ситуация проявлялась в тех случаях, когда приоритет расчета удержаний равен 0.