Johan van Zijl

I recently started working on the ERP Sales Order functionality in the CRM 5.0 WebClient. This is essentially a WebClient view which uses the ERP 6.0 Lean Order API(LORD) to perform all sales order functionality directly in the backend. The benefit is no messy replication of CRM Sales Orders, Config, Pricing and Enhancements.

The problem is that as with all ERP systems customers enhance VA01 over time and the Lean API does not cater for all scenarios, such as additional fields appended to VBAK which must be filled by the user. (UPDATE – See Note 1078575 for restrictions)

The problem is that there seems no(to my knowledge) way to extend the structures of the API to carry these from CRM to ERP in any traditional(i.e. passing parameters) way.

Then this SDN thread prompted me to investigate the innovative implementation of the Lean Order API and I learned something new: Global variables in SAP Programs are externally accessible!

So all you need to do is create a Remote Function module like the one below in ERP.

FUNCTION ZZ_ERPORDER_TRANSFER_FIELD.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IV_CONTACT_NAME) TYPE  ZZCONTACT DEFAULT 'My Abap Test'
*"----------------------------------------------------------------------

 field-symbols: <fs_vbak> type vbak.

 assign ('(SAPLSLS_LORD)VBAK') to <fs_vbak>.
 if sy-subrc = 0.
    <fs_vbak>-ZZCONTACT = IV_CONTACT_NAME.
 endif.

ENDFUNCTION.

The function module above accesses the global VBAK structure in Function Group SLS_LORD and updates it. This is riding rough shod over any concept of variable scope, so please think carefully before implementing this.

Now, all you need is to call the RFC Function Module from CRM. I used an implementation of BADI CRM_IC_ERP_BADI to accomplish this.

method IF_EX_CRM_IC_ERP_BADI~AFTER_CREATION.

call function 'ZZ_ERPORDER_TRANSFER_FIELD'
  destination cl_crm_erp_il=>gv_rfc
  EXPORTING
     IV_CONTACT_NAME = 'Contact Name'.

endmethod.

–Update– The code shown here is not 100% correct and reliable. I will probably fix at some point…

I haven’t posted in a long time, mostly because I have been doing everything except working on a SAP system. So, the first bit of code I have written in a while goes here.

Scenario: Its difficult for BW to create reports according the Category Hierarchy on CRM Service Tickets as maintained in the Category Modeller.

Quick Fix Solution: Append fields for Level 1,2 and 3 to CRMD_CUSTOMER_H using EEWB. Create initial load report and BADI implementation to fill these.

I am not going to explain in much more detail. Hopefully someone finds the code useful.

The code can be found here:  Category Update Code.

CRM 7.0 is due to start ramp up on 21 November 2008. There has been some significant enhancements in the following areas:

• Interaction Centre – Lean Interaction Record and optimization for high-volume use
• IT Service Desk and Accounting Interaction Centre Scenarios
• Increased Personalization and Improved UI Tools
• Marketing -> Loyalty Management and Improved TPM
• A lot of functionality has been added to CRM Service and includes improved ERP Integration, Advanced Contract Management, Warranty Processes, etc.

For those with access to the Service Marketplace there are more info on ramp up here and some good presentations on SAP CRM 7.0 here.

This presentation just popped into my inbox. It describes the new features in SAP NetWeaver 7.1 CE’s Web Dypro Java.

But the screens in the presentation looks exactly like CRM 2007 screens!

Interesting, considering CRM 2007 has been available for almost a year now and is built on ABAP/BSP and not even WebDynpro.

Mmm…The same UI built and supported in 2 languages!?

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).