How to resolve COMMIT_IN_POSTING error when 'send immediately'?

[former_member367551]

Dear forumers,

I have a requirement as follows:-

- Create new print program, ZPRINT_SD that is configured for a new output type, ZSD1

- The output type, ZSD1 will be configured for debit memo requests

- Each time a debit memo request is saved (i.e. in transactions VA01 or VA02), a debit memo must be created from the print program

The dispatch time for the output type, ZSD1 is set as "send immediately".

For this, I noticed that I keep running into the runtime error, COMMIT_IN_POSTING each time the debit memo request is saved - and no debit memo is created too.

If I delay the dispatch time for the output type, ZSD1 and run the program, RSNAST00, then there will be no runtime error and a debit memo will be created.

The FM, BAPI_BILLINGDOC_CREATEMULTIPLE is called in the print program for creating the debit memo.

The runtime error mentioned here is caused by the COMMIT WORK statement that was executed from the called FM, RV_INVOICE_REFRESH.

This is how my codes look like:-

PROGRAM ZPRINT_SD.

* declaration of data
INCLUDE rlb_invoice_data_declare.
* definition of forms
INCLUDE rlb_invoice_form01.
INCLUDE rlb_print_forms.

*---------------------------------------------------------------------*
*       FORM ENTRY
*---------------------------------------------------------------------*
FORM entry USING return_code us_screen.

  DATA: lf_retcode TYPE sy-subrc.
  CLEAR retcode.
  xscreen = us_screen.
  PERFORM processing USING us_screen
                     CHANGING lf_retcode.
  IF lf_retcode NE 0.
    return_code = 1.
  ELSE.
    return_code = 0.
  ENDIF.

ENDFORM.                    "ENTRY


FORM processing  USING    proc_screen
                  CHANGING cf_retcode.

  DATA: lt_billing  TYPE STANDARD TABLE OF bapivbrk.
  DATA: lt_return   TYPE STANDARD TABLE OF bapiret1.
  DATA: lt_success  TYPE STANDARD TABLE OF bapivbrksuccess.

  DATA: lwa_vbak    TYPE vbak.
  DATA: lwa_billing TYPE bapivbrk.
  DATA: lwa_return  TYPE bapiret2.

  CONSTANTS: lc_debitmemo_type TYPE fkara VALUE 'ZSRV'.

  CLEAR:
cf_retcode,
lt_billing, lt_return, lt_success,
lwa_vbak, lwa_billing, lwa_return.


* Retrieve data on the debit memo request
  SELECT SINGLE *
    FROM vbak
    INTO lwa_vbak
    WHERE vbeln = nast-objky.

  IF sy-subrc = 0.
    lwa_billing-salesorg   = lwa_vbak-vkorg.
    lwa_billing-distr_chan = lwa_vbak-vtweg.
    lwa_billing-division   = lwa_vbak-spart.
    lwa_billing-doc_type   = lwa_vbak-auart.
    lwa_billing-ref_doc    = lwa_vbak-vbeln.
    lwa_billing-bill_date  = sy-datum.
    lwa_billing-sold_to    = lwa_vbak-kunnr.
    lwa_billing-ordbilltyp = lc_debitmemo_type.
    lwa_billing-price_date = sy-datum.
    lwa_billing-ref_doc_ca = lwa_vbak-vbtyp.

    APPEND lwa_billing TO lt_billing.

    SET UPDATE TASK LOCAL.

* Create debit memo
    CALL FUNCTION 'BAPI_BILLINGDOC_CREATEMULTIPLE'
      TABLES
        billingdatain = lt_billing
        return        = lt_return
        success       = lt_success.


    cf_retcode = sy-subrc.
  ENDIF.

ENDFORM.                    "PROCESSING

Any ideas on how I can resolve this issue with the dispatch time set as "send immediately"?

Appreciate any help at all.

Thanks,

Deborah

[former_member367551]

Dear forumers,

I have also tried the following, but it failed as well:-

*    SET UPDATE TASK LOCAL.

* Create debit memo

    CALL FUNCTION 'BAPI_BILLINGDOC_CREATEMULTIPLE' IN UPDATE TASK

      TABLES

        billingdatain = lt_billing

        return        = lt_return

        success       = lt_success.

Appreciate any inputs. Many thanks.

[somnath]

Hi - I didn't get why you prefer to use SET UPDATE TASK LOCAL? Is there any technical issue you faced. Could you please remove the statement and post the outcome here?

Also try if this helps you.

Step 1- Transaction_begin --> Get the transaction ID

Step 2 - Call the BAPI

Step - 3 Transaction_end <- Pass the transaction ID.

- Thanks , Somnath

[former_member367551]

Hi Somnath,

I run my tests via the transaction, VA02.

Would you please elaborate what you meant for the 3 Steps in your note?

I added "SET UPDATE TASK LOCAL" because initially, the program codes were written like this and still, the same COMMIT_IN_POSTING runtime error occurred then:-

...

    lwa_billing-salesorg   = lwa_vbak-vkorg.

    lwa_billing-distr_chan = lwa_vbak-vtweg.

    lwa_billing-division   = lwa_vbak-spart.

    lwa_billing-doc_type   = lwa_vbak-auart.

    lwa_billing-ref_doc    = lwa_vbak-vbeln.

    lwa_billing-bill_date  = sy-datum.

    lwa_billing-sold_to    = lwa_vbak-kunnr.

    lwa_billing-ordbilltyp = lc_debitmemo_type.

    lwa_billing-price_date = sy-datum.

    lwa_billing-ref_doc_ca = lwa_vbak-vbtyp.

    APPEND lwa_billing TO lt_billing.

* Create debit memo

    CALL FUNCTION 'BAPI_BILLINGDOC_CREATEMULTIPLE'

      TABLES

        billingdatain = lt_billing

        return        = lt_return

        success       = lt_success.

    cf_retcode = sy-subrc.

[former_member367551]

Just to add on:-

The initial codes worked perfectly when I delay the dispatch time for the output type, i.e. "send with periodically scheduled job" in transaction VA02 and then execute the program, RSNAST00.

[somnath]

Hi -

Once you save the DMR thru VA02 COMMIT doesn't get complete before you trigger your print program. So it seems the DMR is not in place. Once you give a delay in the processing then it works fine.

So probably you can set a little delay using WAIT UP TO 10 secs (say)  before calling the BAPI - and then allow the print program to generate the DM.

As within this time frame the DMR will be saved in the database.

Related to my earlier posting about the three steps: for the time being park that changes and just add the wait statement to your print program and let me know.

- Thanks , Somnath

[former_member367551]

Thanks for your inputs again, Somnath.

I have tried the WAIT statement earlier as well, but it didn't work.

I have just tried it again, and the outcome is still the same:-

I will have a pop-up message, "Express document "Update was terminated" received ..."

And when I check the error in ST22, it is concerning COMMIT_IN_POSTING again.

Here are the latest codes:-

FORM processing  USING    proc_screen

                 CHANGING cf_retcode.

  DATA: lt_billing  TYPE STANDARD TABLE OF bapivbrk.

  DATA: lt_return   TYPE STANDARD TABLE OF bapiret1.

  DATA: lt_success  TYPE STANDARD TABLE OF bapivbrksuccess.

  DATA: lwa_vbak    TYPE vbak.

  DATA: lwa_billing TYPE bapivbrk.

  DATA: lwa_return  TYPE bapiret2.

  CONSTANTS: lc_debitmemo_type TYPE fkara VALUE 'ZSRV'.

  CLEAR:

  cf_retcode,

  lt_billing, lt_return, lt_success,

  lwa_vbak, lwa_billing, lwa_return.

* Retrieve data on the debit memo request

  SELECT SINGLE *

    FROM vbak

    INTO lwa_vbak

    WHERE vbeln = nast-objky.

  break ext_dtan.

  IF sy-subrc = 0.

    lwa_billing-salesorg   = lwa_vbak-vkorg.

    lwa_billing-distr_chan = lwa_vbak-vtweg.

    lwa_billing-division   = lwa_vbak-spart.

    lwa_billing-doc_type   = lwa_vbak-auart.

    lwa_billing-ref_doc    = lwa_vbak-vbeln.

    lwa_billing-bill_date  = sy-datum.

    lwa_billing-sold_to    = lwa_vbak-kunnr.

    lwa_billing-ordbilltyp = lc_debitmemo_type.

    lwa_billing-price_date = sy-datum.

    lwa_billing-ref_doc_ca = lwa_vbak-vbtyp.

    APPEND lwa_billing TO lt_billing.

    WAIT UP TO 15 SECONDS.

* Create debit memo

    CALL FUNCTION 'BAPI_BILLINGDOC_CREATEMULTIPLE'

      TABLES

        billingdatain = lt_billing

        return        = lt_return

        success       = lt_success.

    cf_retcode = sy-subrc.

  ENDIF.

ENDFORM.                    "PROCESSING

[somnath]

There is an update task error, run SM13 and cross check the issue there. May be helpful if you can post the screen shots.

Also I saw you have placed the wait after select, can you please place it before select statement.

- Thanks , Somnath

[former_member367551]

[former_member367551]

Dear Somnath,

Regarding your statement earlier:-

"Also I saw you have placed the wait after select, can you please place it before select statement."

I have just tried and tested this, and it did not work too.

(The reason for this is because the SELECT statement retrieves data from the VBRK table -- and at any point of time, the VBRK data record would have already existed earlier on. This is because the transaction that we're working on is always VA02 - making changes to existing debit memo request.)

Any other ideas perhaps?

[former_member367551]

The issue is resolved after I've added IN BACKGROUND TASK to the BAPI call.