Добрый день,

хочу удалить актуальный результат расчета, но система выдает такую ошибку "Нет записи в таблице T549Q для аргумента 00".
Смотрю таблицу, там у нас параметр периода 01-ежемесячно, определено до конца 2017. Что за аргумент 00 не понятно
Может кто сталкивался с такой ошибкой?

У вас не с T549Q что-то не в порядке, а с ТН или с расчетом по ТН, который вы удаляете. Вот Вы пишите - у нас параметр периода 01. А как система, работая с результатом расчета конкретного ТН, должна узнать, что у Вас модификатор периода 01?

В выполненном результате расчета хранится модификатор периода, за которой выполнен расчет (в каталоге расчете поля PERMO и IPERM). Если вдруг результат расчета у вас какой-то "битый", внутренние структуры не заполнены, то вполне возможно появление такой ошибки. Считав такой результат, программа воспринимает пустое значение за модификатор 00, а далее обнаруживает, что настроек для этого модификатора не хватает.

Спасибо за ответ, только я не поняла момент, как понять, что результат расчета "битый"? И каким образом можно теперь удалить этот расчет?

P.S. Я РУ не настраивала, поэтому не знаю его "глубину"

Обратитесь к АБАР-у. Он точнее скажет, где, что не заполнено. Возможно, он сможет и обойти эту ошибку для удаления расчета.

Хорошо, спасибо!

Коллеги, добрый день.

Подниму тему.
Удалось у вас совладать с данной ошибкой?

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

Здравствуйте. Миграция нас давно миновала:) Вот как раз в таблице VERSC стоит параметр периода 00, вместо 01, о чем писалось выше. Из-за этого удалить расчет не могу. И не могу никак обойти эту ошибку.

Вариант 1. Сделать утилиту, которая исправить неправильно заполненные атрибуты в результатах расчета. Потому удалить.
Вариант 2. В T549Q сделать необходимые настройки для модификатора 00. По крайней мере ошибки типа "Нет записи в таблице T549Q для аргумента 00" не будет. Затем ненужные настройки можно удалить.

Месяц в котором этот 00 вместо 01 - это расчитанная драйвером запись или это все таки загруженные исторические данные?
Исправьте это значение на 01 в VERSC и все пройдет.

Рассчитанная драйвером. А не подскажете, пожалуйста, как мне это исправить?

Это хуже, значит проблема массовая, это не единичный случай?

Если проблему рожает драйвер расчета как следствие настроек - то и исправлять настойку нужно. Проверьте настройки spro->payroll:russia->basic settings->payroll organization.
Если бы это были не верные исторические данные - тогда проще всего было бы разово поправить записи утилитами по коррекции кластера.

Это хуже, значит проблема массовая, это не единичный случай?

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

Настройки посмотрю. Спасибо!