Добрый день.

Просим дополнить интерфейс обработки приказов в КЗ. Добавить новое поле "Дата приказа".

Для этого выявилось сразу две причины.

1. Клиент - бюджетная организация. Зарплата закрывается и выплачивается до конца текущего месяца. Поэтому до 25 числа месяца расчётчик обрабатывает поступающие из КП приказы в текущем режиме. Затем, после 25 числа, кадровики утверждают в КП табель, и расчётчик считает зарплату по организации. Все приказы, которые кадры оформляют после 25 числа будут обрабатываться уже в следующем месяце.

Поэтому расчётчику требуется видеть, когда был утверждён данный приказ (как вариант, когда письмо пришло в КЗ). Тогда расчётчик сможет отсортировать необработанные приказы по дате утверждения и обрабатывать только те, что поступили до 25 числа месяца.

Иначе существует риск, что сотруднику рассчитают зарплату, сформируют кассовую ведомость, спустя 2 дня начислят отпускные или работу в выходной день за текущий месяц, и "недоплатят" - начисленные суммы встанут на 101 вид "Остаток" и перенесутся на след.месяц. Такое для клиента крайне нежелательно.

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

2. По сотруднику давно не обрабатывались приказы, либо кадры переделывали приказ.

Нередки ситуации, когда кадровик принял приказ, отменил его, исправил, принял ещё раз. А потом заметил ещ недочёт и исправил его тоже.

В этом случае в необработанных приказах в ЛС может присутствовать 5 строчек "Удаление вида Н-У", и следом ещё 5 строчек "создание вида Н-У". плюс между ними несколько отпусков, больничных и т.д.

Дополнительная сортировка по дате утверждения приказа позволит лучше понять, в каком порядке приказ утверждался/разутверждался. И, соответственно, расчётчику будет проще справляться с обработкой приказов из КП.

Добрый день.

В КП создаётся приказ "По беременности и родам". Всё сделано верно, никаких "дублей", "лишних приказов" нет.

После обработки писем в КЗ в лицевом счёте отображаются два приказа:

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

Если начать обрабатывать второй - выходит сообщение:

Расчётчика мы, разумеется, научили, что на втором приказе нужно нажать F3, пометить обработанным и забыть о нём. Но всё равно существует риск ошибки - расчётчик может ткнуть не туда, например, обработать все приказы массово,  из главного окна программы. И в табеле будут проставлены не те символы.

Получается, что данный "приказ №2" создаёт вероятность ошибки расчётчика, но полезной функции не несёт (по крайней мере, мы таковой не увидели).

В связи с чем возникают вопросы:

1. Зачем это сделано?
2. Нельзя ли сделать так, чтобы второй "приказ" в принципе не появлялся?

Спасибо.

Здравствуйте.

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

За 2 дня, пока "закрывали" июльскую зарплату, во входящих накопилось 6500 писем. Запустили на обработку. 20 минут - 40 писем. Т.е. ориентировочно процесс займет 54 часа...

Где и что можно посмотреть/почистить/настроить?

На всякий случай информация о системе: info.txt

Добрый день!
У клиента изначально настраивали прием 496 вида из КП как 101 в КЗ. Еще во время внедрения в прошлом году изменили настройки соответствия, теперь 496 = 104. Сейчас при обработке письма из КП о закрытии вида, в КЗ закрывается именно 101 вид. В чем может быть проблема и как это исправить, не подскажете?

Добрый день! Такая проблема: клиент скорее всего заново отправил все данные по исполняемым должностям из КП в КЗ. Из-за чего во входящих КЗ уже 10 000 писем (и их число только растет). КЗ не успевает их обрабатывать, а данных там очень много. Можно ли удалить все эти письма, и перевыслать только новые данные? И можно ли как-то отменить отправку писем?

Добрый день!
Как настроить соответствие источников финансирования в КП и КЗ?

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

И можно ли настроить, чтобы из приказа пособий до 3х лет, в зарплате открывался 205 вид расчет до 1,5 лет. Т.к. в кадровой службе отказываются формировать приказы до 1,5 лет, а формируют приказ сразу до 3х лет, обосновывая это законодательно. И в расчетном отделе вручную каждый раз открывают и рассчитывают 205 вид. А можно как-то настроить разбивку при обработке приказа до 3х лет при обработке в зарплате?

Добрый день

Подскажите, пожалуйста, как передать тип работы в КЗ из КП.

Поставили задачу по Контур-Зарплате. Вычислить заработок только по основной должности.

Настроена интеграция с КП. В КЗ с основной должности уже несколько раз переводили сотрудника.

Однако.

В КЗ у человека есть поле «Тип работы»

В КП вся нужная информация ведётся.

Совместительства отдельно, совмещения отдельно, основная должность тоже.

Вопрос в том, как быстро и массово передать «тип работы» через интеграцию.

Возможно, есть способ собрать НРЗ и выгрузить ID должностей, по которым установлено соответствие? Чтобы затем загрузить их файлом в КЗ.

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

На техподдержку КП тоже отписался.

Добрый день, уважаемые разработчики!

В Контур-Персонале приказ на БЛ создается для каждой исполняемой должности для правильного отражения его в табеле и учете влияния на периоды стажа, дающие право на дополнительный отпуск.

Раньше, даже если должностей 10 штук, приказ на БЛ приходил единый, предполагаю, что он сливался по датам и номеру БЛ.

В середине октября устанавливали сразу несколько релизов (в каком именно произошли изменения - теперь сказать трудно), до версии 601.1, и стало происходить следующее.

В ЛС приходят приказы на каждое совместительство. Они одинаковы, кроме кода исполняемой должности (видим его при просмотре XML), любой из них одинаково обрабатывается, на расчет подаются все равно сразу все совместительства.

В чем смысл таких изменений? Дублирующиеся приказы только сбивают с толку расчетчиков.

Хотелось бы вернуть обработку писем по БЛ в старом порядке, чтобы БЛ приходил один.