>Т.е. ручная корректировка присутствует.

>Выделить "новые" виды и поставить им массово источник не сильно трудозатратнее чем, поставить источник в к.ч.

И потом помнить, что надо менять источник для таких-то сотрудников, если им добавляется вид Н-У. Например, разносится массово премия.

>В к.ч.при переводе ( с даты перевода) запишется и должность и категория.

А также меняется и дата приёма и дата увольнения.

(см тему:

https://kontur.userecho.com/communities/47/topics/7637-integratsiya-s-kp-pri-nastrojke-priyoma-id-raznosit-tolko-v-kch-menyaetsya-data-priyoma-v-id

что чревато другими ошибками.

Возвращаясь к основной теме с расчётом отпуска:

>>Если перенести (вручную или через таблицу разноски) все неявки из табеля старой основной должности в табель новой - это решит проблему с расчётом среднего. Возможен ли такой вариант, или он выйдет боком где-то в другом месте?

Отлично, спасибо!

Буду знать.

>Интересно, а как программа узнает, что источник в ЛС сменился? Из КП разве передается подобная аналитика?

Источник из КП не передаётся. С этим вопросом мы тоже не раз обращались, там проблема в том, что в КП могут при приёме разбить должность по нескольким источникам (принять на 1 ставку, но из неё 0,5 на Бюджет, 0,25 на Спецсчёт и т.д.)

В данном случае у клиента есть чёткое соответствие между должностью сотрудника и источником финансирования. Расчётчик видит, что пришла новая должность из КП, видит категорию должности (тоже передаётся из КП) и ставит на её основании источник для данной ИД.

>>Отключать интеграцию видов я не предлагал.

Если пришёл "голый" вид Н-У, в нём нет информации по подразделению, категории, источнику. Расчётчик не сможет корректно провести расчёт и выплатить суммы по этому виду Н-У, потому что не знает, на какой источник, подразделение, должность эти суммы ставить, по какому источнику их выплачивать.

Если нет ИД с этими параметрами - только ждать бумагу из кадров и с неё перебивать.

>>Старые виды НУ закрываете, новые открываете.

>>Для новых видов НУ указываете источник, ШЗ, категорию

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

>>1)Ручная корректировка среднего

>>2)Либо вариант озвученный выше (при переводах не плодить должности)

3) Если перенести (вручную или через таблицу разноски) все неявки из табеля старой основной должности в табель новой - это решит проблему с расчётом среднего. Возможен ли такой вариант, или он выйдет боком где-то в другом месте?

>>Зачем в данном случае вы перевод приняли на отдельную должность? Почему нельзя было принять данные на действующую должность?

На должность завязаны источник финансирования, категория и шифр затрат.

И клиенту требуется разбивать суммы в сводах по подразделениям, в т.ч. по одному конкретному сотруднику, если перевод был в середине месяца.

>>Ждите когда в КЗ будет реализована цепочка переводов, тогда средний можно будет посчитать правильно...

На какие сроки ориентировать клиента и как решать проблему до тех пор?

Сотрудник переведён с 1.07.2019 на новую должность.

Считаю по прежней должности:

Считаю по текущей должности:

В итоге получилось 2 отпуска, по старой должности, и по новой.

В связи с чем в глаза бросаются ошибки:

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

2) При расчёте по прежней должности за июль ставится сумма "0" и рабочие дни "29.3". Что делает расчёт среднего неправильным.

>>Нужно сначала сделать расчет по первой должности, потом по второй.

3) Расчётчик должен об этом помнить сам и вручную по каждой просчитывать? А если переводов будет пять в течение 12 месяцев?

Таким образом, рассчитывать отпуск клиенту требуется в целом по всему заработку сотрудника, а не по отдельности, и из КП информация приходит именно так.

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

Как это выглядит в КП:

Исполняемые должности:

Отпуска (какие были, такие и остались)

Каким образом рассчитывать отпуск, чтобы на выходе получились корректные данные?

Ввели объекты для каждой группы подразделений. Теперь будем формировать ведомости по объектам.

Задача не решена, но найден обходной путь.

Решили через "объекты". завели отдельный объект для одной группы подразделений, и для другой.

>У вас по прежнему ведомости создаются с пересекающимися id? Ситуация воспроизводится постоянно или время от времени?

Да. В 2018 году созданы ведомости с ID по 8000.

С 2019-го нумерация пошла с начала. сейчас 3780 и новые продолжают создаваться по порядку.

Увидел, спасибо.

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

Кстати, вернул в ТВХ настройку "1,* " для 354-го кода - с 3 знаками после запятой формируется тоже 79 копеек.