G_ZARPL
Краткое описание :
Алгоритм для расчета нарядовОписание :
Формирование нарядовЧто измененно :
Недостаточно существующих алгоритмов по расчету нарядов для
необходимого предприятию расчета.
Нужен алгоритм, который позволит получить итоговое количество "Часы факт"*"КТУ"
по операции, так как в наряде две (и более) операции.
Также нужна возможности взять "Часы факт с учетом КТУ" по каждому работнику и
"Часы факт" по каждой записи в спецификации наряда.
Как измененно :
NRSUMTIMEBYOP(OPERATION: comp, withKTY: boolean): double;
Возвращает сумму фактически отработанного времени (с учетом КТУ, если параметр
withKTY равен true) по операции OPERATION из спецификации наряда. Операцию в
собственном алгоритме можно выбрать с помощью функции OPERNAR.
NRSUMTIMEBYLS(LS: comp, withKTY: boolean): double;
Возвращает сумму фактически отработанного времени (с учетом КТУ, если параметр
withKTY равен true) для конкретного работника LS из спецификации наряда.
Лицевой счет в собственном алгоритме можно выбрать с помощью функции LSNAR.
NrTime(withKTY: boolean): double;
Возвращает сумму фактически отработанного времени (с учетом КТУ, если параметр
withKTY равен true) по конкретному наряду из спецификации наряда.
G_ZARPL
Краткое описание :
перенос сальдо по матпомщи с основного ЛС на доп.Описание :
Контроль доходаЧто измененно :
Переносить и суммы с предыдущего места работы и сальдо на начало месяца только из смежных дополнительных ЛС в смежный основной.
Как измененно :
Теперь суммы с предыдущего места работы и сальдо на начало месяца переносятся только из смежного дополнительного ЛС, который имеет вид работы "Основное место работы" и который был уволен последним, в смежный основной, который является физическим лицом.
G_ZARPL
Краткое описание :
Сумма налогового вычета при расчете НДФЛ с отпуска и матпомощи к отпуску учитывается дваждыОписание :
Расчет удержаний с отпусков межпериодаЧто измененно :
У сотрудника через постоянную доплату заведен налоговый вычет на сумму удержанных взносов (ежемесячных) в негосударственный пенсионный фонд. Рассчитывают отпускные, заводят матпомощь к отпуску. Запускают расчет отпуска и удержаний (Shift-F8). Сумма налогового вычета учитывается при расчете НДФЛ с отпускных сумм и с сумм матпомощи к отпуску, то есть дважды, что в дальнейшем приводит к пересчету НДФЛ при окончательном расчете. Нужно чтобы вычет учитывался один раз. Описание клиента во вложении.
Как измененно :
При расчете НДФЛ с материальной помощи к отпуску учитывается ранее примененная скидка при расчете НДФЛ с отпуска.
G_ZARPL
Краткое описание :
Сообщения при обновлении реестра настроек на пустой базеОписание :
Проверка реестра настроекЧто измененно :
При запуске Галактики на пустой базе выдается ряд сообщений, среди которых могут быть:
----------------------------------------------------------
1) Нет настройки UP.DATOTCH. Выполните "Проверку реестра настроек".
2) Нет настройки UP.TEKBUD. Выполните "Проверку реестра настроек".
3) Нет настройки UP.ZAR.CheckBasket. Выполните "Проверку реестра настроек".
4) Нет настройки User.FIO. Выполните "Проверку реестра настроек".
5) Данный вариант недоступен, так как
учет цен в складском учете ведется по
предприятию в целом, а не по разрезам
(См."Настройки Галактики\Логистика\Складской учет\Методика списания")
6) Не открылась таблица "Характеристики предприятия"
----------------------------------------------------------
Нужно по возможности исключить выдачу этих сообщений.
Как измененно :
При запуске Галактики на пустой базе перечисленные сообщения не выдаются.
Изменено значение по умолчанию настройки "Настройки Галактики \ Бухгалтерский контур \ Учет ОС и НМА \ Настройка операций \ Выбытие \ Выбор МЦ для реализации" на "способ не определен". Ранее было "по ссылкам из инвентарных карточек".
G_ZARPL
Краткое описание :
При наличии двух пост. удержаний на перечисление в банк результаты расчёта формируются некорректноОписание :
Расчет удержаний (общие вопросы)Что измененно :
В результатах расчёта в 221 ВУ сумма начисления, ссылка на ВО и параметр указаны из 218 ВО, хотя сумма к выплате относится к 207 ВО.
Имеется несколько видов Параметров.
Добавляем начисление 218 (Компенсация) с параметром "213_КВР 122".
Добавляем удержание 131 для для 218 ВО.
В зависимости от Параметра собираются, контролируются налоги (разные корреспонденции счетов по КОСГУ - Классификация операций сектора государственного управления); так, в приведенном инциденте все начисления (до того, как ввели ВО 218 - СанКур) были в рамках параметра 213_статья,, соответствующего КОСГУ = 211.
Соответственного, все удержания и налоги должны собираться в рамках этого Параметра, НЛФЛ выделялся одной строкой. Проводки собирались по определенным корреспонденциям счетов.
Т.е. при добавлении 218 начисления и соответствующего ему 131 удержания система должна их связывать.
Теперь же кроме 131 удержания параметр "213_КВР 122" также формируется и в 221 удержании. Поэтому ТХО формирует проводки с некорректными суммами.
Как измененно :
Доработана функция разбиения суммы к перечислению при расчете заработной платы для значений "по подразделениям, аналитике и параметру входящих оплат"
и "только по видам оплат" настройки: "Настройки Галактики \ Управление персоналом \ Расчеты с персоналом \ Режимы расчетов \ Разбивать удержания".
Теперь, если для удержания нет вида оплаты, то сопоставление его с начислением происходит по другим параметрам. Таким образом оно относится к соответствующей группе начислений
и вторично запись этими атрибутами в сумму "к перечислению" не попадает.
G_ZARPL
Краткое описание :
В отчет 6-НДФЛ попадают не те суммы по отпускам, которые реально перечисленыОписание :
Расчет удержаний (6-НДФЛ)Что измененно :
При расчете заработной платы формируются +- записи НДФЛ по отпускам межпериода.
Схема формирования данных:
Начислен отпуск, часть которого приходится на будущий период
рассчитан отпуск
сформирован реестр на перечисление отпуска и НДФЛ
Заново рассчитан отпуск, сумма начислений изменилась в большую сторону
сформирован реестр на перечисление отпуска и НДФЛ
Рассчитана заработная плата.
Проблема проявляется при следующих настройка:
1. Для видов оплаты отпуска установлено значение "по месяцу, в котором выплачен" в поле КВО "Учет дохода в налоговой отчетности"
2. Для видов оплаты отпуска установлено значение "По настройке выбора ШПЗ с учетом наличия данных" в поле КВО "Параметр", причем параметр в КВО не задан, а задан в ЛС работника.
3. Дата выплаты начислений отпуска принадлежит марту.
4. Дата оплаты реестра также принадлежит марту (т.е. доход учитывается к марту)
5. Виды оплат для начисленных сумм за будущий период в первом и втором реестре различаются.
В первом реестре - это виды оплат для текущего отпуска, во втором реестре - для будущего.
Как измененно :
Исправлена ошибка расчета заработной платы по учету реестров на перечисление отпуска и НДФЛ в межпериод.
Проблема проявлялась при наличии двух реестров связанных с пересчетом отпусков с установленными настройками:
1. Для видов оплаты отпуска установлено значение "по месяцу, в котором выплачен" в поле КВО "Учет дохода в налоговой отчетности"
2. Для видов оплаты отпуска установлено значение "По настройке выбора ШПЗ с учетом наличия данных" в поле КВО "Параметр", причем параметр в КВО не задан, а задан в ЛС работника.
Теперь в таких случаях результаты расчета НДФЛ развиваются на две части для каждого периода и вида оплаты отпуска . Первая часть отражает сумму дохода и НДФЛ из первого реестра,
вторая часть остаток дохода и НДФЛ согласно пересчету.
Для каждой записи заполняется источник данных "Отпуск".
G_ZARPL
Краткое описание :
Перестали работать алгоритмы для работы с табелем из списка нарядовОписание :
Формирование и расчет нарядовЧто измененно :
Перестали работать табельные алгоритмы для расчета нарядов из списка нарядов. Начинают работать только если на фоне запустить интерфейс с табелем или создать и удалить запись наряда.
Как измененно :
Теперь табельные алгоритмы при расчете нарядов из табличного просмотра работают нормально.
G_ZARPL
Краткое описание :
Сделать что-то с таблицей IndeksОписание :
ИндексацияЧто измененно :
В таблице Indeks для РБ проблема: поле "конец интервала" может иметь одинаковое значение для разных категорий, при одинаковом DATREC и KOLMIN. Вернее, проблема как раз заключается в том, что это значение одинаковым быть НЕ может, потому что в таблице Indeks описан индекс
Indeks01 = DATREC(Unique, Desc) + KOLMIN(Unique) + ENDINT(Unique)
Уникальность по этому набору полей мешает для Беларуси заводить в этом классификаторе записи, где данные три поля одинаковые. Но на самом деле для РБ дата закона, кол-во МЗП и конец интервала могут совпадать для разных категорий, и это нормально. То есть, уникальной должна быть комбинация четырёх полей (+ CHOICE), а не трёх.
Нужно обеспечить корректное хранение данных в этой таблице, когда значения даты, кол-ва МЗП и конца интервала совпадают, но не совпадает категория.
Как измененно :
В индекс Indeks01 таблицы Indeks добавлен сегмент CHOICE (код категории). Уникальность индекса сохранена:
Indeks01 = DATREC(Unique, Desc) + KOLMIN(Unique) + ENDINT(Unique) + CHOICE(Unique)