Johan van Zijl

I recently read a very interesting post by Martin Ceronio that explains an innovative way of gaining shell access to any SAP system.

Obviously, Basis and Security consultants all over will have a fit when they realise this is possible on their precious SAP systems. I must admit though, this is so easy that I am not 100% comfortable with this hole.

But, In order to exploit this you do need access to an SAP system and a fair amount of knowledge of how SAP works …and sufficient authorization.

This brings me to something that has been bothering me lately, which is customers need to trust the consultants they give access to their systems, especially ABAP consultants as they no more about the internals of SAP than anyone else.

The latest trend  is to lock down authorizations in development systems to the point where consultants are unable to perform their work and there is always doubt as to whether the problem is code related or authorization related. I completely support the full lock down of Quality Assurance and Production Systems, but is it really necessary in Development?

The moment you give a consultant debug with variable change authorization(which ABAP consultants must have in development), virtually any check can be bypassed (you can even grant yourself SAP_ALL and a Developer Key).

The other major threat is ABAP developers writing malicious programs and slipping them into production under the radar.

In my view draconian restrictions in development systems frustrates your consultants and leads to a real increase in development time. The assumptions made by the implemter of these authorizations must be(maybe a bit harsh):

• The consultants cannot be trusted to act responsibility
• They are too stupid to find their way around all the restrictions

There is a lighter side to this though and that involves phoning the authorization consultant at 2:00 AM for that transaction code you really need now to the fix problem(and going to bed and booking a delay against him if he doesn’t answer).

Here is some code that will help you to determine the Sales Areas assigned to a CRM Business Partner and also the sales area details maintained for the BP.

The variables you will need are provided below:

data: lv_partner_guid type  bu_partner_guid,
      lt_sales_areas  type  crmt_bus_sales_area_t,
      ls_data         type  crmt_bus_set0030,
      lv_owner        type  crmt_bu_set_owner,
      lt_return       type  bus_bapi-return_table,
      lv_error        type  bus_bapi-error.
field-symbols: <fs_sales_area> type  crmt_bus_sales_area.

Below is the code which allows you to retrieve the billing data tab(price group, currency, customer group, etc) .

    call function 'CRM_BUPA_FRG0030_GET_LIST'
      exporting
        iv_partner_guid = lv_partner_guid
      importing
        et_sales_areas  = lt_sales_areas.

    loop at lt_sales_areas assigning <fs_sales_area>.
      call function 'CRM_BUPA_FRG0030_GET_DETAIL'
        exporting
          iv_partner_guid = lv_partner_guid
          is_sales_area   = <fs_sales_area>;
        importing
          es_data         = ls_data
          ev_owner        = lv_owner
          et_return       = lt_return
          ev_error        = lv_error.
    endloop.

The export parameter ev_owner will contain an X if CRM is the owner of the set.

The function module CRM_BUPA_FRG0010* allows you to read the Sales Data tab and CRM_BUPA_FRG0020* allows you to read the Shipping Data tab on the BP.