G_ZARPL
Краткое описание :
Очистка буфера перед запуском алгоритма расчета ЗПОписание :
Алгоритмы пользователяЧто измененно :
Пример алгоритма:
1) If(SumAlgNo(2)=0, if(Uch_Summa=0, SETBUFVALUED(LSC_TARIF*UCH_CHASF/169.3*UCH_PROC/100 + GETBUFVALUED)*0 + Round(GETBUFVALUED,2) + SETBUFVALUED(GETBUFVALUED- Round(GETBUFVALUED,2))*0,Uch_Summa),0)
2) if(GETBUFVALUEC<> UCH_LSCH, SETBUFVALUEC(UCH_LSCH)*0+SETBUFVALUED(0),0)
Если несколько раз запускать расчет по одному ЛС, то при работе с буфером он не обнуляется, что ведет к неверным расчетам.
Как измененно :
Перед выполнение расчета заработной платы для каждого лицевого счета происходит очистка буфера для временного хранения значений.
G_ZARPL
Краткое описание :
Добавить еще переменные для работы с буфером в функции
используемые в алгоритмах расчета ЗПОписание :
Алгоритмы пользователяЧто измененно :
Для использования расчета доплат с использованием
пользовательских алгоритмов при работе с буфером
(GETBUFVALUED, SETBUFVALUED) необходимо иметь
возможность использовать свой буфер для отдельного
алгоритма. Иначе можно завести только одну доплату
которая будет использовать при расчетах буфер.
Как измененно :
Для работы с пользовательскими алгоритмами добавлены функции:
- GETBUFVALUEDI(longint): double
- SETBUFVALUEDI(longint, double): double
Функция SETBUFVALUEDI сохраняет во временном буфере значение числа с плавающей
точкой. В первом параметре передается индекс, по которому будет сохранено
значение, переданное во втором параметре. Функция возвращает сохраненное
значение.
Функция GETBUFVALUEDI предназначена для получения из временного буфера
значения, сохраненного по определенному индексу, который передается в качестве
параметра.
Максимальное количество индексов, которые могут быть применены для сохранения
значений равно 2147483647.
Значение по индексу 0 можно сохранить и получить при помощи функций
SETBUFVALUED и GETBUFVALUED (функции без постфикса I)
G_ZARPL
Краткое описание :
На северный стаж 1 месяц насчитывается 1% северной надбавкиОписание :
Расчет начислений (общие вопросы)Что измененно :
На северный стаж работы в остальных районах крайнего севера продолжительностью 1 месяц 19 дней насчитывается 1% северной надбавки (вместо 0%) и этот процент идёт в итоговый расчёт.
Как измененно :
Доработан расчет северных надбавок с настройками:
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Северные надбавки \ Учитывать изменения особых климатических условий" - "да"
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Северные надбавки \ Расчет периода проживания для молодежи" - "для каждого типа местности"
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Северные надбавки \ Переход на дополнительную шкалу при достижении 60%" -"да"
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Северные надбавки \ Пересчет процента надбавки при изменении типа местности" - "нет"
Если в настройке указано значение "нет", то расчет идет согласно консультации АЦ.
Расчет из консультации Москвы:
Период работы с 18.11.2010 по 29.07.2011 в иных местностях составляет 8 мес.11 дней. За это время сотрудник не заработал надбавку (так как меньше 1 года), значит, этот стаж работы отбрасывается и далее не учитывается при подсчете северных надбавок.
Теперь настройка учитывается еще и при переходе из типа местности "Остальные районы Крайнего Севера" в "Местности, приравненные к рКС".
G_ZARPL
Краткое описание :
Требуется доработать настройку "Раздельный расчет по обособленным подразделениям"Описание :
Расчет подоходного налогаЧто измененно :
Требуется доработать настройку "Раздельный расчет по обособленным подразделениям".
НА данный момент данная настройка имеет 3-ри значения.
1. Нет
2. из дополнительных аналитик
3. из подразделений отнесения затрат.
Клиенту для работы требуется 2-й и 3-й варианты настройки, т.к. есть случаи и изменения кпп и переходы в обособленные подразделения.
Постоянно варьировать настройками и делать контроль дохода не удобно и не всегда можно вовремя это сделать.
Я предлагаю 2-ю и 3-ю настройку объединить в одну, далее программа должна делить по направлениям настройки сама либо смена кпп, либо переход в обособленное.
Как измененно :
1. Доработана функция контроля для раздельного расчета по обособленным подразделениям.
Исключена возможность заполнения облагаемой суммы и вычетов в этой функции. `
Изменено окна ввода параметров для функции "Контроль дохода".
Параметр "Заполнять облагаемую сумму и вычеты в записи об удержании" переименован. Теперь он называется "Заполнять ссылки на обособленные подразделения, КПП и ОКТМО".
Теперь поля "Облагаемая сумма" и "Сумма вычетов" из функции "Контроль дохода" в "Суммах удержаний" не заполняются.
Контроль исходных облагаемых сумм теперь можно выполнить только из функции "Контроль для раздельного расчета по обособленным подразделениям".
Параметр "Заполнять ссылки на обособленные подразделения" переименован. Теперь он называется "Заполнять ссылки на обособленные подразделения, КПП и ОКТМО".
В функции "Контроль для раздельного расчета по обособленным подразделениям" добавлен дополнительный анализ параметров.
При выборе значения "Заполнять облагаемую сумму" добавлен запрос следующего содержания
"Перед выполнением функции с параметром "Заполнять облагаемую сумму""
"рекомендуется сохранить копию архива "Суммы удержаний"!"
"Продолжить?'.
Если параметр не установлен, также выводится соответствующее сообщение.
При вывод протокола зависит от параметра "Выводить протокол выполнения функции".
Примечание. Вывод протокола в функции Контроль дохода, по прежнему зависит от значения "о расчете НДФЛ по обособленным подразделениям" настройки
"Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Режимы расчетов \ Печать пояснительного протокола"
2. Доработана функция выбора подразделения из дополнительных аналитик при значении параметра "Заполнять облагаемую сумму"".
Теперь преимущество имеют дополнительные аналитики из базовых таблиц "Суммы оплат" и "Суммы удержаний".
Также усовершенствована функция сопоставления записей суммы начислений и удержаний при заполнении облагаемой суммы и суммы вычетов.
Теперь кроме анализа счета, субсчета и дополнительных аналитик, сопоставляются вида оплаты из начислений и удержаний НДФЛ.
3. Доработана функция расчета НДФЛ при расчете зарплаты для значений отличных от "нет" в настройке:"Раздельный расчет по обособленным подразделениям".
Теперь это значение учитывается для пересчета за прошлый год в текущем.
G_ZARPL
Краткое описание :
При контроле годового до хода рантайм 216 на определенном работнике.Описание :
Контроль доходаЧто измененно :
1.Во время контроля дохода сотрудника, у которого есть смежные лицевые счета, но нет подходящего для переноса сальдо, галактика падает с runtime.
2.Падение при наличии в результатах расчета записи по материальной помощи за прошлый месяц, который выбран для контроля дохода.
Как измененно :
Исправлено падение. Теперь контроль дохода отрабатывает нормально.
G_ZARPL
Краткое описание :
Некорректный расчет ИПН в случае ухода на пенсиюОписание :
Контроль доходаЧто измененно :
Некорректный расчет ИПН в случае ухода на пенсию
У всех работников-пенсионеров неверно рассчитывается п/налог. Расчет касается тех работников, которые например, в марте 2017 достигли пенсионного возраста (и в марте у них прекратили удержание в пенсионный фонд путем изменения настройки в ЛС)
Сейчас п/налог рассчитывается так, как будто происходит добор п/налога с ОПВ за предыдущие месяцы.
По трудовому кодексу РК работодатель не имеет права увольнять работника, вышедшего на пенсию.
Был выполнен Контроль дохода по всему заводу, так как работников, с которых удерживается ДПВ, от 1000-2000 человек. В связи, с чем обнаружилась данная ситуация.
После выполнения контроля дохода, в таблице "Размер годового дохода" суммы в графах Основной +совокупный доход и За вычетом пенсионных равны в месяцах до выхода работника на пенсию.
Как измененно :
Доработана функция Контроль дохода по настройке на страну "Казахстан".
Теперь значение поля "за вычетом пенсионных" формируется независимо от признака Лицевой счет => Взносы => Пенсионный.
Если у работника в архиве удержаний есть взносы в пенсионный фонд, то они льготируют доход.
У работников, вышедших на пенсию этих сумм не будет, значит сумма "за вычетом пенсионных" за те месяцы, которые работник был на пенсии, будет равна доходу.
G_ZARPL
Краткое описание :
Некорректная разбивка НДФЛ в результатах расчета при наличии 2 реестров НДФЛ на 1 выплату в межпериодОписание :
Расчет удержаний (6-НДФЛ)Что измененно :
При оплате НДФЛ 2 реестрами по одной выплате в межпериод некорректно разбивается НДФЛ по видам оплат и некорректно формируется НДФЛ-6 раздел 2.
К сожалению 2 реестра - это не каприз клиента, связано с финансированием оборон заказов.
Как измененно :
1.Доработана функция учета реестров на перечисление НДФЛ при расчете заработной платы. Теперь в случае перечисления НДФЛ 2 реестрами по одной выплате в межпериод, сумма НДФЛ из реестров суммируется,
а не погашается.
2.На второй итерации доработан еще один случай учета реестров при расчете заработной платы после ручной корректировке реестра на перечисление НДФЛ для режима "Начисления и выплаты".
В рамках данного решения учитываются только корректировки в меньшую сторону.
Теперь при наличии одной или нескольких учетных сумм операций, их результат ограничивается общей суммой по работнику, которая была откорректирована.
Доработка проводилась для значений "учет не ведется" и "учет ведется" настройки
"... \ Учет межпериода при расчете зарплаты \ Учет выплат по реестрам"
G_ZARPL
Краткое описание :
Удержания и выплаты - отражение в налоговой отчетностиОписание :
Расчет сумм в режиме "Удержания и выплаты"Что измененно :
1.Нужно сохранять в реестрах и ведомостях "Удержаний и выплат" сумму дохода. Сумму дохода брать из поля "Сумма к обложению".
2. Доработать расчет заработной платы с тем, чтобы суммы, сформированные на основе удержаний в межпериод, записались корректно в результаты расчета.
Как измененно :
1. Доработана функция формирования реестров и платежных ведомостей в части сохранения суммы дохода. Теперь сумма дохода для "Удержаний и выплат" берется из поля "Сумма к обложению".
2. Доработан расчет заработной платы с тем, чтобы суммы, сформированные на основе удержаний в межпериод, записались корректно в результатах расчета.
Схема Формирования.
Если в суммах оплат присутствует начисление с видом оплаты, который совпадает с видом оплаты из "Удержаний и выплат", то доход записывается в результаты расчета с этим видом оплаты.
Если при этом сумма дохода превышает соответствующую сумму начисления или же для вида оплаты из "Удержаний и выплат" нет вида оплаты в начислениях, сумма распределяется
последовательно, по другим видам начислений, согласно полю "Приоритет оплаты при расчёте удержаний и предоставлении вычетов"
Примечание. значение 0 в поле "Приоритет оплаты при расчёте удержаний и предоставлении вычетов" воспринимается как пустое: в этом случае учитывается обычный приоритет КВО (как и при расчёте удержаний).
Поэтому лучше устанавливать приоритеты, начиная с единицы.
G_ZARPL
Краткое описание :
Расчет зарплаты - учитывать вычеты межпериода из реестровОписание :
Предложение по новой функциональности модуля заработная платаЧто измененно :
Сейчас при окончательном расчёте зарплаты программа пытается обратным расчётом вычислить вычеты, предоставленные в межпериод (поскольку в операциях межпериода вычеты не сохраняются). Такой подход не всегда даёт правильную картину.
Предлагается после доработок сохранения вычетов в операциях и реестрах межпериода (при окончательном расчёте брать сохранённые вычеты из реестров.
Как измененно :
При расчете заработной платы вычеты для сущностей межпериода берутся готовыми суммами из реестров. При этом, если были сформированы реестры до установки данного обновления, то вычеты будут вычисляться.
G_ZARPL
Краткое описание :
Расчет удержаний - формируемая аналитика не соответствует настройке КАУ для бухсчетаОписание :
Расчет удержаний (общие вопросы)Что измененно :
При определённых условиях в результатах расчёта для удержания (перечисления) отпускных в межпериод формируется аналитика по сотрудникам, хотя на счёте такая аналитика в принципе не ведётся.
Возможно, переносится из начисления отпускных (по настройке "Разбивать удержания - по подразделениям, аналитике и параметру входящих оплат").
В результате при формировании проводок получаем неправильную аналитику.
Необходимо добавить проверку на наличие аналитики в случае, если пользователи хотят переносить КАУ, которые есть в реестре, но с учетом аналитики по счету/субсчету.
Изменить название параметров в классификаторе видов удержаний (особенности выбора КАУ) - "... из постоянного удержания." на "... из источника".
Как измененно :
В классификаторе видов удержаний изменены названия параметров для "особенностей выбора КАУ" фраза "из постоянного удержания" заменена на "из источника".
При учете данного поля при выполнении функции формирования результатов расчета добавлена проверка на наличие аналитик на счете в случае, если пользователи хотят переносить КАУ, которые есть в реестре, но с учетом аналитики по счету/субсчету.