Добрый день, уважаемые коллеги и знатоки HR!
Позвольте обратиться к вам за советом.

Суть.
Создали собственный инфо-тип 90NN. Временная привязка 3 (инфо-тип может иметь пропуски и перекрытия).
Требования: записи должны быть уникальны с учетом полей стандартного ключа + трех собственных, т.е. Z-полей. Реализовали эту уникальность в программе ведения инфо-типа MP90NN00.
Поле SUBTY нет возможности задействовать, оно остается пустым.
Обратила внимание, что поле SEQNR при этом формируется корректно. Как известно, оно участвует в ключе. Но руководитель предостерегла, чтобы на это поле я особо не рассчитывала, мотивируя это тем, что SEQNR редко в каких инфо-типах можно использовать, иногда это использование приводит к неправильному результату. Действительно так?
Помимо ведения инфо-типа в транзакции PA30 по требованию заказчика разработана (пока не сдана) еще программа массового ввода данных в этот инфо-тип. В ней кроме вставки записей написана также процедура удаления записей. Также необходимо реализовать возможность массового изменения.

Внимание, вопрос!
С учетом такой нетривиальной реализации уникальности записей инфо-типа каким образом корректно будет добиться в стандартных процедурах удаления и обновления именно нужных записей (а не первых попавшихся или всех подряд)?
(Для удаления программист воспользовался ФМ HR_INFOTYPE_OPERATION с параметром operation = 'DEL').

Удаление - с условием where, накладываемым кроме стандартных полей также еще и на три Z-поля? Обновление – с предварительным удалением и последующей вставкой?
Или возможно задействование все же поля SEQNR , корректно ли это будет?

Благодарю.

Ну, опять же, что говорит нам сап доки по разработке инфотипов. SEQNR предназначено для нумерования записей инфотипа по одинаковым ключевым записям. Я его воспринимаю как версию записи инфотипа. Как типичный пример 0298 инфотипа когда в мероприятии мы его вставляем в параметром INSS (всегда новая запись). Поэтому какие могут быть проблемы с этим полем остается не понятным. Может ли Ваш руководитель привести конкретные примеры - при том что в стандарте в 0298 оно используется оочень активно и как всем известно проблем с этим ИТ нет ни у кого.

Почему нельзя было использовать стандарт для Z* инфотипа и включить для массовой обработки записей оного PA70/PA71?

Благодарю за разъяснения! Надо будет найти доки и почитать внимательно.
Пример был с инфо-типом "Отсутствия" - я не вникала, но мне сказали, что там были проблемы с SEQNR. После чего была выработано отношение к этому полю.


Как-то заведено так - нередко пишем сами программы массового ввода данных. PA70/PA71 настроены для некоторых ИТ, имеющих отношение к зарплате.
Но в основном, пишем собственные программы, они реализуют массу фишек. В частности, используют возможности ЛБД (удобно экономистам, отвечающим за свои подразделения), отображают доп. информацию по каждому (ФИО, должность, место работы), позволяют не вбивать таб.номера, а выбирать и отмечать нужные (нередко - все записи), переходить ("проваливаться", как у нас говорят) в другие транзакции, отображают уже имеющуюся информацию, на основе чего пользователь может принять решение о целесообразности ввода. И т.д.
Описываемый мной ИТ имеет ряд особенностей, в силу чего многое было специально обработано в программе.
Хотя, кое-что из этих возможностей, наверное, можно реализовать в PA70/PA71?

Документация по разработке инфотипов PA


Касаемо PA70,71 - суть ее простая, она запускае отчет на основе PNP который возвращает в нее список табельных номеров с которыми потом можно делать все что угодно. Если нужно вести там пользовательский инфотип то в MP9XXX00 должны быть реализованы специальные экраны для этих транзакций: 4000 ные для значений по умолчанию и 5000ные для полностью ручного ввода, как пример смотреть на примере MP029400.

А посокльку ИТ Z* то и сделать можно внутри них все что угодно

metha , благодарю Вас за поддержку! Вы столько раз приходили на помощь!
Обязательно гляну.
Позднее, по прочтении, я, возможно, задам еще вопросы.
К сожалению, временно приходится оставить эту задачу - перекидывают на другую, более срочную.
Просто проблемы с этой задачей все равно "загружены" уже в голове, мысленно продолжаю их решать.

Не очень понял вопрос.
В любом PA-инфотипе первичный ключ состоит из полей струкутры PAKEY. Ни больше, ни меньше. Z PAI-логика на ограничение ввода к первичному ключу отношения не имеет.
Если вопрос в том, можно ли создать две записи, у которых одинаковые PAKEY, но отличие в неких Z-полях, то так не получится.

Не ну, это понять можно. Ну вот такая у людей архитектура, PAKEY соблюдается, SEQNR формируется, но есть требование сделать дополнительными полями инфотипа тоже ключевыми. Это сделать можно только логикой, стандарт по этим ключевым полям ничего сделать не сможет, тем более что временная привязка = 3.

Извините, я неверно выразила свою мысль. Ключ, конечно же, PAKEY. Искусственно в программе MP90NN00 я добиваюсь того, чтобы нельзя было создать запись с идентичными значениями PAKEY (кроме SEQNR, его я не рассматриваю вообще, нам так и нужно) + значениями еще трех полей, назовем их условно ZF1, ZF2, ZF3.

(Чтобы стало понятнее: требуется, чтобы у одного таб.номера в течение временного периода можно было ввести только одну запись с определенным набором значений полей ZF1 ZF2 ZF3.
Т.е. нельзя создать еще одну запись с идентичными значениями этой тройки полей ZF1 ZF2 ZF3.
Независимо от того, что SEQNR у них разный!)

Когда я писала первый пост, отталкивалась от предположения, что SEQNR у всех записей должен быть пустым.
Вот и задумалась - а как же тогда пакетный ввод определит, какую именно запись необходимо изменить\удалить.
Но благодаря metha утвердилась в мысли, что именно благодаря полю SEQNR в случаях, подобных моему, а еще в ИТ 0298, достигается уникальная идентификация.
Естественно, теперь все встаёт на свои места.


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

metha, спасибо, все верно!

Уууу.... пакетный ввод тут то все просто. Когда пишете пакетник то в PA30 транзакции появляются дополнительные поля для однозначного определения изменяемой записи и для этого ничего писать в Z* не надо. Дополнительными полями для идентификации в пакетнике явлеются помимо SEQNR еще и OBJPS

точнее - ФМ HR_INFOTYPE_OPERATION.
Ну в пакетнике-то - да, а при вводе данных? А, ну да, тогда в той же программе MP90NN00 можно и значения этих полей определять тоже.
Впрочем, стандарт с SEQNR и без меня справился.

При создании ИТ не было таких далеко идущих планов.
Все повылезало, когда выяснилось, что данных понадобится вводить чересчур много для простого ведения, и потребуется массовый ввод. Вот тут-то многие вопросы и возникли.
А требования по поводу ключа пользователь выразил на этапе тестирования и сдачи инфо-типа, а не во время написания ТЗ. Дописала просто обработку.

Скажу уж тогда прямо еще одну вещь - инфо-тип создавала впервые , по документации, в жутко горящие сроки.
Про SEQNR, видимо, пропустила.

Коллеги, а вот такой вопросик под новый год.
Существует ли способ в пакетном вводе узнать SEQNR созданной записи? Мне кажется, что никак нельзя. Но очень хочется

При записи пакетного ввода, в PA30 на главном экране появляются внизу экрана поля в группе полей "Другие ограничения": два из них это OBJPS и SEQNR, если эти поля заполнены, то PA30 возьмет на редактирование записи строго соответствии с этими ограничениями.

Эти поля в батчинпуте сохраняются в RP50G-SEQNR.

Это мы можем указать, какую запись редактировать/удалять/блокировать.

А мне надо узнать, какую запись я создал в пекетнике.

Это да, никак не узнать , а для чего это надо? Типа эмуляция динамики?