topic Re: KO02 - Internal Order Change in Application Development and Automation Discussions

KO02 - Internal Order Change

Former Member — Mon, 30 Sep 2019 11:07:36 GMT

Hi,

I am trying to change Internal Order using BAPI 'KAUF_ORDER_STORE'. But data is not getting updated. Can someone help me out.

Code that i have written:

is_coas-ktext = 'Change IO K'.
*is_coas-ltext = 'Long text for IO'.
is_coas-aufnr = '1234TEST56'.

is_kauf-auf_index = '1'.
is_kauf-flg_enque = 'X'.
is_kauf-flg_erloe = 'X'.
is_kauf-flg_obligox = 'X'.
is_kauf-old_astnr = '10'.
is_kauf-old_estnr = '00'.
is_kauf-par_actvt = '02'.
is_kauf-par_aprof = 'MSAM'.
is_kauf-par_obtyp = 'ORC'.
is_kauf-par_busobj = 'BUS2075'.
is_kauf-par_layou = 'MSAM'.
is_kauf-par_dbmod = 'U'.

DATA: afko TYPE afko,
afpo TYPE afpo.

CALL FUNCTION 'KAUF_ORDER_STORE'
EXPORTING
i_afko = afko
i_afpo = afpo
* i_check = 'A'
i_coas = is_coas
* i_dialog = 'X'
i_kauf = is_kauf
* i_save_flag = 'X'
* I_AUC_DIALOG_OFF = ABAP_FALSE
EXCEPTIONS
error_message = 1
OTHERS = 2.
IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.

Thanks in Advance

Re: KO02 - Internal Order Change

GK817 — Mon, 30 Sep 2019 11:19:57 GMT

Hi,

You need to pass I_SAVE_FLAG as 'X' to save the data. Also, try calling BAPI_TRANSACTION_COMMIT after the FM call.

P.S. : This is a 'Not Released' function module, not recommended to use.

Regards

Re: KO02 - Internal Order Change

former_member1716 — Mon, 30 Sep 2019 11:25:59 GMT

Hello Sankar Gelivi,

Kindly use BAPI_TRANSACTION_COMMIT after your Successful FM Call. Below Code for reference.

*Commit On Success
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
wait = 'X'.

Kindly note that it is not released in my version as shown below, Kindly check the same if it is released in your version.

Re: KO02 - Internal Order Change

Former Member — Tue, 01 Oct 2019 11:41:28 GMT

Hi Gaurav,

Can you share me the change FM or BAPI for internal order if you are aware.

As suggested, i have tried still it is not working.

Thanks & Regards,

Sankar Gelivi

Re: KO02 - Internal Order Change

GK817 — Tue, 01 Oct 2019 13:37:21 GMT

Hi,

Did you try by passing i_save as X and then using commit work after that?

Re: KO02 - Internal Order Change

Former Member — Tue, 01 Oct 2019 16:38:27 GMT

Unfortunately there is no BAPI or any kind of standard feature officially released for customer use in regards of internal order modification. I also don't recommend to use KAUF_ORDER_STORE even if you are able to make it work, as input validation seems to be completely missing from its coding.

The best thing I've found so far for this kind of tasks is function module KAUF_ORDER_CHANGE_BAPIFIELDS with is BAPI-like parameter list and behavior:

DATA: order            TYPE aufk-aufnr,
      order_data       TYPE aufk,
      test             TYPE abap_bool,
      save_flag        TYPE abap_bool,
      fields_to_change TYPE STANDARD TABLE OF ddfldnam,
      messages         TYPE bapirettab.

order = 'TEST'.

" Provide new field values
order_data-ktext = 'This is a test'.

" Mark fields to be changed
fields_to_change = VALUE #( ( name = 'KTEXT' ) ).

" Set save flag
save_flag = boolc( test = abap_false ).

CALL FUNCTION 'KAUF_ORDER_CHANGE_BAPIFIELDS'
  EXPORTING
    i_order          = order
    i_aufk_new       = order_data
    i_flag_testrun   = test
    i_flag_save      = save_flag
  TABLES
    fields_to_change = fields_to_change
    return           = messages
  EXCEPTIONS
    OTHERS           = 1.

COMMIT WORK.

If any error occurs it will be returned in parameter RETURN.

Re: KO02 - Internal Order Change

Nawanandana — Wed, 02 Oct 2019 20:01:33 GMT

Hi,

I suggest to use FM BAPI_INTERNALORDER_SAVEREPLICA. This FM is documented, and released for customer use

Re: KO02 - Internal Order Change

Former Member — Thu, 03 Oct 2019 07:45:38 GMT

Although it is indeed in released status this function is meant for use only in ALE scenarios where the assumption is that the data has already been validated on the sender side.

It does not contain authorization checks and only very limited input data checks restricted to one or two organization data fields, does not consider field selection from order type configuration, always deactivates budgeting related statuses (which is maybe not the intention) and if the order did not exist previously it gets created.

A lot more have to be done by the caller.