Когда вызывается ФМ, если он IN BACKGROUND TASK?

Вызывается он после завершения UPDATE процессов (CAL FUNCTION ... IN UPDATE TASK). И вот доказательство.
Создаем вот такую табличку:


Создаем вот такой ФМ типа RFC:

FUNCTION zfm_krs_test_bg.
*"--------------------------------------------------------------------
*"*"Локальный интерфейс:
*"  IMPORTING
*"     VALUE(ID) TYPE  CHAR10
*"--------------------------------------------------------------------
  DATA ls_data TYPE zkrs_test_bgto.

  ls_data-id = id.

  GET TIME STAMP FIELD ls_data-tst.

  MODIFY zkrs_test_bgto FROM ls_data.
  COMMIT WORK.

ENDFUNCTION.

Еще один типа UPDATE TASK немедленного запуска (обратите внимание что в нем еще раз запускается BG-ФМ со своим ID):

FUNCTION zfm_krs_test_upd.
*"----------------------------------------------------------------------
*"*"Функциональный модуль обновления:
*"
*"*"Локальный интерфейс:
*"  IMPORTING
*"     VALUE(ID) TYPE  CHAR10
*"     VALUE(IV_WAIT) TYPE  INT4 DEFAULT 5
*"----------------------------------------------------------------------
  DATA ls_data TYPE zkrs_test_bgto.

  ls_data-id = id.

  WAIT UP TO iv_wait SECONDS.

  GET TIME STAMP FIELD ls_data-tst.


  MODIFY zkrs_test_bgto FROM ls_data.

  ls_data-id = |BG{ id }|.

  CALL FUNCTION 'ZFM_KRS_TEST_BG'
    IN BACKGROUND TASK
    EXPORTING
      id = ls_data-id.

ENDFUNCTION.

И еще один UPDATE TASK отложенного запуска:

FUNCTION zfm_krs_test_upd2.
*"----------------------------------------------------------------------
*"*"Функциональный модуль обновления:
*"
*"*"Локальный интерфейс:
*"  IMPORTING
*"     VALUE(ID) TYPE  CHAR10
*"----------------------------------------------------------------------
  DATA ls_data TYPE zkrs_test_bgto.

  ls_data-id = id.

*  WAIT UP TO 5 SECONDS.

  GET TIME STAMP FIELD ls_data-tst.

  MODIFY zkrs_test_bgto FROM ls_data.

ENDFUNCTION.

Для наглядности где какой тип ставить картинка:

И выполняем вот такой код для проверки

CALL FUNCTION 'ZFM_KRS_TEST_BG'
    IN BACKGROUND TASK
    EXPORTING
      id = 'BG'.

  CALL FUNCTION 'ZFM_KRS_TEST_UPD'
    IN UPDATE TASK
    EXPORTING
      id = 'U0'
      iv_wait = 0.


  CALL FUNCTION 'ZFM_KRS_TEST_UPD'
    IN UPDATE TASK
    EXPORTING
      id = 'U1'
      iv_wait = 5.

  CALL FUNCTION 'ZFM_KRS_TEST_UPD2'
    IN UPDATE TASK
    EXPORTING
      id = 'U2'.

  COMMIT WORK.

Как видите, тут мы вначале регистрируем BG-ФМ, потом UPD-ФМ с нулевой задержкой внутри, потом UPD-ФМ с задержкой в 5 секунд перед обновлением и завершением, и, наконец, UPD-ФМ с задержкой обновления.
Наша задача доказать что BG-ФМ выполнится последним, несмотря на то, что зарегистрирован первым, и главное выполнится только после всех UPD-ФМ. И заодно проверим вызовется ли BG-ФМ из UPD-ФМ без COMMIT.
Запускаем и смотрим в таблицу (таблица для наглядности отсортирована по времени выполнения):


Итак, какие можно сделать выводы.

1. BG-ФМ запускается после выполнения всех UPD-ФМ (даже после UPD-ФМ с задержкой запуска) 
2. BG-ФМ, вызванный из UPD-ФМ, не нуждается в дополнительном COMMIT для запуска 
3. BG-ФМ, вызванный из UPD-ФМ, также запускается только после выполнения всех UPD-ФМ (даже после UPD-ФМ с задержкой запуска) 
4. BG-ФМ, зарегистрированный до COMMIT, вызывается позже чем BG-ФМ, вызванные из UPD-ФМ

ЧТД.