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

Может кто сталкивался с такой проблемой в системе. Ситуация следующая - при создании продуктивного прогона табельный номер не включается. Когда делаем только на него одного Р прогон, выходит сообщение "Результат расчета уже проанализирован в ходе прогона 0000002409".
Смотрю №прогона - это прогон прошлого периода (прошлый год!).

Добрый день, Ваш прогон *2409 уже выполнен? Можете его удалить?

Это же продуктивный прогон. Мы не можем его удалить.

Документы в этом прогоне в каком статусе?

Документы деблокированы, проведены в FI.

Коллеги,

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

Возможно какая-то путаница в нумерации результатов расчета? Может кто-то вручную правил?
Посмотрите, нет ли в PCALAC для старого прогона номера нового результата расчета.

В PCALAC новые результаты расчета стоят под старым прогоном *2409. Вручную не могли править, т.к. в продуктиве мы ничего не редактируем.
А как теперь быть? В прошлом периоде (май) бухгалтеры провели суммы по этому табельному ручками в FI.

И еще такой момент-
1) в PC_PAYRESULT идет следующая последовательность:
75 - май
76- июнь

2) в PCALAC идет так:

75 PP 2409
76 PP 2409
77 PP 2409 - что это?

Я правильно понимаю, что здесь надо удалить №77? А что делать с №75 (май)? Ведь прогон мая пошел без этого тн. Тоже удалить запись или оставить так?

Почистила таблицу ручками.
Только как можно объяснить создание этих некорректных записей в таблице?

Добрый день!
Может Z??? Стандартно, система не должна себя так вести, если конечно кластер зп не редактировать Z-ом
Гуру поправьте, если я не прав.

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

ну хотя бы вот так:

Не, rpudir00 PCALAC вроде бы не трогает. Если только как-то через стек вызовов из 20 ФМов.

calm ясно, я так понимаю, это при удалении расчета он не удаляется ото всюду. Но тогда одной pcalac не отделаться, наверное