KamiCATze написал(а):
P.S. пока писал ответ, куда то сообщение RoustR пропало(
Я написал, но затем понял, что в моем описании есть проблемы, поэтому удалил сообщение, пока не исправлю. Сегодня дополнил.
KamiCATze написал(а):
@RoustR, а Вы случаем с таблицей T51P6 не сталкивались? Есть там интересный функционал, как приоритеты и алгоритм действий в случае, если дохода для удержания не хватает.
Например, алгоритм "1", когда независимо, хватает ли дохода перекрыть долг работодателя или не хватает, алименты удерживаются в любом случае.
Но пока не пойму, какими подводными камнями может это все аукнуться.
С T51P6 сталкивался конечно. Это обязательная для настройки RUPRI таблица. Без нее RUPRI работать не будет. И приоритеты в T51P6 должны быть аналогичны приоритетам в V_T7RUD1-V_T7RUD3, иначе фигня будет.
Для T51P6-Просрочка = 1 подводный камень такой. RUPRI - это RU-надстойка для международной PRPRI. RUPRI составляет план удержаний по таблицам V_T7RUD1-V_T7RUD3, затем ядро от PRPRI выполняет сокращение согласно плану с учетом таблицы T51P6. Так вот, при составлении плана RUPRI не проверяет значение T51P6-Просрочка = 1 (то есть, ВО не может быть сокращен), и составляет план так, как будто ВО сокращается. Это значит что план для ВО, с приоритетом ниже, чем у ВО Просрочка = 1, будет составлен из расчета что денег было оставлено чуть больше, чем на реально осталось.
Ядро PRPRI работает с обработкой T51P6-Просрочка = 1, план сокращения летит к черту, цикл блок обработки удержаний зацикливается, пока ВО, с приоритетом ниже, чем у ВО Просрочка = 1, не будут сокращены полностью. Если это случится позднее, чем за 1000 итераций, то выскочит ошибка превышено число итераций цикла. В такой ситуации ТН будет считать очень долго.
Я дорабатывал блок составления плана сокращений на предмет анализа значения T51P6-Просрочка = 1.