Имеется инфонабор на основе логической базы PNP или PNPCE. Среди стандартно определенных полей есть, для примера, поле «Дата поступления на работы» - SYHR_A_P0000_AF_HIREDATE («прицеплено» к ИТ0000). Проблема с этим полем в том, что оно работает только если мероприятие приема попадает в период анализа отчета. То есть, если период анализа будет стоять, например, «сегодня», это поле останется пустым.
Это происходит из-за того, что отчет отбрасывает все записи загруженных ИТ, которые не попадают в период анализа. В данном случае в итоговом отчете встречается следующая строчка


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

Мне, конечно, не сложно определить собственное поле «Дата поступления на работы» с собственной обработкой, которая бы не зависела от периода анализа отчета. Но хотелось бы знать, может быть есть какой-нибудь способ управления работой подобных полей?
Или у нас просто что-то не так работает? Не хочу писать лишний код из-за того, что у нас где-то что-то неправильно настроено.

В данном конкретном случае советую забить. Т.к. эта штука всё равно будет косячить на увольнениях/приемах след.днем без изменения статуса.

Стал лазить отладчиком. Вообще хрень какая-то получается, если честно.
Отчет вызывает ФМ RPAQ_GET_AF_0000. В этом ФМ есть отдельная секция для определения даты приема. Первым делом идут такие строчки:

то есть, обрабатывается вариант, когда анализируемый период равен одному дню. Видно, что значение переменных enter_begda и enter_endda становятся равным.
Далее вызывается ФМ HR_ENTRY_DATE с параметрами даты enter_begda - enter_endda.

который по сути является обертышем для ФМ HR_ENTRY_DATE_CALC.
В ФМ HR_ENTRY_DATE_CALC зачитываются и обрабатываются периоды из ИТ 0000,0001,0041, при этом формируются две таблицы date и entry_dates, в которые попадают периоды работы. В этих таблицах только одно поле даты – начала периода. Для самого простого случая (сотрудник принят и работает) там будет одна запись с даты приема.
Далее идут 4 интересные строки

begda и endda, напомню, равны. Значит эти строки просто очистят таблицы, если только период анализа не равен дате приема сотрудника. Ну а дальше

Приехали, называется.
В se37 запускаю HR_ENTRY_DATE_CALC на тестирование для любого ТН с равными begda-ennda, естественно всегда получаю entry_date_not_found.
Что еще удивляет, вроде простое действие - определить дату према, а там весь код в исправления. САП долго и упорно переписывает этот кусок, а он все равно не работает

Ну и не будет он работать в наших условиях. У нас есть FM
HR_RU_HIRE_DATE
HR_RU_HIRE_FIRE
HR_RU_HIRE_FIRE_DATES
на их основе и сделайте свое поле. А стандартные вычисляемые лучше вообще выкинуть, проку от них чуть, только юзеров смущать

Просто ради интереса - а что, в дальнем забугорье какие-то особые условия? Ведение даты приема как-то приципиально отличается?

T7RU530 тогда для чего? ) Насколько я помню, больше нигде нет увольнения без изменения статуса занятости

проблема увольнения и приема следующим днем легко лечится в FMах HR_ENTRY/LEAVE_DATES глобально через бади парой сточек кода.
причем работает это практически врезде в отличии от русского стандарта.

проводил сравнительное тестирования стандартные:
HR_RU_HIRE_DATE
HR_RU_FIRE_DATE
HR_RU_HIRE_FIRE_DATES

жутко медлено работают по сравнению с той же группой модулей 99ой, просто кошмар, это будет заметно например в квери когда FM будет вызываться много раз...

теперь немного по теме
если стандартном поле действительно используются даты выбора(хотя я насколько помню там только проблема если запускать отчет на 1 дату, если хотя бы на интервале в 2 дня то уже все нормально, системы нет под рукой завтра гляну если не забуду), то, просто создайте поле свое которое будет возвращать ближайшую к ключевой дате дату приема или увольнения, можно использовать стандартные функции по типу HR_RU_HIRE/FIRE_DATE или HR_ENTRY/LEAVE_DATES передавая в них BEGDA = 18000101 и ENDDA = концу периода сбора данных/табельных, например

Я сделал запрос с SAP с описанием этой проблемы. Как ни странно, в их ответе нашлось и решение. Нота 562031 исправляет ситуацию – просто удаляется белиберда, которая была внесена предыдущими нотами.
Если внимательно «курить» исходники и ноты, которые вносили исправления в них, то видна история. Сначала была проблема с вычислением датой увольнения, по этому поводу была одна или две ноты. За одно аналогичные изменения внесли в секцию вычисления даты приема, тем самым внеся ошибку. Нота 562031 отменяет эти изменения.

Я принципиально не стал делать свое вычисляемое поле. У нас несколько рабочих инфонаборов, не факт, что не появятся новые, за всеми не уследишь. Потом я посмотрел журнал использования, эти ФМ используется и в других отчетах и программах. Лучше уж badi написать. Но сейчас я в случае явных косяков со стороны САПа делаю Report Error. Даже если косяк легко обходиться.

А работают медленно эти ФМ из-за того, что они полностью считывают ИТ 0000, 0001, 0016 и 0041.

Медлено работают именно HR_RU* по сравнению с HR_ENTRY/LEAVING_DATE

к HR_ENTRY/LEAVING_DATE нет нареканий, хоть и считывают все (там идет буферизация все равно)