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.

The SAP CRM system allows a manager to send broadcasts to agents via the broadcast manager. This is useful to notify agents immediately of any important information.

The BSP Application CRM_BM can be used to send broadcast messages. Below is a screenshot.

When you click send, the user will immediately receive a scrolling message at the bottom of their screen.

However, in some case you may want to send an automated message. Maybe you want to notify a processor that a service ticket is outside SLA or a customer must be phoned?

It is possible to send broadcasts automatically from background jobs or actions using the following code.

data: lt_users    type  crmt_bm_key_value_tab,
      ls_user     type  crmt_bm_key_value_line,
      lv_message  type  string.

data: supervisor type ref to cl_crm_bm_broadcast_sup.

   lv_message = 'This is a demo message'.
   ls_user-key = 'AUSERNAME'.
   ls_user-value = 'AUSERNAME'.
   append ls_user to lt_users.
   create object supervisor.

   try.
     supervisor->send_message(
       exporting text_value       = lv_message
                 priority_value   = '0'
                 duration_h_value = '0'
                 duration_m_value = '1'
                 dl_members       = lt_users ).
*    importing
*      et_success       = et_success
*      et_fail          = et_fail
     catch cx_crm_bm_exception .
  endtry.

I wonder how many times someone stuck their finger into SAPMSSYD before the developer included this warning…

*///////////////////////////////////////////////////////////////////////
* C A U T I O N:
*///////////////////////////////////////////////////////////////////////
* If you want to add a specific handler within a main step handler,
* make sure to follow the following
* G O L D E N  R U L E
* If you do not know, what a dynpro is:    HANDS OFF
* If you do not know, what a main step is: HANDS OFF
...
* N E V E R  prototype here. You may damage the system seriously.
* The worst case will lead to a system, where nobody can login.
* It will be your job, to spend the following night in your office
* to repair the system.
*///////////////////////////////////////////////////////////////////////

The thing is that I discovered this comment late one night many years ago after implementing a login screen for RF scanners using SAP Console. The process is described in Note 365664. I ignored the part of the note that said “Please, change only the layout!!!!” and tried to include a subscreen or module(can’t remember why).

The result was that nobody could log into the system. The reason is that the code in the login program SAPMSYST is hidden(try to view it in SE80:-) ). As soon as this program is modified, the hidden code is lost(…it took me a while to figure out what the heck happened).

The only way to fix this error is to transport program SAPMSYST from a working system into the broken system.

–Update: Please note there are issues with this Enhancement after applying CRM 7.0 SP 5 & 6. I will try to get hold of the fix, but it may better to investigate other options–

Overview

This post describes the enhancement of the IC WebClient using the Business Transaction Search in CRM 5.0. The Business Transaction Search (BT Search) allows you to define an index table that can be used as an alternative to the standard reporting framework.

As this is really too much to information to put into a post, I just placed an extract here, and created a PDF(containing code, screen shots, etc) that can be download here:

Inbox BT Search Documentation

Benefits

The BT Search allows you to overcome a number of common problems encountered in the Inbox, namely:

• Poor performance
• Custom Search Fields
• Inconsistent Search Results

The typical IC WebClient Project deals with all 3 of the above problems. Poor performance is almost inherent to the standard Inbox as the database structure of the One Order Framework is extremely flexible, but complex.
If you add custom search fields to the Inbox, you must either implement filters in the AFTER_SEARCH method of BADI CRM_IC_INBOX_BADI or you must implement BT Search. Using filters is always a bad idea, as performance suffers and they lead to unexpected results.
Finally, the Inbox is used to select Interactions, Service Tickets, Follow Ups, Sales Orders, etc. All of these transactions have different customizing settings and it is sometimes impossible to align all of them in the standard Search Results. BT Search allows you to do this.

Steps

The BT Search allows you to define an Index Table in the IMG. The IMG transaction will generate the following components for you:

• A Database Table that will be your “Index”
• An initial load report for populating the Database Table
• A Badi Implementation (ORDER_SAVE) used to populate the delta entries to the Index when a document is saved.

However, you will have to modify the generated Report and Badi in order to achieve the desired results.
You must also create an Implementation of Badi CRM_IC_SOS_INDEX in order to determine the Index to be used.
An implementation of Badi CRM_IC_INBOX_BADI will also be required for doing some fancy footwork.
The rest of the document will describe the required steps in more detail.

Enhancement Scenario

The enhancement described in this document caters for the following requirements:

• An Index only for Service Tickets and Follow ups
• Multiple Customer Specific Search Fields
• Customer Specific Result Fields

Caveats

BT Search completely replaces the standard search. It’s a lot of work as you really end up rebuilding the entire search logic of the Inbox. The BT Search is not a simple enhancement. It needs a lot of tweaking. This document assumes that the reader has an understanding of One Order documents, their customizing and ABAP knowledge.

This document is only applicable to CRM 5.0. The BT Search functionality has changed significantly in CRM 2007 and many of the problems and solutions described here will hopefully not be encountered. I have not verified this beyond the point of looking at the customizing tables in CRM 2007.
This document does not deal with adding additional search parameters to the UI or the BOL. That is a separate topic on its own. Here we assume it has already been done.

I have not tested this Index with an Inbox containing Workflow Items or E-mails as well. Some code in this document may be incompatible with Workflow/E-mail Items, but I just don’t know.