Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Use CRM_ORDER_MAINTAIN FM to change CREATED_BY field into an order.

Former Member
0 Kudos

Hello,

I am facing a challenge  when changing created_by field from an order using FM CRM_ORDER_MAINTAIN.

It is a bit tricky to choose the right input fields.

I also have setup the active switch in order for the change to work.

But still doesn't work.

Does anyone have an example of this FM being used in the same purpose?

Any help is much appreciated.

Thank you.

Best regards,

Elena Hutanu

16 REPLIES 16

Former Member
0 Kudos

Hi Elena

Are you referring to the Partner Function: Created by

or the value on CRMD_ORDERADM_H

Regards

Arden

0 Kudos

Hello Arden,

I have to update both the references.

Partner function and Created_by field from CRMD_ORDERADM_H.

Thank you.

Best regards,

Elena

0 Kudos

OK

I'll leave out the Header Update, once you get the Partner Update done, you should find the header update easier.

Sorry, the following code is from a massive integration program I wrote years ago, so the field definitions are missing, but I think you'll get the general idea.

Do a CRM_ORDER_READ to get the relevant current values for Header and Partner

Then : CALL FUNCTION 'CRM_ORDER_INITIALIZE' with the relevant ORDER guid

Then apply this code to deal with the Partner Update

"This would be your read of the relevant Partner Function from CRM_ORDER_READ   

READ TABLE gt_partner INTO gs_partner WITH KEY partner_fct = '00000056'.

CHECK sy-subrc EQ 0.

*   Call must be reassigned back to the call center

    CLEAR gs_input_fields. REFRESH gt_input_fields.

    gs_input_fields-ref_guid    = gs_crmd_orderadm_h-guid.

    gs_input_fields-ref_kind    = 'A'.

    gs_input_fields-objectname  = 'PARTNER'.

    CLEAR gs_field_names.

    gs_field_names-fieldname = 'DISPLAY_TYPE'.

    APPEND gs_field_names TO gs_input_fields-field_names.

    CLEAR gs_field_names.

    gs_field_names-fieldname = 'KIND_OF_ENTRY'.

    APPEND gs_field_names TO gs_input_fields-field_names.

    CLEAR gs_field_names.

    gs_field_names-fieldname = 'NO_TYPE'.

    APPEND gs_field_names TO gs_input_fields-field_names.

    CLEAR gs_field_names.

    gs_field_names-fieldname = 'PARTNER_NO'.

    APPEND gs_field_names TO gs_input_fields-field_names.

    ls_partner-ref_partner_no = gs_partner-partner_no.

    ls_partner-ref_partner_handle = gs_partner-ref_partner_handle.

    ls_partner-ref_guid = gs_crmd_orderadm_h-guid.

    ls_partner-ref_kind = gs_partner-ref_kind.

    ls_partner-ref_partner_fct = gs_partner-ref_partner_fct.

    ls_partner-ref_no_type = gs_partner-ref_no_type.

    ls_partner-ref_display_type = gs_partner-ref_display_type.

    ls_partner-kind_of_entry = 'A'.

 

    ls_partner-partner_no = gv_stat_partner.

    ls_partner-no_type = gs_partner-ref_no_type.

    ls_partner-display_type = gs_partner-ref_display_type.

    ls_logical_key-ref_partner_handle = ls_partner-ref_partner_handle.

    ls_logical_key-ref_partner_fct = ls_partner-ref_partner_fct.

    ls_logical_key-ref_partner_no = ls_partner-ref_partner_no.

    ls_logical_key-ref_no_type = ls_partner-ref_no_type.

    ls_logical_key-ref_display_type = ls_partner-ref_display_type.

    gs_input_fields-logical_key = ls_logical_key.

    APPEND gs_input_fields TO gt_input_fields.

    APPEND ls_partner TO lt_partner. CLEAR ls_partner.

      CALL FUNCTION 'CRM_ORDER_MAINTAIN'

        EXPORTING

          it_partner        = lt_partner

        CHANGING

          ct_input_fields   = gt_input_fields

        EXCEPTIONS

          error_occurred    = 1

          document_locked   = 2

          no_change_allowed = 3

          no_authority      = 4

          OTHERS            = 5.

clear gs_objects_to_save.

  gs_objects_to_save = gs_crmd_orderadm_h-guid.

  append gs_objects_to_save to gt_objects_to_save.

  CALL FUNCTION 'CRM_ORDER_SAVE'

    EXPORTING

      it_objects_to_save   = gt_objects_to_save

    IMPORTING

      et_saved_objects     = gt_saved_objects

      et_exception         = gt_exception

      et_objects_not_saved = gt_objects_not_saved

    EXCEPTIONS

      document_not_saved   = 1

      OTHERS               = 2.

Then Commit the changes

Regards

Arden         

0 Kudos

Hello Arden,

Thank you for your reply and sorry for my late answer.

I have used the logic to change both the partner function and the header but after running the maintain FM I get sy-subrc = 4 which means I have no authority.

Do you know whether I have to setup any new parameters in order to make the change?

I can change the same order in UI so I do have access to change it, I am certain I need some additional setups but cannot figure which.

my entries below:

      CALL FUNCTION 'CRM_ORDER_MAINTAIN'

        EXPORTING

          it_partner        = lt_partner

          it_active_switch  = lt_active_switch

        CHANGING

          ct_orderadm_h     = lt_orderadm_h_new

          ct_input_fields   = lt_input_fields

        EXCEPTIONS

          error_occurred    = 1

          document_locked   = 2

          no_change_allowed = 3

          no_authority      = 4

          OTHERS            = 5.

Thank you for your help.

Best regards,

Elena

0 Kudos

Hi Elena

That's very odd.

Any chance you can run an Authorisation Trace when you run this function. (Transaction ST01)

Regards

Arden

0 Kudos

Hello,

The ST01 doesn't read any record, the file comes back empty and in the su53 I get that the last authorization check was successful.

I did though commented out the orderadm_h table update and I get the sy-subrc = 0 but still the partner is not changed.

The authorization issue must come up when I try to maintain the header table.

Best regards,

Elena

ceedee666
Active Contributor
0 Kudos

Hi Elena,

as always my answer to this type of questions is: why are you using the CRM_ORDER_MAINTAIN function module and not the corresponding BOL object? From my point of view using the BOL is much easier. Only in special cases I'd recommend using CRM_ODER_MAINTAIn directly.

As example how to use the BOL is available here: Modify an entity and save the entity using BOL Programming - CRM - SCN Wiki

Christian

Former Member
0 Kudos

Hello Christian,

Thank you for your suggestion.

At a first look the recommended code will change a few attributes from a specific transaction type.

My case is that I need to change several document types and not only one but a list of them.

Also the 'Partner function' and the header 'Created_by' information are not part of the same UI app.

Do you think this would be a more easy way to do it in this case also?

Thanks.

Best regards,

Elena

ceedee666
Active Contributor
0 Kudos

Hi Elena,

definitely. The CRM_ORDER_MAITAIN function module is in my opinion a very low level API. Allowing everything but at the cost of being very complex.

With the BOL you are working on a higher abstraction layer. Here there is not one large function module to change an order but instead you work on objects like partner set, status set etc. It also doesn't matter if there is an CRM UI that has all data in one screen. The BOL is the obejct model underlying the UI but independent of it.

Here is an example of how to change certain field of a CRM order using BOL:http://www.abaplog.com/Icerik/33/how-to-change-order-status-with-bol-programming

Further more you shóuld have a look at the general introduction to BOL programming: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e0ddd4e6-32f9-2c10-9d88-d993c4b00...

Christian

0 Kudos

Because we all know that the BOL layer at the end of the day calls CRM_ORDER_MAINTAIN and it's much more efficient for mass updates to either call CRM_ORDER_MAINTAIN or the XIF adapter instead.   I think honestly CRMXIF_ORDER_SAVE is a better option than both the BOL and CRM_ORDER_MAINTAIN.  It's what I use for my inbound data conversions, however if you need to precision update a single segment of an one order document, I personally like CRM_ORDER_MAINTAIN. 

 

That being said, the best way to figure out what you need to fill out, is to run the program CRM_ORDER_READ in SE38 which will show you how SAP populates all the segments.  The trick is to make sure you use business transaction that was manually create/populated with your target values.

This probably needs to be in the CRM spaces on SCN, because answering this in ABAP general just seems weird.

Take care,

Stephen

Former Member
0 Kudos

Hi Christian,

I have tried your way also and  it doesn't make the update as the flag comes up for read_only.

Don't think I can change that.

Any ideas would be most appreciated.

Thank you.

Best regards,

Elena Hutanu

Former Member
0 Kudos

Hello Stephen,

Thank you for you answer.

''The trick is to make sure you use business transaction that was manually create/populated with your target values."


Related to your suggestion, unfortunately the value I need to change is the CREATED_BY partner function and in the front end this value cannot be changed as it is grade out.


This is why I am trying to change it via a back end program, so I cannot debug my case as I cannot change the necessary input.


Best regards,

Elena Hutanu



0 Kudos

Actually CRM_ORDER_MAINTAIN has existed before the bol and is part of the one-order API that is the foundation for SAP CRM.  It's not really low-level since the if you go below there is a lot more layers below that function module.  I would concede that understanding screen-driven BDT for the business partner is not really necessary, but the API's are still good to know.

It really is good to know how to use one-order, because that part has remains stable despite any UI changes to SAP CRM.

Take care,

Stephen

0 Kudos

I wrote something similar and my logic shows that for the input filed table you need have:

PARTNER_NO, PARTNER_FCT, MAINPARTNER, DISPLAY_TYPE, KIND_OF_ENTRY, NO_TYPE

for the partner communication structure:

ref_guid, ref_kind, kind_of_entry, partner_no, no_type, display_type, mainpartner must be maintained

You will also need to do a move corresponding of the partner communication structure to the logical key of the input fields.

I would also check your partner determination procedure to see if the partner function is changeable.  If not then I would adjust the configuration temporarily to allow this and run your program.

Beyond that I don't know what else you can do, but I did build/use a similar program to update a single partner function on a transaction once.

Take care,

Stephen

ceedee666
Active Contributor
0 Kudos

Hi Elena,

I guess this is due to the changeability mentioned in his comment. The BOL just calls CRM_ORDER_MAINTAIN underneath so the same restrictions, checks etc. apply.

Christian

Former Member
0 Kudos

Hi All,

The issue was that the Partner Function had also the 'Block Entry'  flag checked which didn't allow me to make any change using the FM.

I removed that flag leaving though the Partner Function unchangeable and I could make the necessary changes afterwards using my program.


Thank you all for your help.

Was much appreciated.


Best regards,

Elena Hutanu