Ваши комментарии

Ну вот, я же говорил, что надо просто файлы с лицевыми копировать, а все "нет, так неправильно, нужно через прием-передачу". Вот и результат.

Уточнил еще раз проблему у расчетчика.

Новый б/л 910063290114 - это продолжение б/л 910063289906 (все эти б/л по данному сотруднику). Этот лицевой счет передавали другому расчетчику (в другой каталог RASCHET), сейчас вернули обратно. Выгрузка проводилась через Ctrl+F6, Ctrl+F7.

Я так понимаю, из-за того, что 910063289906 считался на другом рабочем месте, информация о нем осталась на другом компьютере,  т.к. каталоги RASCHET не связаны между собой. Вопрос только в том, как это исправить.

Игорь, мы делаем продление б/л №8, получаем эту ошибку. В реестре другого б/л с этим номером не нашел, только тот, что был у этого сотрудника с 14.02.20 по 12.03.20

Коллеги, помогите, пожалуйста, нужно срочно рассчитать б/л сотруднику.

Игорь, как тогда сделать? У нас у части сотрудников период с разрывами

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

Сам вид с алгоритмом 886 считает дни только из дат действия, из табеля не берет.

Попробовал разбить на два периода, но тогда это среднее лишается смысла, т.к. рассчитывает среднее за м-ц, а не за период действия. Как правильно настроить?

Добрый день! В продолжении темы можно спросить - как настроить, чтобы этот символ "Ф" учитывался как рабочее время? 

Подскажите, пожалуйста, а как добавить этот символ  Ф в табель?

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

Получил значение из 60 сетки выборкой:

По всем сотрудникам заполняет правильно:

Можно как-нибудь проверить NomSet в скрипте?



Сервис поддержки клиентов работает на платформе UserEcho