ZPL2907_zplinfo_full(20190813_144422).cab

Tabl6.Sum

На всякий случай приложил парочку сохранённых ЛС, чтоб не передавать отдельно ТВХ, список доп.реквизитов и прочее.

Код оклада клиент видеть не будет, ей только базовое значение нужно.

Доп реквизиты вытаскиваются тоже неправильные - оба по одной и той де строке (в том примере - 4.01.

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

Поэтому приходится принимать БЗ оклада, принимать повышающий коэф-т из доп.реквизита, а потом перемножать их.

Но это уже усложнение исходной задачи - сейчас даже просто принять БЗ или принять доп.реквизит получается только если у сотрудника одна действующая строка оклада.

ясно, спасибо.

завтра с утра пройдусь по должностям в КП и отпишусь о результатах.

Верно.

Проблема в том, что клиент хочет там видеть дату приёма в организацию (2016 год), а получает дату последнего перевода (2018-й).

Спасибо!

Добрый день. Пожалуйста.

Уважаемые разработчики, до сих пор ждём ваш ответ.

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

Готов предоставить удалённый доступ.

Уважаемые разработчики, до сих пор ждём ваш ответ.

По предложенному ранее в соседней теме варианту:

>>У настройки "Способ приема Исполняемых Должностей" есть значение 2 - при котором дата увольнения не меняется.

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

Ваш ответ понятен. Будем пока устраивать паллиативные меры с переносом табеля на новую должность, и ждать выхода нового функционала.

По поводу того, что считать ошибкой, остановлюсь отдельно.

>>В моем понимании ошибка, это когда что-то сделали, но работает неправильно (не так как задумывали).

>>Отсутствие какой-либо возможности это не ошибка.

Проблема именно в том, что до конца непонятно, "как именно задумывали".

Я постараюсь описать своё видение проблемы, прошу прощения, если как-то коряво сформулирую.

Насколько я понимаю, основная проблема кроется в том, что мы говорим о разных сценариях работы системы и пользователя.

У нас есть параметр интеграции "Способ приёма Исполняемых Должностей".

Николай говорит о том, что если поставить в неё значение "1" или "2", то описанная выше проблема не возникнет.

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

Но зачем тогда возможность поставить параметр "0", когда "каждая должность сотрудника принимается как новое совместительство"?

Если у нас есть единственно верный сценарий работы с интеграцией - когда все переводы разносятся на одну ИД, то зачем "задумывали" другие варианты? Тогда сама возможность для внедренца указать параметр "0" - ошибка.

Если же вариант с параметром = "0" - возможен, и "задумывался", то при одном из сценариев работы расчётчика ("был перевод" И "рассчитываем отпуск") мы упираемся в тупик, описанный выше. Что и является ошибкой.

Не может же так быть, чтобы вариант "принимать каждую должность как новое совместительство" - "задумывался", а последствия - "переведённому сотруднику нужно рассчитать отпуск" - "не задумывались"?

Нам не хватает развёрнутой инструкции по работе с интеграцией. С ней подобных вопросов бы не возникало в принципе

>>>Как вы массово разносите премии, для каждой строки в таблице указываете на какую должность поставить сумму? Та еще автоматизация...

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

>>У настройки "Способ приема Исполняемых Должностей" есть значение 2 - при котором дата увольнения не меняется.

Предлагаю обсуждение этого вопроса всё же перенести в указанную тему.

>>копирование табеля в новую должность должно помочь с проблемой учета неявок

Я спрашивал о другом.

Хорошо, будем надеяться, подводных камней не выйдет.