ФМ для обновления VBRK

sy-uname

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

Если смотреть в Debug, то все нормально... На выходе из OPEN-FI в таблице VBRK (se11) все заполнено. Но потом все равно поле обнуляется

Очень, очень похоже на то, про что говорил sibrin
- надо искать кто ещё может изменять VBRK - включите трассировку и проанализируйте результат.

sibrin

sy-uname написал(а):

надо искать кто ещё может изменять VBRK - включите трассировку и проанализируйте результат.

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

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

Фактура блокирована и в OPEN-FI она тоже блокирована. Поэтому и использую дополнение IN UPDATE TASK.

Поймите, не могут два параллельных процесса изменять один и тот же документ. Результаты того процесса, который завершается первым, затираются вторым. Для того и созданы блокировки. Их нужно использовать, а не пытаться обойти.

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

К тому же в OPEN-FI не могу делать COMMIT WORK.

И не надо. Изменять vbrk нужно в рамках LUW. Можно экспортировать номер документа в глобальную память, а потом в каком-нибудь экзите, в котором vbrk доступна на изменение записать в z-поле.
Или воспользоваться грязным хаком — assign'ом в глобальную область вызывающей программы.

__Gennady

У меня была похожая ситуация. Хотелось апдейтить поле в bseg при проводке, но вот незадача: в одних расширениях belnr еще не был присвоен, а в других данные затирались. Вот какое нашлось решение.

Code:

FUNCTION z_xref3_00001050.
*"----------------------------------------------------------------------
*"*"Локальный интерфейс:
*"  IMPORTING
*"     VALUE(I_XVBUP) LIKE  OFIWA-XVBUP DEFAULT 'X'
*"  TABLES
*"      T_BKP1 STRUCTURE  BKP1
*"      T_BKPF STRUCTURE  BKPF
*"      T_BSEC STRUCTURE  BSEC
*"      T_BSED STRUCTURE  BSED
*"      T_BSEG STRUCTURE  BSEG
*"      T_BSET STRUCTURE  BSET
*"      T_BSEU STRUCTURE  BSEU
*"----------------------------------------------------------------------

  DATA: bukrs TYPE bukrs.
  DATA: belnr TYPE belnr_d.
  DATA: gjahr TYPE gjahr.
  DATA: bktxt TYPE bkpf-bktxt.

  bukrs = t_bkpf-bukrs.

    CHECK belnr IS NOT INITIAL AND gjahr IS NOT INITIAL.
*-- запускаем функцию, которая определит pid текущего процесса и запустит
*-- программу, одидающую его завершения
    CALL FUNCTION 'ZUSER_FM_PREPARE'
      IN UPDATE TASK
      EXPORTING
        bukrs = bukrs
        belnr = belnr
        gjahr = gjahr
        bktxt = bktxt.
  ENDIF.
ENDFUNCTION.

FUNCTION zuser_fm_prepare.
*"----------------------------------------------------------------------
*"*"Функциональный модуль обновления:
*"
*"*"Локальный интерфейс:
*"  IMPORTING
*"     VALUE(BUKRS) TYPE  BUKRS
*"     VALUE(BELNR) TYPE  BELNR_D
*"     VALUE(GJAHR) TYPE  GJAHR
*"     VALUE(BKTXT) TYPE  BKTXT
*"----------------------------------------------------------------------

  DATA: lt_wpinfo TYPE TABLE OF wpinfo,
        ls_wpinfo TYPE wpinfo,
        subrc TYPE sy-subrc.


* получить process id
  CALL FUNCTION 'TH_GET_OWN_WP_NO'
    IMPORTING
      subrc    = subrc
      wp_no    = ls_wpinfo-wp_no
      wp_pid   = ls_wpinfo-wp_pid
      wp_index = ls_wpinfo-wp_index
    EXCEPTIONS
      OTHERS   = 1.
  IF sy-subrc EQ 0 AND subrc EQ 0 AND
     NOT ls_wpinfo-wp_pid IS INITIAL.

    APPEND ls_wpinfo TO lt_wpinfo.

    CALL FUNCTION 'ZUSER_FM_SET'  "вызов модуля в другом диалог окне
      STARTING NEW TASK 'USER_FM'
      DESTINATION 'NONE'
      EXPORTING
        bukrs  = bukrs
        belnr  = belnr
        gjahr  = gjahr
        bktxt  = bktxt
       TABLES
        t_wpinfo = lt_wpinfo.
    .
  ENDIF.
ENDFUNCTION.

FUNCTION zuser_fm_set.
*"----------------------------------------------------------------------
*"*"Локальный интерфейс:
*"  IMPORTING
*"     VALUE(BUKRS) TYPE  BUKRS
*"     VALUE(BELNR) TYPE  BELNR_D
*"     VALUE(GJAHR) TYPE  GJAHR
*"     VALUE(BKTXT) TYPE  BKTXT
*"  TABLES
*"      T_WPINFO STRUCTURE  WPINFO
*"----------------------------------------------------------------------
  DATA: ls_wpinfo TYPE wpinfo,
        wplist LIKE wpinfo OCCURS 0 WITH HEADER LINE,
        ls_mkpf TYPE mkpf,
        lt_mseg TYPE TABLE OF mseg,
        ls_mseg TYPE mseg,
        done(1) TYPE c.
  DATA: mode_call(1).     "работа по вызову

  LOOP AT t_wpinfo INTO ls_wpinfo.
    EXIT.
  ENDLOOP.

*-- ожидание завершения предыдущего процесса
  WHILE done IS INITIAL.
    REFRESH wplist.
    CALL FUNCTION 'TH_WPINFO'
      TABLES
        wplist     = wplist
      EXCEPTIONS
        send_error = 1
        OTHERS     = 2.
    READ TABLE wplist WITH KEY wp_pid   = ls_wpinfo-wp_pid
                                 wp_mandt = sy-mandt.
    IF wplist-wp_istatus = 2 OR sy-subrc <> 0.
      ls_wpinfo-wp_pid = sy-subrc.
      done = 'X'.                   "процесс завершен
    ENDIF.
  ENDWHILE.

  CALL FUNCTION 'ZFB02BATCH_INPUT'
    EXPORTING
      bukrs = bukrs
      belnr = belnr
      gjahr = gjahr
      bktxt = bktxt.

ENDFUNCTION.

Vadim

Спасибо за пример, надо будет попробовать.
Но... Цель состоит в том, чтобы не только создать дополнительный документ и записать его в поле VBRK-ZZBELNR_D, но еще если не создался дополнительный документ, то и первый документ не надо создавать.

vga

Геннадий, а Вы не искали, сам SAP что-либо подобное использует для обновления в финансовых документах?
Скорей всего, для описанного случая Ваш вариант не сработает, я склоняюсь к варианту sibrin, но при другом использовании насколько такая технология допустима с точки зрения обработки ошибок и целосности данных?

__Gennady

В свое время мне этот метод тоже подсказали, как крайний вариант, когда не найдено более подходящих расширений. Мной проверено, работает, все сохраняется. Единственное, я использовал не BAPI а пакетник. Искать где используется подобное я не пробовал, ФМ 'TH_GET_OWN_WP_NO' используется мало где (в ERP2005 39 раз).

sibrin

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

Но... Цель состоит в том, чтобы не только создать дополнительный документ и записать его в поле VBRK-ZZBELNR_D, но еще если не создался дополнительный документ, то и первый документ не надо создавать.

Так какие проблемы-то. Документ создаёте в отдельном процессе и ждёте его в open fi и получаете его номер. Если номера нет — ошибка. А дальше записываете VBRK-ZZBELNR_D в том же LUW вместе со всей фактурой.

sibrin

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

В свое время мне этот метод тоже подсказали, как крайний вариант

Цикл ожидания "грузит" процесс: нужно wait up to 1 seconds вставить.

Ещё одно решение, как подождать окончания update-процесса, приведено здесь: http://sapboard.ru/forum/viewtopic.php?t=15449.

Интересно, какое из этих двух лучше?

vga

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

Фактура блокирована и в OPEN-FI она тоже блокирована. Поэтому и использую дополнение IN UPDATE TASK.
К тому же в OPEN-FI не могу делать COMMIT WORK.
Да и еще раз говорю, без WAIT UNTIL... все работает. Но надо знать результат выполнения BAPI

Пораскинув мозгам на досуге, пришел к выводу, что без WAIT UNTIL работает потому, что вам просто повезло, что асинхронный процесс выполнялся дольше, чем основной, поэтому vbrk сначала обновил первый процесс, потом асинхронный. В случае синхронизации двух сессией все произошло наоборот. Поэтому, даже без WAIT UNTIL реализация не корректна. Самый правильный вариант, который предлагает sibrin.

Vadim

Спасибо!! Это я уже тоже понял!!! Но все равно спасибо!!! Будем пробовать!!!

Vadim

sibrin написал:

Так какие проблемы-то. Документ создаёте в отдельном процессе и ждёте его в open fi и получаете его номер. Если номера нет — ошибка. А дальше записываете VBRK-ZZBELNR_D в том же LUW вместе со всей фактурой.

То есть выполнить обновление VBRK-ZZBELNR_D в том же OPEN-FI после завершения дополнительного процесса?? Или же обновлять уже где-нибудь в USER-EXIT ???

sibrin

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

То есть выполнить обновление VBRK-ZZBELNR_D в том же OPEN-FI после завершения дополнительного процесса?? Или же обновлять уже где-нибудь в USER-EXIT ???

Не совсем. Самому update делать не надо. Нужно найти момент времени и цель, в которую в которой можно записать поле ZZBELNR_D.

Моментом может быть open fi, а целью - структура из глобальной области программ ниже по стеку вызвов (она может называеться xvbrk, например), которая изменяется при помощи assign.

Можно использовать законный юзер-экзит или бади для изменения заголовка фактуры, которые вызываются после open fi. Например, BADI_SD_BILLING~INVOICE_CHANGE_POST. Цель здесь - параметр FXVBRK этой бади.

Или не очень законные экзиты в момент после open fi, в которых опять же использовать assign.

vga

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

То есть выполнить обновление VBRK-ZZBELNR_D в том же OPEN-FI после завершения дополнительного процесса?? Или же обновлять уже где-нибудь в USER-EXIT ???

Если Вы не хотите "извратнуться" и написать асинхронный ФМ,
запускаемый после успешного создания фин. документа прямо в open-fi, который будет ожидать снятие блокировки с VBRK и только после этого делать Update VBRK ;-)

то конечно, искать нужный exit.

Vadim

sibrin написал:

Можно использовать законный юзер-экзит или бади для изменения заголовка фактуры, которые вызываются после open fi. Например, BADI_SD_BILLING~INVOICE_CHANGE_POST.

Спасибо!!! Но... Ведь все уже передано в FI, и после этого уже нет никаких USER-EXITов и т.п. Они уже все отработали. Или я не прав?

Vadim

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

Если Вы не хотите "извратнуться" и написать асинхронный ФМ,
запускаемый после успешного создания фин. документа прямо в open-fi, который будет ожидать снятие блокировки с VBRK и только после этого делать Update VBRK ;-)

то конечно, искать нужный exit.

В OPEN-FI запись в VBRK блокирована с самого начала и до конца.

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

ФМ для обновления VBRK

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