Добрый день!

Помогите разобраться в настройке объединения сумм в сводах.

По настройке виды страховых взносов объединяются (например суммы 341 и 511 объединяются и выводятся по 341 коду).

ZPL_zplinfo_full_net(20190704_145805).cab

Но если  ЛС есть суммы только по 511 коду, и нет 341, то в свод выводится 2 строки: 341 (по другим людям) и 511 (по данному сотруднику).

Приложил сохранёнку. Подскажите, пожалуйста, как исправить.

Добрый день!

В таблице в "Ф-ция разноски"  прописана ф-ция PutST, которая производит разноску по F6.

Возможно ли с помощью этой ф-ции (PutST) производить разноску в ЛС  из скрипта, вызываемого по Alt_F4, чтобы не использовать  F6 ?

Простая вставка ф-ции в скрипт результатов не даёт.

Добрый день!

Где можно найти описание и порядок применения ф-ции  GetOrderRow() ?

Добрый день!

В связи с появлением услуг типа "Массовая диспансеризация"  увеличились объемы работ по расчету среднего.

Расчетчики просят организовать массовый  расчет среднего через таблицу,  что вполне решаемо с помощью

класса KCalcSredn.

Но, поскольку, при любом расчете среднего в архив подшивается "Таблица расчета среднего",

возможно ли появление в классе KCalcSredn  появление метода который бы выводил такую таблицу?

Добрый день!

Можно ли в 116 алгоритме школьной версии сделать (может быть параметр какой-то есть), чтобы ФРВ бралось не из табеля, а вводилось вручную и при пересчете не корректировалось?

Добрый день!

Расчёт доплаты до МРОТ происходит по месяцу принадлежности. Суммы, начисленные 

за предшествующий месяц/месяцы в расчёт МРОТ не берутся.

Клиент просит перенастроить алгоритм расчёта так, чтобы он учитывал суммы по месяцу начисления.

Подскажите, пожалуйста, правомерен ли вообще такой расчёт МРОТ, и если да, как можно изменить настройку?

Добрый день. Подскажите как прописать, чтобы оплата за качество выполненных работ (считается от оклада) включалась в расчет праздничных

подскажите пожалуйста существует ли в таблице входимости алгоритм расчета премии по такой формуле  

оклад деленный на норму рабочего времени за квартал

умножить на количество отработанный дней за квартал

умножить на процент премии     ( то есть выглядит примерно так за 1 квартал 2019 г. 10000 / 57 x 34 x 75%)

эта формула отличается от обыкновенной формулы расчета премии за квартал ( код 112)

Добрый день!

При работе с клиентом возник вопрос, повторил на поставке. Помогите, пожалуйста, разобраться.

Расчёт за первую половину месяца настроен так:

Сумма заработной платы по 21-му столбцу ТВХ собирается на мнимый вид 901.

Рассчитываю сотрудника за первую половину месяца. Получаю следующий результат.

Расчёт корректный, замечаний нет.

Затем выясняется, что человек прогулял несколько дней в феврале.

Выполняю пересчёт месяца. Рассчитываем ЛС за первую половину ещё раз. После чего ЛС принимает следующий вид:

Получается, в расчёт за первую половину месяца берутся суммы только за март.

Допустим, клиент провёл массовый расчёт за первую половину и сформировал кассовую ведомость по мнимому виду 901, на который упали результаты расчёта. 

В итоге получается вот какая картина:

Во второй половине месяца рабочих дней у человека нет. 

Получается, если в апреле сотрудник не отработает ни дня и уволится, по нему повиснет "долг", который будет уже не из чего удерживать. Сейчас клиент отслеживает таких людей вручную и вручную же исправляет сумму к выдаче по авансу на меньшую, чтобы учесть пересчёт предыдущих месяцев.

Посоветуйте, пожалуйста, как лучше поступить? Создать табличку, которая будет отслеживать подобные ЛС после расчёта за первую половину?

Добрый день!

У клиента в ходе работы возникла ошибка - в какой-то момент времени по неизвестной причине в УЖЕ рассчитанных ЛС табель заменился на неправильный.

Пример.

У сотрудника стоит стандартный график рабочего времени - 5 дней по 8 часов. В соответствии с этим графиком сотруднику рассчитан оклад за полностью отработанный месяц - 159 часов.

После расчёта часы табеля по какой-то причине изменились:

Вручную расчётчики заполнить часы табеля не могли. Такое невозможно чисто физически, т.к. изменения в табеле мы нашли почти у 3 тысяч сотрудников.

Была версия, что всему виной интеграция с "Контур-Персоналом". Проверили через сервис мониторинга в КПМ - табеля не утверждались никогда. По одному отделению мы табель утверждали сами, когда пытались определить причину ошибки. Эти утверждения/разутверждения и видно на скриншоте.

Кроме того, проверили в КЗ письма интеграции - табеля не присылались никогда (за исключением, опять же, случая тестирования). Следовательно, Интеграция с КП ни при чём (если она не происходит в каком-то скрытом режиме).

Средствами автоматической разноски в КЗ такого результата достигнуть можно, но таблиц разноски, влияющих на часы табеля мы клиенту не делали, а сам клиент их тем более создать не мог.

Таким образом получается, что в какой-то момент сотрудникам массово разнеслись в табель непонятно откуда взятые значения часов.

Сейчас мы оказались в ситуации, когда расчётчики не могут выполнять по уже рассчитанным сотрудникам доначисления, не могут выполнять пересчёты, и по всем ещё не рассчитанным сотрудникам им приходится обнулять табель вручную.

Скажите, пожалуйста

1) каким образом могла возникнуть данная ошибка, случалось ли такое ранее в других организациях?

2) каким образом можно наиболее просто и безболезненно эту проблему исправить/?