Creation of Transfer order takes time

[ManojYadav]

Dear All,

Need your help on below query.

On ALV, we select order numbers and click on the push button to create "Transfer order (staging)". For this, we have a BDC on tcode LP10. After BDC, we are displaying the list of "transfer orders" created above on a pop-up screen. But the creation of TOs sometimes takes a lot of time. Due to this, the wrong message is displayed to users.

The pseudo code as below:

lv_date = sy-datlo.

lv_time = sy-timlo.

LOOP AT it_selected_objects INTO ls_selected_objects.

BDC code.

CALL TRANSACTION 'LP10'

USING gt_bdc

MODE 'N'

UPDATE 'S'

MESSAGES INTO lt_msg.

ENDLOOP.

WAIT UP TO 5 SECONDS.

*/..Get created TO's in above step

SELECT lgnum tanum benum FROM ltak

INTO TABLE lt_ltak

FOR ALL ENTRIES IN lt_aufnr

WHERE benum = lt_aufnr-aufnr

AND bname = sy-uname

AND bdatu GE lv_date

AND bzeit GE lv_time.

IF sy-subrc EQ 0.

Display list on pop-up.

ELSE.

MESSAGE "No Transfer orders created for selected service orders" TYPE 'I'.

ENDIF.

How can I solve this issue? By increasing wait time? or BDC update mode set to "L" or "A"?

Thanks in advance.

Regards,

Manoj

[VXLozano]

Is there no BAPI to create transfer orders? Why a batch-input? What do the CALL TRANSACTION messages say?

If you find an alternate (and better) way to create the TO (via BAPI, maybe?) you will be able to get rid of that WAIT UP TO FIVE ETERNAL SECONDS, and you will have better control of the output (ie: why the TO has not been created).

[Sandra_Rossi]

Please edit your question (menu Actions > Edit), select your code and press the button [CODE], which makes the code appear colored/indented, it will be easier for people to look at it. Thank you!

[DominikTylczyn]

Hello manoj_yadav

LP10 as such doesn't create transfer orders. It creates transfer requirements. I presume that you have activated immediate transfer orders creation from transfer requirements. If so, transfer orders are created asynchronously with qRFC calls. That is done by the TA_AUTOMATISCH_ANSTEUERN form routine, include LLCPPF0F, line ~80:

        move CON_RFC_CALL_WMPP to lf_qname.
        move '_'               to lf_qname+9.                "v_n_653897
        move sy-uname          to lf_qname+10.
        condense lf_qname no-gaps.                           "^_n_653897

      CALL FUNCTION 'TRFC_SET_QUEUE_NAME'
           EXPORTING
                QNAME = LF_QNAME.

      CALL FUNCTION 'L_COMMUNICATION_TO_CREATE' IN BACKGROUND TASK
        AS SEPARATE UNIT
           EXPORTING
                MAILK   = HLP_ITBDIR-MAILK
                BUSER   = SY-UNAME
                BETYP   = HLP_ITBDIR-BETYP
                BENUM   = HLP_ITBDIR-BENUM
                MATNR   = HLP_ITBDIR-MATNR
                BERKZ   = BERKZ
                LANGU   = SY-LANGU
           TABLES
                T_LTBUB = ITBDIR.

Notice how the queue name is set to MW_KANBAN_<user name>. MW_KANBAN comes from the CON_RFC_CALL_WMPP constant.

Therefore instead of just waiting for an arbitrary time, you should check the status of RFC queues in the TRFCQOUT table. Look for MW_KANBAN_<user name> queues and wait till all of them are processed, either correctly or erroneously. Only after that read the transfer orders. The qRFC statuses are defined in the RSTRFCM1 report:

constants: qs_ready    like trfcqout-qstate value 'READY',
           qs_running  like trfcqout-qstate value 'RUNNING',
           qs_executed like trfcqout-qstate value 'EXECUTED',
           qs_sysload  like trfcqout-qstate value 'SYSLOAD',
           qs_sysfail  like trfcqout-qstate value 'SYSFAIL',
           qs_cpicerr  like trfcqout-qstate value 'CPICERR',
           qs_stop     like trfcqout-qstate value 'STOP',
           qs_waitstop like trfcqout-qstate value 'WAITSTOP',
           qs_waiting  like trfcqout-qstate value 'WAITING',
           qs_nosend   like trfcqout-qstate value 'NOSEND', "#EC *
           qs_nosends  like trfcqout-qstate value 'NOSENDS',
           qs_waitupda like trfcqout-qstate value 'WAITUPDA',"#EC *
           qs_vberror  like trfcqout-qstate value 'VBERROR',"#EC *
           qs_finish   like trfcqout-qstate value 'FINISH', "#EC *
           qs_retry    like trfcqout-qstate value 'RETRY',
           qs_afinish  like trfcqout-qstate value 'AFINISH',"#EC *
           qs_aretry   like trfcqout-qstate value 'ARETRY',
           qs_anoretry like trfcqout-qstate value 'ANORETRY',
           qs_modify   like trfcqout-qstate value 'MODIFY'. "#EC * 

You can also view qRFC queues with SMQ1 transaction.

Best regards

Dominik Tylczynski

[ManojYadav]

Hello Dominik,

Thank you so much. I will check this approach and let you know if its works.

Regards,
Manoj