Метод IN_UPDATE

Dronx

Граждане, товарищи!
Кто-нибудь может подсказать, где собака порылась?
В Бизнес-Add Ins\Z_PA_UPDATE
в методе IN_UPDATE отлавливаю событие на изменение ИТ0082.
При этом мне необходимо прицепом сделать изменения в связанном ИТ2001:

Code:

  IF ipspar-infty = '0082'.
... 
    IF i0082-subty = '....' AND ( ipspar-actio = 'MOD' OR ipspar-actio = 'LIS1' ).
...
        CALL FUNCTION 'HR_INFOTYPE_OPERATION'
          EXPORTING
            infty         = ls_pskey-infty
            number        = ls_pskey-pernr
            subtype       = ls_pskey-subty
            objectid      = ls_pskey-objps
            lockindicator = ls_pskey-sprps
            validityend   = ls_pskey-endda
            validitybegin = ls_pskey-begda
            recordnumber  = ls_pskey-seqnr
            record        = wa2001
            operation     = 'MOD'
            tclas         = 'A'
            dialog_mode   = '0'
*            NOCOMMIT      =
*     VIEW_IDENTIFIER      =
*     SECONDARY_RECORD     =
          IMPORTING
            return        = return.

HR_INFOTYPE_OPERATION отрабатывает без ошибок.

Прелести начинаются потом.
Вываливаемся в диалог "Изменить отсутсвия" и
выскакивает сообщение: «Запись, предназначенная для удаления, не найдена».
Для какого удаления?!...
Естественно, нужных нам автоматических изменений не проиходит.
Получается, где-то сорим.

Кто-нибудь сталкивался с такой неприятностью? Как ее побороть?
(В динамических мероприятиях вроде ничего особенного нет)
:?:

Сергей Королев

Dronx написал(а):

Кто-нибудь сталкивался с такой неприятностью? Как ее побороть?
(В динамических мероприятиях вроде ничего особенного нет)
:?:

HR_INFOTYPE_OPERATION не надо использовать, я так понимаю, в результате получается некорректный рекурсивный вызов и портится буфер обновления инфотипов. Вариант - работать напрямую с этим буфером подпрограммами из SAPFP50P - INSERT_INFOTYP, UPDATE_INFOTYP, DELETE_INFOTYP.

Dronx

Спасибо!
Сейчас глянем.

Dronx

Сергей Королев написал:

Dronx написал(а):

Кто-нибудь сталкивался с такой неприятностью? Как ее побороть?
(В динамических мероприятиях вроде ничего особенного нет)
:?:

HR_INFOTYPE_OPERATION не надо использовать, я так понимаю, в результате получается некорректный рекурсивный вызов и портится буфер обновления инфотипов. Вариант - работать напрямую с этим буфером подпрограммами из SAPFP50P - INSERT_INFOTYP, UPDATE_INFOTYP, DELETE_INFOTYP.

Передаю UPDATE_INFOTYP в параметр изменяемую запись, но почему-то UPDATE не происходит. Ошибок тоже нет. Странно...

Сергей Королев

Dronx написал(а):

Передаю UPDATE_INFOTYP в параметр изменяемую запись, но почему-то UPDATE не происходит. Ошибок тоже нет. Странно...

Надо в отладке поглядеть, меняется ли буфер...

Dronx

Сергей Королев написал:

Надо в отладке поглядеть, меняется ли буфер...

Кстати, обновляется,... но при определенных стечениях обстоятельств.
Осталось разобраться - поискать, где мусорок закрался.
Спасибо БОЛЬШОЕ, Сергей!

Dronx

Сергей Королев написал:

Dronx написал(а):

Передаю UPDATE_INFOTYP в параметр изменяемую запись, но почему-то UPDATE не происходит. Ошибок тоже нет. Странно...

Надо в отладке поглядеть, меняется ли буфер...

Происходит следующее:
При первой записи ИТ0082 не происходит одновременной записи в ИТ2001(проверено в журнале изменений). Если повторно войти в режим редактирования ИТ0082 и попытаться сохранить, то все проходит нормально.

Как бы заставить проапдейтить ИТ2001 за первый заход?

Dronx

Граждане, может кто подскажет, как заCOMMITить IN_UPDATE?

kizif

Можно попробовать очистить буфер ФМ: 'HR_PSBUFFER_INITIALIZE' .

Dronx

kizif написал(а):

Можно попробовать очистить буфер ФМ: 'HR_PSBUFFER_INITIALIZE' .

Спасибо!
Но, к сожалению, не помогло.
Странно это все...

Dronx

Может есть еще какие идейки? Или что-то держит, или чего-то не хватает...

Bully

ИМХО принципиально не правильный подход.

Ты посмотри в каком месте стандарт вызывает IN_UPDATE и все ясно станет.

Я бы поставленную задачу решил на уровне динамических мероприятий.

Galka

и никак через IN_UPDATE нельзя подменить значения? только динамика?
задача стоит так - переделать мою красивую прожку из динамики в IN_UPDATE и всё тут. Хотя смотрю я по дебагеру, уже и CPREL поменяла, и p0015, но, кажется, данные уже записались к моменту, когда вызывается IN_UPDATE.
Есть шансы поменять поля вызывающего инфотипа из IN_UPDATE или нереально?

Leonnn

Добрый день,

Помогите пожалуйста, может было нечто похожее, я прямым insert-ом (система 4.6) формирую продление отсутствий, в случае разрыва отпусков, при этом количества затребованных дней и остатков в ит0005 не изменяется, а если мы зайдем в созданные записи на изменение и сохраним то 0005 ит изменится, как програмно можно обойти данный этап???

Rocktrooper

может кому будет полезно. Просто стояла похожая проблема, реализацию подглядел в стандартном классе.
CL_IM_HR_NL_EIR_IT3250
метод => IF_EX_HRPAD00INFTY~IN_UPDATE

если в кратце:

PERFORM insert_infotyp IN PROGRAM sapfp50p USING
ls_0027
lv_insert_check
gc_it_no
lv_msgtp
lv_error_flag
gc_it_no.

PERFORM put_infotyp_buffer IN PROGRAM sapfp50p.
У меня все работает, ошибок не возникало.

Правила форума

Метод IN_UPDATE

Кто сейчас на конференции