Добрый день.

Ситуация такая, генерация лимитов через отчет HTUTQTA0 проходит около 4-5 суток, это производство численность 36 000 чел. с разными условиями труда от которых зависят лимиты отсутствий так же есть различные ограничения лимитов т.е. в сумме лимиты не должны превышать к примеру 42/66к.д.
так же есть многосменный режим работы и есть лимит за многосменность который приходит из оценки времени т.к. завязка на ИТ7 и атрибуты.
так как на производстве проходят ежедневные переводы с штатки на штатку или перевод с одного ГРВ на другой в связи с этим есть необходимость генерировать лимиты ежедневно, но она не проходит за ночь проходит 4-5суток.

вопрос: подскажите кто нибудь сталкивался с этим? и как можно оптимизировать генерацию лимитов с помощью HTUTQTA0?

Заранее спасибо .

если честно, этого отчета у нас в системе нет, но все-таки из общих рекомендаций:
1) запустить его под пользователем с sap_all и/или индексированными полномочиями
2) распараллелить запускаемый отчет: программа RPCS0000, там указываете отчет, который нужно распараллелить (HTUTQTA0 в вашем случае, будет выполняться в фоне), и вариант с которым его запустить. Указываете число заданий (максимум заданий в конкретной системе разный, лучше узнать у базиса, ну или кто из форумчан подскажет в этой теме). Отчет, в принципе, можно запланировать.

Добрый день.

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

Наверное речь идет об отчете RPTQTA00?
В порядке бреда, можно попробовать создать свой Z отчет, в котором вызывать Вашу программу, предварительно сделав выборку по людям, которым делались переводы. Ведь не все 36000 каждый день переводятся.
При вызове можно и распаралелить, и так же в фоне запускать...

Добрый день.

такой вариант у нас и был. Мы написала свой z отчет, в котором он делал проверку ИТ + мероприятия которые влияют на лимиты отсутствий. Затем отчет собирал количество людей и передавал уже в HTUTQTA0 (именно этим отчетом мы пользуемся). Но ситуация такая что у них есть многосменный режим работы соответсвенно есть и лимиты за многосменность т.е. данные лимиты формируются через оценку т.к. он нарастает каждый день, а в лимитах есть ограничения 66 к.д. для этого мы сделали расширения в котором он сокращает осн.отпус на массу многосменки чтоб не вылетело за пределы ограничения.
и число таких людей составляет 16 000.

потом это все распаралели и нифига не получается( генерация проходит 2 суток.

что делать? проблема(

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

И у меня , например, нет отчета HTUTQTA0, а есть отчет HRUTQTA0, или это что-то специфическое для страны ?

упс, это я по запарке опечатку допустила сорри. отчет HRUTQTA0.
у нас в оценке итак настроено, лимит за многосменность не более 2 или 4 дней.

Допустим сотруднику полагается отпуска не боле 66 дней, в это кол-во входит вред-18 дней, ненормированность -21, осн.отп-24 и многосменка-4дня.
общая сумма превышает ограничения 66.
Для этого нам нужно сократить лимиты, но не трогая многосменку, т.к. если человек отработал по многосменному режиму то ему эти дни в любом случае полагаются. для этого мы сокращаем осн.отп т.к. в генерации лимитов он обрабатывается последним.

При выполнении мероприятия с изменением 0001 и 0007 в инфо-группу генерация лимитов по этому работнику не пробовали добавлять? Это может убрать необходимость ежедневной генерации по всем работникам.
Сталкивались с подобным, но время измерялось часами, решилось отключением всех проверок полномочий прямо в коде - ускорение было в разы.

Приветик.

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

спасибо.
Алина.

Я так понимаю считывание ИТ1222 производится в своей z-разработке. Попробуйте добавить сброс буфера через HR_INITIALIZE_BUFFER перед считыванием ИТ1222.
1640701 - 0HR_PA_BN_1 dumps with TSV_TNEW_OCCURS_NO_ROLL_MEMORY.