Сравнение файлов
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
101.61538NEWВ результаты расчета попадает удержание межрасчетной выплаты не с тем параметром. продолжение 101.161164Заработная платаРасчет удержаний (общие вопросы)
В межрасчет рассчитаны и выплачены реестром суммы с определенным параметром. Операции - Начисления и выплаты - Расчет. Настройка "Разбивать удержания" установлена в значение "по подразделениям, аналитике и параметру входящих оплат". При расчете зарплаты в начисления попадает тот же параметр, но в удержание попадает параметр из ЛС. Если в межрасчетной выплате задан параметр, то в удержание нужно брать его из межрасчетной выплаты (как и в случае с начислением), если же он не задан, то брать его из ЛС (опять же, как и в случае с начислением). Если межрасчетные выплаты считаются в разрезе разных параметров (которые потом входят в аналитический разрез реестров и ведомостей) и они явно задаются в интерфейсе межрасчетной выплаты, то, само собой разумеется, что эти параметры должны попадать и в Результаты расчета в начисления и в удержания с этой выплаты (перечисление в банк). На данный момент в начисление параметр попадает из межрасчетной выплаты, а в удержание из ЛС, что абсолютно нелогично. Настройки Галактики Управление персоналом Расчеты с персоналом Межрасчетный период Учет межпериода при расчете зарплаты Учет выплат по реестрам учет не ведется. Проблема не только по реестрам, но и по платежным ведомостям, т.е. когда удержание=181 Если в Начислениях и выплатах рассчитать НДФЛ, то в результаты расчета потом 182/183 ВУ попадет также с параметром из ЛС, а не из Начисления-выплаты.Доработана функция формирования сумм удержания "из Начислений и выплат" в результатах расчета заработной платы для значений "учет не ведется" в настройках учета реестров и платежных ведомостей. Теперь параметр удержаний принимает значение параметра из начисления в том случае, если не определены другие настройки классификатора видов удержаний. Кроме того, в результаты расчета передается и сумма начисленная. Примечание. Ситуация проявлялась в тех случаях, когда приоритет расчета удержаний равен 0.
102.178858NEWрасчет пенсионного с отпусков при наличии двух отпусков (в отчётном и в будущем периоде)Заработная платаОтпуска будущих периодов
РБ. Отчетный период - январь. В отчетном периоде предоставили отпуск с 10.02.18 по 10.02.18, рассчитали отпуск, рассчитали удержания - все хорошо. Рассчитали зарплату, все нормально. Далее в закладке будущий период назначили еще один отпуск тому же сотруднику с 18.02.18 по 20.02.18, рассчитали. Рассчитываем удержания - не считает пенсионный, пенсионный 0.РБ, расчёт удержаний в пенсионный фонд для отпуска будущего периода выполняется корректно.
102.179586NEWРасчёт в "Удержаниях и выплатах" - проверка наличия отпусковЗаработная платаРасчет сумм в режиме "Удержания и выплаты"
Исторически сложилось разграничение типов в классификаторе отпусков по коду отпуска: 1...20 - основные отпуска (очередной и т. п.), где 2 - отпуск по уходу за ребенком 21 - административный отпуск (за свой счет) 22...39 - учебный отпуск 40 и выше - компенсация за неиспользованный отпуск Периодически возникают вопросы и замечания от клиентов о неудобстве такого разграничения. Одним не хватает диапазона кодов до 20, другим (при переходе на Галактику из других систем) просто не хочется менять привычные коды. Необходимо при расчёте сумм в режиме "Удержания и выплаты" отказаться от проверки номерного значения кода для разделения компенсации от отпуска (40 и выше) и перейти на проверку поля "тип отпуска" из классификатора в значении "компенсация".При формировании суммы "Выплачено" учитываются отпуска не по значению кода (меньше 40), а по значению поля "тип отпуска" для этого кода в классификторе отпусков. Учитываются отпуска, для которых это значение не "компенсация".
102.179606NEWНеобходим анализ кода расчёта удержаний - обращение к отпускамЗаработная платаРасчет удержаний (общие вопросы)
Исторически сложилось разграничение типов в классификаторе отпусков по коду отпуска: 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;
106.10564NEWНеправильно рассчитываются алименты для работников, уволенных в последний день месяцаЗаработная платаРасчет алиментов и исполнительных листов
Неправильно рассчитываются алименты для работников, уволенных в последний день месяца.Алименты не пересчитываются, если дата окончания алиментов равна дате окончания начислений, с которых расчитываются алименты.
180.10636NEWАрифметическое округление Социальных отчисленийЗаработная платаРасчёт налогов на ФОТ
В Казахстане внесены изменения в Постановление Правительства Республики Казахстан от 21 июня 2004 года № 683 "Об утверждении Правил исчисления и перечисления социальных отчислений". Касательно уплаты социальных отчислений в связи с внесением изменений в Постановление Правительства Республики Казахстан от 21 июня 2004 года № 683 "Об утверждении Правил исчисления и перечисления социальных отчислений".Постановлением Правительства Республики Казахстан от 29 сентября 2017 года №603 "О внесении изменений и дополнений в некоторые решения Правительства Республики Казахстан" (вступило в силу 5 октября 2017 года), в связи с неоднократными обращениями работодателей и предпринимателей были внесены изменения в Постановление Правительства Республики Казахстан от 21 июня 2004 года № 683 "Об утверждении Правил исчисления и перечисления социальных отчислений" Так, в соответствии с правилами, при исчислении социальных отчислений суммы, исчисленные в тиынах, округляются до 1 тенге в большую сторону. Это означает, что независимо сколько тиын получается при расчете, сумма СО увеличивается на 1 тенге.РК. Если в классификаторе налогов на ФОТ для социальных отчислений ("Дополнительный признак" = "О") установлено округление итоговой суммы до целых НДЕ, то это округление производится всегда в бОльшую сторону.