G_ZARPL
Краткое описание :
Использование таблицы PRVIDOPL для хранения данных доработок региональных офисовОписание :
Расчет начислений (общие вопросы)Что измененно :
Наши законодатели выдумали очередные навороты, для реализации которых нужно хранить дополнительные
табличные данные по каждому лицевому счету (имеются ввиду последние изменения в законе о
расчете индексации, принятые постановлением КМУ от 13.06.12 № 526).
Таблица нужна следующего вида:
--
ссылка на лицевой счет (либо табельный номер)
год
месяц
сумма
--
Доработка для всех клиентов, поэтому делать докомпиляцию словаря очень не хочется - хлопотно сопровождать.
Предполагается использовать для хранения этих данных таблицу PRVIDOPL.
Во избежание проблем в будущем прошу выделить какой-то диапазон значений PRVIDOPL.CHOICE для
доработок по поддержке законодательства, выполняемых региональными офисами.
Как измененно :
Зарезервирован диапазон значений PRVIDOPL.CHOICE от 51 до 59 включительно. Записи PRVIDOPL с указанным значением поля CHOICE не обрабатываются как выплаты при расчете зарплаты.
G_ZARPL
Краткое описание :
Очень большая оплата по окладуОписание :
Расчет начислений (общие вопросы)Что измененно :
У клиента есть 3 системы оплат
30 - для оплаты оклада по дням , с 7 системным во алгоритмом 3/ признак 0.
31 - для оплаты оклада по часам , 40 часовая с оплатой 6 системным кодом.
Человек до 1.05 был на 31 системе оплат с окладом 15000.
со 2 его переводят на оплату по среднему, оклад ставят 0, система оплат 30.
В результатах расчета имеем
система оплат 31, оклад 15000,
вид оплат 7. -
сумма 2283040.00
то есть здесь вид оплат соот. переводу, а система оплат и оклад нет.
При этом в предварительном просмотре все нормально.
Ставим в перевод 10 рублей - в результатах расчета все нормально
- система оплаты оклад, оклад и сумма 10 р.
Меняю в переводе систему оплат на 31 и оклад в 0 - все нормально.
В предварительном просмотре просмотре 6.
Как измененно :
Доработаны алгоритмы 3, 4, 14 при расчете заработной платы.
Теперь, если в предварительном просмотре имеется запись за расчетный месяц по данному алгоритму, у которой оклад равен 0, программа рассчитывает сумму по окладу из лицевого счета или перехода на дату начала записи.
Если в переходе на эту дату указан оклад равный 0, то по умолчанию оклад из ЛС не подставляется.
G_ZARPL
Краткое описание :
Больничные, отпуска - очень медленно идёт расчёт удержанийОписание :
Расчет удержаний с больничных листовЧто измененно :
На базе клиента время расчёта удержаний по одному больничному составляет от 1 до 2-х минут. Просят ускорить до приемлемого времени. Для сравнения полный расчёт зарплаты по одному работнику идёт около 3-х секунд.
Как измененно :
Ускорен расчет удержаний для больничных и отпусков.
Добавлена визуализация процесса расчета удержаний (для удобства работы).
G_ZARPL
Краткое описание :
Реализовать в классификаторе налогов на ФОТ дату окончания
действия налога.Описание :
Классификатор налогов на ФОТЧто измененно :
Реализовать в классификаторе налогов на ФОТ дату окончания
действия налога.
Просьба доработать классификатор налогов на ФОТ. Для каждого налога нужна дата
окончания. Многие налоги в нашей стране отменяются.
Например, с 2012 года отменен налог ТФОМС. Но из базы мы его удалить не можем.
Объем БД увеличивается, так как сколько заведено налогов в справочнике, столько
строк резервируется по каждому работнику за каждый год в двух таблицах sumulsoc
и sumupsoc.
Также налог "ПФ Федеральный бюджет" отменен с 2010 года, но в базе данных
присутствует и создает пустые строки.
Как измененно :
Реализовано с учётом общесистемной настройки "Настройки
Галактики \ Общие настройки системы \ Настройки для страны = Россия".
В классификатор налогов на ФОТ для перечислений, ранее составляющих ЕСН
(значение поля "Дополнительный признак" = "+") - добавлено поле "Окончание",
формат - дата, обрабатывается из неё месяц и год. Принимается, что указанный
месяц - последний, в котором действовал налог на ФОТ. То есть для отчислений в
ФБ РФ можно указать любую дату декабря 2009, например, 31.12.2009, а для ТФОМС
31.12.2011. В процессе расчёта налогов на ФОТ для перечислений, срок окончания
которых указан ранее расчётного месяца, записи в справочниках "Размер
социальных налогов до/после расчёта" не создаются и начисления по ставкам (даже
если они были введены отличные от 0) не производятся. Аналогичным образом
значение поля "Окончание" обрабатывается при выполнении сервисной функции
"Контроль (для налогов с годовой НБ)" по отношению к параметрам месяц+год.
Сервис удаления "лишних" записей справочников соцналогов не создавался, т.е.
если записи в справочниках соцналогов уже существовали на 2012 год - то они и
останутся. По мере необходимости из клиентских БД их можно удалить SQL-запросом.
G_ZARPL
Краткое описание :
Ошибка при расчете зарплаты с учетом смежных лицевых счетовОписание :
Расчет начислений (общие вопросы)Что измененно :
Не рассчитывается заработная плата по основному ЛС с параметром "с учетом смежных ЛС", если у смежного лицевого счета заведен имущественный вычет с алгоритмом 97 признак 1.
Как измененно :
Исправлен рантайм при расчете заработной платы по основному ЛС с параметром "с учетом смежных ЛС" если у смежного лицевого счета заведен имущественный вычет с алгоритмом 97.
G_ZARPL
Краткое описание :
Расчет по 4 алгоритму с незаполненным полем "оклад" в предварительном просмотреОписание :
Предварительный просмотрЧто измененно :
Если ВО рассчитывается по 4 алгоритму, а в предварительном просмотре не заполнено поле оклад, расчет не происходит по этому ВО.
Если поле оклад заполнено, то расчет происходит. Ранее расчет происходил в любом случае, теперь нет.
Как измененно :
Восстановлен функционал, который был изменен при решении ПИР 180.6906.
Теперь, если ВО рассчитывается по алгоритмам 4 и 3, а в предварительном просмотре не заполнено поле оклад, расчет происходит на основе текущего оклада на дату начала записи, так как это было раньше.
G_ZARPL
Краткое описание :
подоходный налогОписание :
Расчет подоходного налогаЧто измененно :
У клиента подоходный налог не возвращается, а берется в зачет будущих периодов.
Сотрудник в мае месяце 2012 года принес справку---имущественный вычет за декабрь 2011 года.
Перепробовала все, не льготирует.В расчетном листке показывает суммы льготы, но сам налог не пересчитывает, в размере годового после расчета з.пл ничего по налогу за декабрь не изменилось.
И в связи с тем, что налог не пересчитался, он не берется в зачет за май текущего года.
Для расчета з.пл выкрутились--- вносили руками сумму в таблицу=== суммы с предыдущего года===.
Но ,как правило,такие справки люди приносят и приносят.
Надо бы исправить эту ощибку.
Все льготы за текущий год идут нормально.
Табельный 238, база otp-816\\d:\base\grpotch\data\
Как измененно :
Исправлена ошибка погашения подоходного налога при расчете заработной платы по настройке на РБ.
У клиента существует схема возврата подоходного налога в зачет будущих периодов.
Сотрудник в мае месяце 2012 года принес справку---имущественный вычет за декабрь 2011 года.
Теперь налог за счет предоставленного вычета берется в зачет за расчетный месяц текущего года.
Примечание. Для локализации проблемы должно быть установлено значение 3000 настройки "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Налог на доходы \ Год изменения алгоритма расчета основного налога".
G_ZARPL
Краткое описание :
Выплата зар. платы не разбивается по доп. аналитикамОписание :
Расчет начислений (общие вопросы)Что измененно :
Выплата зар. платы не разбивается по доп.аналитикам в результатах расчета, поэтому неверно формируются реестры.
Проявляется в ситуации, когда дополнительные вналитики имеются два уровня: первый из ЛС, второй из КВО.
Также проявляется при наличии премии за прошлый месяц, перечисленных отпусков, основного и дополнительного за будущий в отчетном, и основной заработной платы.
Проблема в том, что перечисление отпуска проходит системным кодом 200, и для суммы перечисления в результатах расчета не подтягивается доп.аналитика из ЛС.
Как измененно :
Сумма к перечислению заработной платы разбивается по доп.аналитикам в результатах расчета, поэтому верно формируются реестры.
Перечисление отпуска проходит системным кодом 200, и для суммы перечисления в результатах расчета подтягивается доп.аналитика из ЛС и КВО.
Проблема проявлялась в следующей ситуации.
1. дополнительные аналитики имеются два уровня: первый из ЛС, второй из КВО.
2.при наличии премии за прошлый месяц.
3.при наличии отпусков, основного и дополнительного за будущий в отчетном
4.реестра на перечисление отпуска с системным кодом 200.
G_ZARPL
Краткое описание :
Система ругается на неутвержденные приказы. otpusk/factotpusk.clsch/tperson = 0Описание :
Расчет удержаний с отпусков межпериодаЧто измененно :
Включена технология планирования. Заводим приказ на отпуск, формируем из плановой записи фактическую и не! утверждаем приказ. При этом создаются записи в таблицах otpusk, factOtpusk с нулевыми ссылками по полям clsch и (t)person.
Таких неутвержденных приказов может быть больше десятка.
При расчете зарплатчиком НДФЛ с какого-либо отпуска, система выдает предупреждения:
Отсутствует ЛС с табельным номером 30002001! Проверьте справочник отпусков!
Отсутствует ЛС с табельным номером 31001544! Проверьте справочник отпусков!
Отсутствует ЛС с табельным номером 31001544! Проверьте справочник отпусков!
Зарплатчик ищет эти табельные номера, находит и не понимает что с ними не так. Предлагается не вводить зарплатчика в заблуждение в описанной ситуации.
Как измененно :
В случае обнаружения отпусков с нулевой ссылкой на лицевой счет сообщение об ошибке больше не выдается.