Happy holidays everyone! Be careful on the roads out there this week! And watch out for crazy drivers wearing call-center telephone headsets!

What in Steve Jobs' name am I talking about you ask?

Well, in case you haven’t heard already, this week is, “National Customer Service Week!” I’m not making this up. It’s a real thing. Back in 1992 the United States Congress declared that the first week of October would be an annual nationally recognized event. And to seal the deal, George Herbert Walker Bush signed it into law.

National Customer Service week was created to help raise awareness of the vital role front line employees play in organizations. This holiday isn’t just for call center agents, but for anyone who works on the front line dealing with angry, disgruntled, iPhone wielding customers! This also includes front-desk staff, field service technicians, delivery drivers, airport ticket agents, hotel doormen, service dogs, coffee house baristas, or anyone else whose job involves placating whiny “customers”.

National Customer Service week is not some frivolous make-pretend holiday like “Sweetheart’s Day” dreamed up by greeting card companies. No, this is a genuine national holiday, as revered as Christmas or the Independence Day! It is our duty as citizens of the business world to honor those men and women on the front lines who sacrifice their sanity on a daily basis to keep us safe from the unruly mobs of angry customers.  

So, how should companies celebrate National Customer Service week? Do you just hand your call center agents a “#1 Service Rep” coffee mug stuffed with an Amazon.com gift certificate and call it a day? Sure… If you’re completely lame. Otherwise, you might want to think up something a bit more creative and motivational like theme days, awards ceremonies, cubicle decorating contest and other ideas. As a rule of thumb, err on the side of fun rather than stuffy. Even if employees find it corny, they will still appreciate the effort and crack a smile.

One of the best examples of employee motivation efforts I’ve ever seen came from an actual SAP customer in the pharmaceuticals and medical products industry. As part of their CRM upgrade project the company wanted to increase employee buy-in. They spared no expense in their change management initiative which included all of the normal activities like end-user training, super-user champions, viral videos and collateral, and on-site technical support. But in addition, they also added an element of fun. For example, the call center managers would dress up in cheerleader costumes and run through the call center cheering on the service reps. Silly? You bet!. Effective? More effective than you would ever believe!

Enter the Contest

So, with that in mind, here’s the contest. What’sthe best employee motivation initiative you’ve ever conducted at your company or heard about at another company?Please leave a short description in the comments section below briefly explaining the initiative and the results.

All contest entrants will receive a free conference pass (SAP customers only; no vendors) to the Technology Services World (TSW) conference in Las Vegas, Oct 15 - 17 (entrants are responsible for their own hotel, transportation and expenses). In addition, one winner will be selected at the end of the week. The winner will receive a no-expenses paid "date" with SAP customer service guru John Burton. The “date” shall take place either at SAP’s Palo Alto headquarters or will be conducted virtually for customers located outside the San Francisco Bay Area. Topics of conversation for the “date” shall be limited to questions about SAP CRM Interaction Center/Service functionality, SAP CRM upgrade tips and best practices, Social CRM tactics and strategies, etc. Sorry, no hand holding, back massages, or parting kisses on the cheek .

*** Disclaimer: Event scheduling is subject to John Burton’s availability. SAP reserves the right to amend, modify or terminate this promotion in its sole discretion.

Creating the new button involves the following four steps:

1. 1. Enhance the component and view

2. 2. Create a method to create the button

3. 3. Call the new method from the do_prepare_output

4. 4. Implement the event to be triggered when the button is clicked

5. 1. Enhancing the component and view
   First enhance the component and enhance the view. How to enhance a component and a view can be found here.

2. Creating the method to create the button
In the workbench, navigate to the implementation class of the view. The implementation class is located directly under the view controller. The implementation class typically ends with '_IMPL'.

Double click on this Z-class. If the class does not start with a Z, you have either not enhanced the view yet, or you should go one screen back and re-open the component in the workbench.

In the attributes tab, create a new attribute called GT_BUTTONS (Instance Attribute, Public) of type CRMT_THTMLB_BUTTON_T

In the Methods tab, create a new method called 'CREATE_TOOLBAR' or 'CREATE_BUTTONS' (Instance Method, Private).

In the Method, add the following code:

---------------------------------------------------------

  DATA: ls_button     TYPE crmt_thtmlb_button.
CLEAR gt_button.
ls_button-type     = cl_thtmlb_util=>gc_icon_add
ls_button-text     = text-001.
ls_button-on_click = [name of the event].
ls_button-enabled  = [abap_true|abap_false].
ls_button-id       = [ID].
APPEND ls_button TO gt_buttons.
CLEAR ls_button.
---------------------------------------------------------

One of the variables is the name of the event. You can name this event anything you like. For instance 'create_line' or 'edit_line'. The implementation of the event will be done in step four.

 
The following attributes are available to buttons, and can be set:

ID   
Identifies the button at runtime
TEXT   
This is the text as displayed on the button -Keep it short!-
TOOLTIP   
This is the text that shows when the mouse hovers over the button
ON_CLICK   
This is the event that is raised when clicking the button
ON_CLIENT_CLICK
???
ENABLED
If this is set to false, the button is greyed out, and cannot be clicked.
ICON_SRC
This can be used to refer to an externally located gif image, i.e. '/sap/bc/bsp/...../w_pdf__s.gif',
TYPE
This is used to add standard icons to the button. The available set can be found in cl_thtmlb_util, in the attributes tab.

3. Redefine the do_prepare_output to call the method as defined in step 2.

In the view, navigate to the Request Processing, and redefine the method do_prepare_output.
How to redefine a method can be found here.
In this method, call the newly created method to create the toolbar buttons.
This would be a statement like create_toolbar( ) or create_buttons( ).

4. Create the event to be raised when clicking the button

'Event Handler'. Right click on it, and click on 'create'. Create an event with the exact name as coded in step 2.

The system will now create a method within the event handler called 'EH_ON[event_name]'. Double click this event to enter the logic to be performed when clicking the button.

Examples:
Having the button switch between edit and change mode.
me->view_group_context->set_view_editable( me ).

Call a transaction launcher transaction.
In order to navigate to a screen or launch transaction in the coding, you should customize a 'Generic OP Mapping' in the nav bar profile.

IMG:
SAP IMG -->  Customer Relationship Management --> UI Framework --> Technical Role Definition --> Define Navigation Bar Profile.

Within the nav bar customizing transaction, Select the correct profile, and double click on 'Define Generic OP Mapping' on the left side of the screen.

Add a line to the table where you map the new object name to an existing logical link. You can use this object name in the coding to call the logical link. The action should be the same as the action as customized in the OP Mapping.


---------------------------------------------------------
DATA: lr_col            TYPE REF TO cl_crm_bol_bo_col.
DATA: lr_nav_descr TYPE REF TO if_bol_bo_property_access.

lr_nav_descr = cl_crm_ui_descriptor_obj_srv=>create_ui_object_based(
  iv_ui_object_type   = [name of the object type]
  iv_ui_object_action = 'D' ).

CREATE OBJECT lr_col.
lr_col->if_bol_bo_col~insert( iv_bo    = lr_nav_descr
  iv_index = 1 ).

op_tobt( iv_data_collection = lr_col ).

---------------------------------------------------------------------------

If you do this, you should also implement the outbound plug op_tobt.
This outbound plug contains the following coding:

---------------------------------------------------------------------------
DATA:
lr_window      TYPE REF TO cl_bsp_wd_window.

lr_window = me->view_manager->get_window_controller( ).
lr_window->call_outbound_plug( iv_outbound_plug   = 'TOBT'
  iv_data_collection = iv_data_collection ).

--------------------------------------------------------------------------------------------------------------------------------------

Following are the Configuration steps if you want map custom Business Partner relationship category in SAP CRM to Partner Function in SAP ECC Customer master

For example : if you are mapping "Has the Primary Location" Relationship Category on SAP CRM Business Partner to "Primary Location" Partner function on Customer in SAP ECC. You can use these steps to configure your own SAP CRM Business Partner Relationship Categories and Map that Partner Functions in SAP ECC.

Test case :

SAP CRM :

TX : BP

SAP ECC :

TX : XD03

Following are the Customizing settings in SAP CRM and SAP ECC.

SAP CRM SPRO :->

• Step 1.  Go to "Properties of Business Partner Relationship Categories"

• 2.     Press F8
  

• 3.   Click on Business Partner Relationship Categories

• 4.  SAP CRM SPRO :

     Go to "Define Partner Functions"

• 5. Press F8

• 6.    SAP CRM SPRO

Go to "Data Transfer'

• 7  Press F8 : "Distribution of Partner Functions from SAP ECC into CRM"

• 8 Press F8:  "Distribution of Partner Functions from CRM to SAP ECC"

Now go to ECC

• 9   SAP ECC SPRO

            Go to "Partner Determination"

• 10     Press F8:

• 11 Select  Partner Determination Procedure "ZAG"12

• 12  Double click on "Partner Functions" on the left

• 13  Mapped Partner Function "ZP"

Note : The above Customizing steps are related to Mapping only. Assumption is that Partner Functions and Partner Determination Procedures are already defined in SAP ECC system.

Within SAP CRM, actions are pieces of logic that are related to a transaction. They are executed conditionally, either automatically or manually. Examples of actions are: sending out an order confirmation after saving the order, creating a follow-up task when a certain status has been set, or completing an order after a period of time. These actions are all available in the standard system, but you can easily create your own actions and assign them to your own pieces of logic (called: action method) and conditions.  Besides giving a quick overview of what actions are about in this blog, I’d like to share some ‘expert’ tips and tricks that I’ve learned over the years, including action profile determination, a relatively new and little known functionality that was introduced in CRM 7.0.  In this blog, I'll focus on action profiles and action determination. In the next blog, you'll read all about action conditions.

Action profiles

Actions are defined within an action profile, which in turn is linked to a transaction type or an item category (see also the next paragraph on determination). In the action, you can set up a number of parameters, including:

1. When the action should be executed (manually/automatically, for instance)
2. Whether the action is partner dependent or not (and, if so, for which partner function)
3. How often the action should be executed
4. What should the action do? Options include:
   1. send out a mail/fax/print
   2. execute a method (either standard or self-made)
   3. trigger an alert

Example of action details

Common profiles

If you want to reuse action profiles you can setup a common profile and assign it to other profiles. This can be very helpful if you have some (but not completely) overlapping action requirements for similar objects. Maybe an example clarifies this:

• In a quotation you’ve set up two item categories. In both cases, you’d like a follow-up task to be created in case the item status is set to ‘Lost’.
• In only one of the item categories, you’d also like to setup an additional action send out an e-mail too.

You should thencreate one common profile with the follow-up task action, and create two action profiles in which this common profile is linked. In one action profile, you also set up a second action for sending out the mail.  Advantages of such a setup with a common profile include:

1. unique actions can be maintained more easily, and
2. additional requirements can be made available with less effort (think of a third item category with yet another combination of actions).

Setting up common profiles

In the picture above you see how to work with common profiles. Creating a common profile is simple: you create an action profile and flag the Common Profile-flag. You can then select the profile for use in a normal action profile. 

Hint: conditions are setup for the 'complete' profile, i.e. a combination of the actions from the used common profile and the actions of the normal action profile. So: you can reuse a common profile in several action profiles and still have flexibility in the prerequisites (conditions)! 

Action profile determination

In older versions of SAP CRM, you could simply assign an action profile to a transaction type or an item category. Once linked, every new object would include all the actions of the profile that is linked to it, and that's that. Being quite rigid, this sometimes necessitated the creation of another item category or transaction type, only because you needed more flexibility. This has been overcome by the introduction of action profile determination.

Where to find action profile determination in IMG

The principle is quite simple: instead of linking an action profile directly, you can opt to link an action profile determination procedure to a transaction type or an item category. It works exactly like a price procedure: you can use fields from the field catalog to set up condition tables and you set up a number of access sequences to find the correct action profile(s).  Please note the (s) in the last sentence: it is possible to find multiple action profiles, or to both assign a profile directly and have one found through the determination. This can easily be called a small revolution in action customizing in CRM: it is now no longer required to put all the actions you need in one single action profile! Companies can use action profiles in much more flexible ways by combining the action profiles they need in specific scenarios.  I've used this determination technique to be able to have one single item category with different action profiles based on the product that was entered. In the example below you see how this was done.  Please note that in this case, we put the product ID directly into the condition, but you could also use product groups or hierarchy levels to set up this functionality. Because a field catalog is available, you can use any of the fields you use in pricing to determine action profiles.

Example of determination

The picture above shows how action profile determination works. As usual within SAP CRM, the logic at runtime needs to be configured the 'other way around':

1. Create or re-use one or more condition types
   1. You can create your own condition tables
   2. Do not forget to link the condition type(s) to a (new) condition maintenance group
2. Create the conditions
   1. This can be done via general condition maintenance
3. Setup an action determination procedure
4. Assign the procedure to the transaction type or item category

This ends this blog. In the next blog, I'll focus on action conditions.

In the previous blog I've discussed how action profiles can be set up and how it is possible to reuse actions and be more flexible in determining profiles through common profiles and action profile determination.

Now, let's turn to action conditions. Especially if you plan to use a lot of actions in your processes, setting up conditions the right way will prevent performance problems and allow for future reuse.

Action conditions

So, actions have been created and correctly linked (or determined) via the profile. Time to focus when to execute them. This is done with action conditions. You can base them on attributes from the transaction or item at hand. Probably most often used are attributes like user or system status, priority, or a milestone.

There's a few tips and tricks here that I'd like to share, but let's start with the difference between the two types of conditions that are available in SAP CRM.

Schedule vs start conditions

Schedule conditions define when an action is put on the list of executable actions within the object. Once it is put there, it will be executed as soon as the start condition is met.

• By not assigning a schedule condition, the action will be added to the list of executable actions automatically or manually.
• By not assigning a start condition, it is possible to execute the action  automatically or manually.

This seems quite straightforward, but there's more to it:

1. Once an action is scheduled, it will be considered during a (background) run of the action selection report. This impacts performance of the jobs you plan to use.
2. If you want to tirgger actions based on a milestone (e.g., contract end date has passed), you should use a Start Condition: schedule conditions are only checked if there is a change in the transaction and this means that the contract end date has long passed before the transaction is 'touched' again and the action is finally executed.
3. You can assign both a schedule and a start condition to one action. In such cases, the start condition is only considered if the action's schedule condition was fulfilled.

As these points show, there is a conflict here: using too many schedule conditions may impact performance, but only using start conditions disallows you to plan actions based on milestones.  Later, we will look into the solution that SAP provides for this, and milestone-based actions in general. Let's first discuss setting up conditions in general, and running a background job.

Setting up action conditions

When you click on Define Conditions in the customizing, you will see the following screen:

Action Condition Maintenance

I won't go into all the details of this screen, but I would like to highlight a few elements:

• with the Technical Names-button you can switch between the description of the action and action profile to the technical names. This can be very handy if you have non-unique descriptions
• setting up conditions is done with an editor in which you link attributes to values with help of expressions.
• you can reuse conditions after you created them (you can get an overview of all conditions by cllicking on the Schedule Conditions or Start Conditions-buttons). 
  • Reusing conditions is particularly useful if you are using common profiles. As highlighted in my blog on action profiles, common profiles can be used to reuse actions in various action profiles without having to configure them again and again. These embedded actions' conditions need to be set up per action profile that uses them. By reusing these conditions, you can easily do this.
  • Please note that reusing conditions is only possible within: 
    • the same type of condition (schedule / start)
    • the same item category
  • As a general rule of thumb you should consider a naming convention for your conditions (e.g.: [item category] [description of condition]). Too often you see condition names that tell more about the action that they are linked to, than what they actually check. Reusing them will then be quite hard!
• If you want to setup an action without any conditions, you should still add it in this screen (right top corner). If you forget this, the action will not work.

Executing actions

Now that the action profiles, its actions and conditions are set up, it is time to see how actions are executed. As you recall, there are three moments on which actions are executed:

• Immediate processing:as soon as the action should be executed (either by an automatic or a manual trigger), it will be executed. Typically, an end user is working in the transaction when this occurs. 
  • This option will lead to wait time for the end user. Therefore, I would only advise it if user feedback is required or if the action is highly time critical.
• Processing when saving the document:when the user or a background process saves the order, the action is executed. 
  • This option may also impact the end user's experience.
• Processing using selection report: during order processing, the action(s) will only be  scheduled. Execution will be done by running the action processing program (transaction code: CRMC_ACTION_JOB).
  • Within action customizing you can allow end users to execute the action directly, so they don't need to wait for the program to run.
  • Let's look into the action selection report with some more detail.

Milestone-based actions

Setting up an action that should be executed after a period of time can seem quite tricky at first. This is because a number of elements should be correctly setup before the action is actually scheduled at the right moment. These are the things you should get straight:

1. Set up a date profile to calculate your milestone
   1. Hint: give different names to the date types and date rules, even though this is not required
   2. Be sure to include the standard date rule TODAYTIME in your profile (this will always give the current date+time when executed; we will need it in the next step)
2. In action condition maintenance, create a start condition that checks whether TODAYTIME is greater than or equal to the date type

Now let's assume we want to run a hourly background job that executes actions. This would have to check all start conditions with milestones again and again, even if the milestone will not be reached within another 6 months! That's why optimization rules were introduced.

Optimization rules

With help of optimization rules, you can have the background job calculate when the start condition will be met. In the example above, in six months time. The system will write this in a table and, the next time the job is executed, simply skip the start condition because it already found that this condition is not yet met.  This functionality improves performance and requires two configuration activities:

1. In the action condition maintenance, select the date type that you want to use as an Optimization Rule. If you look at the previous picture, you can already see that an Optimization Rule was linked.
2. In the action job, be sure to flag the Use Optimization Rules option.
   1. Note: typically you run this report in a background job. Make sure to set up the variant attributes like in the picture below. it ensures that each time the job is run, the current date and time are considered.

Earlier this week SAP announced at SAPPHIRE Madrid that SAP CRM would be on put on HANA as part of a larger application offering called SAP 360 Customer.  This solution would surround the existing SAP CRM and sales on demand solutions.  I was not at SAPPHIRE Madrid, but was able to get a sneak peak of the SAP CRM on HANA and like all of you went through the publicly made materials on the solution.  That being said I feel that most analysts don't fully get ramifications of what this means when it comes to current on-premise SAP CRM soslution.  Even though SAP can make statements like X amount faster it means nothing if we don't understand the bottlenecks of the current SAP CRM system and how HANA can turbocharge the system.

SAP CRM: A search based system

For those of you who don't work with an actual SAP CRM product on a daily basis as either a user of the system, tech support/consultant or developer may not realize that user interface requires you to either create or search for data as your first step in dealing with any type of data.  We can divide these searches into two primary types: master data and business transactions.  I'm not going to go into the full data model, as one could write part of a book on that topic but let's take a quick look at the difference between the two.  Master data in CRM terminology is generally the same as ERP Master Data.  CRM Master Data includes data such as customers, prospects, contact persons and employees which in SAP CRM terminology are business partners.  In addition goods or services that may be sold are known as products.  Business Transactions describe an interaction between business partners where a communication or exchange of goods or services takes place.  Common examples are customer visits(activities), customer complaints, sales orders, service requests, etc.  In CRM we have two primary ways of looking up data.  We can take a "customer centric" approach or "interaction centric" approach.  The customer centric approach involves finding the overview screen of an account and then looking at the related data.  The interaction centric approach involves looking for a particular type of interaction in the system for a broad range of criteria.

As you can tell from either approach we must search for data before it is brought up.  In the customer centric approach we bring up a business partner and then several "searches" are executed in the background that show the related data.  This related data includes transactions that are related to that business partner and in addition other partners that are related.  For an interaction centric approach we bring up a search screen for a particular type of interaction(sales orders, complaints, leads, etc) and then provide criteria that may cross one or many business partners.  In both cases however we are always executing the same technical search code in the background the difference is that on part of the UI the search has been automatically limited to a single business partner where in the interaction centric approach we not limited to a single business partner unless we choose this.  In both cases the searches executed end up being part of the day-to-day usage of the business users of a SAP CRM system.

Business Transction Search Performance Problems

The business transaction search can be very slow if there were no optimizations to made to it.   The reason being is that business users rightfully demand the ability to search on almost any attribute of a business transaction.  As we understand that if we try to perform searches on a OLTP data model we always encounter tradeoffs when search.  The code for searching for business transaction in SAP CRM is quite complex and can make your head spin when you look at it for the first time. Some of the early attempts to optimize the search involve built-in tables within CRM to index the data for searches.  The most infamous table CRMD_ORDER_INDEX is a table that adds no business value beyond making transaction search feasible in SAP CRM. 

Speed up Search, Speed up SAP CRM

As SAP has realized that search is a key bottleneck in SAP CRM attempts have been made to speed it up.  With introduction of Enterprise Search tools using the TREX SAP has been able to offer ways to speed up search by adding on additional layers.  However the drawback of these approaches is that data must still be indexed and requies additional landscapes to manage.  This is where the promise of of SAP CRM on HANA comes in play.  For the first time in the history of SAP CRM we can actually remove layers to gain performance optimization.  By using in-memory computing to power the search on the same database our searches have the promise of not causing the "wheel of death" on the SAP CRM system to be shown.  That promise of speeding up a fundamental use case within SAP CRM why I see the true value of putting SAP CRM on HANA.  Once we no longer have to worry about performance there are so many other creative things we can dream up such as "real-time segmentation of our customers" instead of waiting for sales data to be available and a batch job to run to put our customers in the correct market segment.

Wait aren't you some salesperson, or getting paid for this?

As I said earlier beyond getting a sneak peak, I have no paid involvement with promoting this.  My opinions reflect the materials made available to me about the solution and my experience working with a current SAP CRM 7.0 on standard database from a technical support perspective.  The wheel of death is the number one complaint of my CRM users and any solution that promises to eliminate that grabs my attention.  As the old saying goes the "devil is in the details", it will be interesting to see the cost, time, and effort to migrate existing SAP CRM customers to the platform.  If the cost and effort are reasonable and can provide the expected ROI, I would expect the general excitement and adoption to be faster than the webclient UI.  Yes we can always throw more hardware at a SAP CRM system to make it faster, but I think this is case where instead we are trying to treat the cause of the problems instead of the symptoms.  I think the real debate will be on ROI and effort and not on the fact that performance will increase.  That being said this is not recommendation to drop what you are doing and go install this immediately.  Rather I feel that all SAP CRM Customers must take a hard look at this solution and can not look the other way anymore when it comes to HANA. 

Organization Management

The organizational structure is very important within SAP. This is used in most of the master data like customers, products and price conditions, in transaction data like orders and in customizing settings like pricing procedure determination.
Within SAP CRM the organizational structure can be setup manually, but normally this is copied from the available SAP ECC organizational structure.

Organizational model

Organizational model is used to represent the functional structure of a Company.

·         Company can be defined as a group of company codes.

·         Company code can be defined as balance sheet with a unique country and currency.

·         Sales organization can be defined as a logical entity which is legally responsible for all the sales activities in an area.

·         Distribution channel is the path through which the product reaches the end customer.

Eg:  dealers, stockiests, retailers etc.

·         Division can be defined as a product line which consists products with the similar characteristics.

·         Sales office can be defined as a physical entity from where sales activities are carried out.

·         Sales group can be defined as a group of employees who are responsible for carryout sales activities in a sales office.

Organizational model of CRM consists of two elements.

1. Organizational unit:logical unit/entity.Organization unit: Irrespective of what we are modeling, top Level Org Unit or a Regional Head Office, they are all represented using an “Org Unit”. For every organization there should be some positions or roles defined like CEO, GM, etc.  

2. Position                  : Functional Task Distribution. The second key element in SAP CRM Org Model is Position . CEO, Regional Sales Manager, Marketing Executive etc are all examples of position. Each position is filled by either a User or an Employee. As usual, you can freely define positions.

If you specify a function for an organizational unit, this information is inherited by the lower-level organizational units.

You can assign certain general attributes to organizational units when creating your organizational structure. General attributes are always related to a specific function, which means you can maintain different attributes for each function.

General attributes define the responsibilities of an organizational unit.

You can assign several attributes to an organizational unit.

You may define additional attributes for your company (table/view T77OMATTR).

Figure: Functions for Sales

The sales organization is the leading organizational unit for sales. You must always define at least one organizational unit as a sales organization in order to map standard processes for sales and service in the CRM system.

Sales offices and sales groups are used to map the internal organization.

The service team is a service group, which executes the service tasks. It is relevant for resource planning.

The service team is a service group, which executes the service tasks. It is relevant for resource planning.

You can use the marketing organization characteristic as follows:

For authorization checks: You can use the marketing organization in authorization checks, for example, to determine whether a user is authorized to change a particular campaign.

For automatically entering and checking marketing attributes: The system can use the marketing organization to make standard entries for particular fields in the available marketing planner.

For partner determination: For example, you can use the marketing organization to determine the suitable marketing manager for the assigned marketing organization and then to assign this to the campaign (on the partner tab page).

Advantages of CRM Organizational Model:

·         The full structure of a company can be maintained .

·         The sales offices can be created directly under sales organizations.

·         Validity periods / Time stamp can be maintained.

·         Flexible and adaptable.

·         Positions can be maintained to which employees are assigned.

·         Same structure can be maintained for both sales and service.

Process Flow: 

Path :

      SPRO -> SAP Ref IMG -> Customer Relationship management -> Master Data ->

                    Organizational Management -> Organizational Model.

                                                  (or)

                Create SAP CRM Org Model  using Transaction code -    PPOCA_CRM

                Edit/Maintain Org Model using Transaction code      -    PPOMA_CRM

While creating organisation unit we have four tabs those are Basic data, Address,

Functions and Attributes.

Basic data contains details like name of the organisation, description and valid period.

Address tab contains adress of the particular organisation and other details like email,

phone number.

Functions tab contains which function that particular org unit belongs to, whether it is

sales, service or marketing.

      In sales we have sales organisation,  Sales office and Sales group.

      In service we have service organization, service team.

      In marketining we have marketing organisation.

Attributes tab contains Country, Tupel, Division, etc. These fields will vary depending on

the function.

Create the organizational unit, In Basic data give the name and description and save.

To assign a CEO first we will create a position CEO and then assign the business partner. For this right click on the org unit there we can find the options create then we will get two options Organizational Unit and Position in those we will select position.

After creating position by right click and assign we can give business partner for that particular role. While creating we will get two options Business Partner and User. Business partner is the one who is related to the organization and User is the one who is on contract.

Now under this we will have sub units IDES US, IDES UK, IDES DE and different departments for different functionalities.

We can select the functionality in function tab.

Similarly for service and marketing we can assign the corresponding organizations.

I meet an interesting issue recently.

There is the request to change system status to I1005 in some special logic. FM CRM_ORDER_MAINTAIN is used to change the system status. But it does not work. After long time debugging, I found that system checks the user status profile to see whether the system status I1005 could be set or not.

My user status profile is configured as:

User status Z003 is mapped to business transaction FINI, thus system does not allow changing the system status to I1005 with CRM_ORDER_MAINTAIN. There are also logs found in the system status analysis:

System status 'Completed' (short 'CMPD', technical short form: 'I1005') is inactive

Status 'Completed' cannot be set

Transaction 'FINI' to change status 'Completed' used in status profile

The solution is simple, in the 'Transaction Control' of user status Z003, add the entry:

The issue was solved. I think the check makes sence. Both system status and user status can infunce the business transactions. If the user status does not allow the setting, there might be inconsistancy caused.

A couple of days later, I realized there is another way to solve the issue: making above setting in my user status profile, then use FM CRM_ORDER_MAINTAIN to change the user status to Z003, system will set system status I1005 automatically.

The system is clever, isn't it?

More information can be found in Status Management in Business Transactions http://help.sap.com/saphelp_crm700_ehp01/helpdata/en/48/db7fe063f45c97e10000000a42189d/frameset.htm

Have you ever been in a situation when you wanted to gain insight into a large amount of your enterprise data? I’m sure most of us have. How long do you think such a task would take? Considering interfacing with IT, processing and requisitioning the right queries and other associated aspects, I would safely guess a couple of weeks? Not anymore! SAP Business Objects Explorer is a web based search and exploration application that allows you to process huge volumes of data at an unbelievable speed.

In this video, I demonstrated some of the capabilities of SAP Business Objects Explorer. What is also interesting to note is the integration of SAP CRM, SAP’s leading solution for customer management, with SAP Business Objects Explorer that can be easily achieved by customers. Additionally, if you observe the video closely, there is an important aspect that should be evident – traditional reporting solutions involve the user running a ‘pre-defined’ report to extract information that would offer insight into the enterprise data. As the report is ‘pre-defined’, the user is aware of the kind of information that is being sought. While this is useful in many cases, this often results in ignorance of key trends and indicators which could escape the purview of such ‘pre-defined’ reports. However, with SAP Business Objects Explorer, there is a great emphasis on discovery. Rather than running defined reports, you are able to slice and dice huge volumes of information the way you want. And by doing this, chances are that you will uncover important trends and indicators which could have a significant influence on your business in the near future. You are thus able to identify and take note of these trends and act before it’s too late.

SAP Business Objects Explorer is a revolutionary tool that makes exploring huge volumes of data quick, easy and intuitive – thereby driving your productivity up and bringing your dependence on IT down.

As a functional consultant, you probably write functional specifications now and then. Even though the SAP CRM solution offers many ways to customize processes, some enhancements are needed to fulfill the few business requirements that cannot be met by standard functionality. With help of business add-ins or the possibilty to link your own function modules in customizing, SAP CRM can of course also cater for that. But SAP CRM cannot ensure that these enhancements are built in a future-proof way.

Only too often I encounter developments that contain hardcoded values or that apply to the system as a whole. Before we go over the most important options to overcome this in more detail, let's first quickly look at the disadvantages a customer might encounter if enhancements are built in a rigid or hardcoded way. Examples of disadvantages are:

• A change in customizing requires a change in coding
• If new business units want to use the system, but do not want your specific enhancement,  a change in that coding is needed
• Once-built logic tends to be forgotten, leading to additional costs when extending or upgrading the system later

So, how can we ensure that enhancements are controllable functionally? With this blog I aim to shed some light on the little-known yet highly powerful parameter options that are standard available in SAP CRM.

Introduction

Parameters can be used to steer logic: programmers can check the value of a parameter before apart of the logic is processed. A parameter can be a simple on/off switch or it can contain a value that would be hard-coded otherwise.

Available parameter types

User parameters

Purpose

If you want certain logic to be only available to certain users, this is the way to go. You can setup additional parameters to your own liking

(Dis)Advantages

Possible to switch on/off or adapt the logic on the lowest possible level: the user. More work to setup and maintain though.

Setup

You can create your own user parameters via SM30 in table TPARA. From then, you can set the value for a user through SU3 (your own user) or SU01 (any user).

What to put in the specification?

From the coding, the parameters and values of a user can be retrieved. Values are stored in table USR05.

Organizational attributes

Purpose

You want certain logic, that might be executed in the background, only to apply to (e.g.) certain sales organizations.

(Dis)Advantages

Can be setup on high level and then inherited to the lowest, where it can be overwritten if wanted. Downside is that the organizational model should be maintained for this.

Setup

You setup your own attributes in table T77OMATTR through SM30. First enter your new attribute (see screenshot). If you enter a description and hit enter, the table and field names are defaulted (SAP delivers a standard table in which all these attributes are saved).

You then link the attribute to the scenario (Sales, Service, or Marketing) and to the object type (for instance O for Organizational Units). You can even setup inheritance from higher- to lower-level objects. This way can you also setup attributes for positions and have those defaulted from the sales organization to which they belong, and overwrite the value if needed. The new attribute is then available in the list of attributes.

What to put in the specification?

You can add the hint to use function module RH_OM_ATTRIBUTES_READ to retrieve all attributes, including your own (if maintained, of course).

WebUI parameters

Purpose

Your end users work through the webUI and you would like specific logic to apply only to certain business roles.

(Dis)Advantages

You can assign parameter values to (big) groups of users rightaway. Needs to be customized and transported though, and only suitable for processes running or initiated in the webUI.

Setup

Parameters can be created through customizing (IMG > CRM > UI Framework > Technical Role Definition > Define Parameter). You assign the parameters and their values to a parameter profile. This profile can then be linked to one or more business roles as a function profile (ID = PARAMETERS, vallue = the parameter profile).

What to put in the specification?

There are standard possibilities to retrieve the business role that the user is logged on for.

Other parameters

Besides the parameter types discussed above, you can also think of other parameters in the system. Example include marketing attributes (freely definable fields in the account), and container parameters in action definitions (more information about actions can be found in my blogs). These will not be described in this blog.

Own table(s)

Purpose

If you have more complex requirements, it can be an option to define your own 'customizing' table. Many customers have one in which they can dynamically add parameters to their coding.

(Dis)Advantages

Much more 'steering' possibilities, but has the risk of being hard to understand.

Setup

Often, these tables are really 'for insiders only', and you know what tends to happen with insiders: they leave the company, forget they ever built it, whatever... The best structure I've seen was a combination of two tables: one in which the link between the object (FM/report/class, for instance) and the parameter was given, and another table with the actual parameters and their values. All programmers were required to use the first table to retrieve the parameter, and this ensured the tables were filled correctly. This enables every new kid to quickly see where what parameters are used.

Which to pick, and how to use them?

Which option you decide to use for the enhancement that you want to have built depends on how you want to limit the logic now, or in the future. The more the SAP CRM solution is used, the more these parameter options will be used. As a company, you should consider setting up guidelines for projects and changes to only build enhancmenets using the parameter options you have chosen based on your company's roadmap (think of: future roll-outs or additional functionalities). By using these parameters in a wise and consequent way, companies can benefit from the enhancement possibilities SAP CRM offers without having the risk that they cannot be managed anymore.

Preliminary note: this project was developed on SAP Netweaver 7.02 SP11 with GW 2.0 SP04 Developer edition available here... so actually there's no need for a CRM system to be able to play with it (despite the title of this blog), as soon as component WEBCUIF is present in your system.

Last year I wrote a blog post about a project that I created on code exchange: BMDG -- Bol Master Data Generator. It's a tool that allows me to create any kind of bol object. All I have to do is fill-in a customizing view with the expected rules: for example, if I need to create a business partner whose first name and last name are constant values together with address fields determined at runtime via importing parameters, I can do so by creating the corresponding "template", and then call BMDG with the template ID.

For more information kindly check the following links:

CRM7.01: what if you could create complex master data models in one click?

CRM7.01: secret weapon for data model creation

However, until now I was only providing the "engine". In other words, if you ever wanted to use BMDG you had to develop your own program and copy/paste the lines of code at the end of my previous blog post to make it work. And even if it represents only 7 lines of code, it was fair enough not to consider BMDG "plug-and-play".

Then last week a friend of mine asked me if I knew a tool to copy/paste marketing plans from Excel inside SAP CRM... I got no clue, but this rang a bell about BMDG: this tool is fully generic so any kind of bol object can be created with it. Also, as of SAP Netweaver 7.01 or 7.02, you can now copy/paste your data from Excel inside any WebUI table. Why not combine both worlds to be able to generate any data model out of a simple table view where users could paste values coming from flat files or Excel?

Sounded like something interesting to me. So I created a WebUI component, that is now shipped with BDMG (together with sample templates based on SFLIGHT model), to unveil the potential of this tool and finally make it "plug-and-play" compliant. Here is how it works:

1) Start WebUI component ZBMDG_UI:

2) Then select a template from the dropdown list:

Only those templates that contain values to be determined at runtime from an importing structure are displayed -- which means that if you created templates where all bol objects' attributes are filled-in with constant values for example, they won't be displayed in the list. As soon as a template is selected, the table is re-arranged automatically, so that you can now enter the values you need, or copy/paste them from Excel:

3) Click the "Import" button:

BMDG will run through each and every line of the table, to create the objects as per the corresponding template (of course there can be more than one object created per line depending on how the template has been customized). Once done, the result status is displayed in the first column, and you can click on the icon to display the complete log:

Here is a short video to show BMDG WebUI component in action:

If you're interested, feel free to join the project on code exchange, make comments, discuss about new features that could be implemented, and of course download everything free of charge:

BOL Master Data Generator

When I first started writing ABAP in CRM I was confronted with CRM_ORDER_READ and CRM_ORDER_MAINTAIN, and learning how to use these took much longer that it should have due to lack of simple examples available. Looking back I don’t know where my confusion lay (it’s really simple!) but I know there was confusion and trouble, so I will try to be provide help to others that I wish I’d had.

The aim of this blog is to create a simple example for CRM_ORDER_READ and then I will write another blog for CRM_ORDER_MAINTAIN.

This blog will show you how to read an order, and read details about it such as and Notes, and Partners associated, the Status and all the other basic information.

include crm_object_names_con.

data:
          lt_header_guids type crmt_object_guid_tab,          ls_header_guids type crmt_object_guid,          lt_orderadm_h type crmt_orderadm_h_wrkt,          lt_opport_h type crmt_opport_h_wrkt,          lt_status type crmt_status_wrkt,          lt_text type crmt_text_wrkt,          lt_partner type crmt_partner_external_wrkt,          lt_service_os type crmt_srv_osset_wrkt,          ls_orderadm_h like line of lt_orderadm_h,          ls_opport_h like line of lt_opport_h,          ls_status like line of lt_status,          ls_text like line of lt_text,          ls_partner like line of lt_partner,          ls_service_os like line of lt_service_os,          lt_request_objs type crmt_object_name_tab.

* 1. First you need to choose which tables you want to get back. 
* In this example I want to read 6 tables, so I need to add them into the “request_objs” table  insert gc_object_name-orderadm_h into table lt_request_objs.  insert gc_object_name-opport_h into table lt_request_objs.  insert gc_object_name-status into table lt_request_objs.  insert gc_object_name-texts into table lt_request_objs.  insert gc_object_name-partner into table lt_request_objs.  insert gc_object_name-service_os into table lt_request_objs.

* 2. Second you need to make a table “lt_header_guids” with all the guids in that you want to read
* These GUIDs are stored as RAW16 type, in the table, 
* so you may need to convert them from CHAR32
data: lv_guid_char type char32.
lv_guid_char = ’#32 char long GUID#’.
ls_header_guids = cl_ibase_service=>cl_convert_guid_32_16( lv_guid_char ).
append ls_header_guids to lt_header_guid.

*3. You’re now read to read! It’s that simple!
call function 'CRM_ORDER_READ'    exporting      it_header_guid       = lt_header_guids      it_requested_objects = lt_request_objs      iv_no_auth_check     = 'X'    importing      et_orderadm_h        = lt_orderadm_h      et_opport_h             = lt_opport_h      et_text                     = lt_text      et_partner                = lt_partner      et_service_os          = lt_service_os      et_status                  = lt_status    exceptions      document_not_found   = 1      error_occurred       = 2      document_locked      = 3      no_change_authority  = 4      no_display_authority = 5      no_change_allowed    = 6.

* sy-subrc = 0 if the read was successful. 





* If the read wasn’t it can mean that the GUID you entered isn’t valid/doesn’t exist.

For help with crm_order_maintain see: http://scn.sap.com/community/crm/blog/2013/02/07/crmordermaintain-simple-example-to-create-an-order-for-those-new-to-crm-andor-abap

and

http://scn.sap.com/community/crm/blog/2013/02/07/crmordermaintain-simple-example-to-update-an-order-for-those-new-to-crm-andor-abap

In a previous blog http://scn.sap.com/community/crm/blog/2013/02/07/crmorderread-simple-example-for-those-new-to-crm-andor-abap I gave a very simple example of how to use CRM_ORDER_MAINTAIN to create a new order.

This blog will show you how to UPDATE an order in CRM using ABAP.
I’ve tried to make this as simple as possible but while including the most important (useful) information.
In this example I will only update the orderadm and opport (opportunity) tables.

include crm_object_names_con.  data:  lt_opport_h        type crmt_opport_h_comt,  ls_opport_h        type line of crmt_opport_h_comt,  lt_orderadm_h      type  crmt_orderadm_h_comt,  ls_orderadm_h      type  crmt_orderadm_h_com,
*Other important things   lt_input_fields    type  crmt_input_field_tab,   ls_input_fields    type  crmt_input_field,   lt_nametab         type  crmt_input_field_names_tab,   ls_nametab         type  crmt_input_field_names,   lt_save_guid       type  crmt_object_guid_tab,   ls_save_guid       type  crmt_object_guid,   lt_saved_objects   type  crmt_return_objects,   ls_saved_objects   type  crmt_return_objects_struc,   lv_lin             type   i,   lv_order_object_id type  crmt_object_id,   lv_order_object_guid  type  crmt_object_guid32.

* 1. Update the description of the opportunity
clear: ls_nametab, lt_nametab[],
          ls_input_fields.    ls_orderadm_h-description                = ‘this is the new description’.    ls_nametab                               = 'DESCRIPTION'.    append ls_nametab to lt_nametab.
*** for help on how to change a CHAR32 to a RAW16 see my CRM_ORDER_READ blog ***    ls_orderadm_h-guid                    = ‘this is the GUID type RAW16’.    append ls_orderadm_h to lt_orderadm_h.    ls_input_fields-ref_kind = 'A'.     ls_input_fields-ref_guid = ‘this is the GUID again, in RAW16’.     ls_input_fields-objectname = 'ORDERADM_H'.    ls_input_fields-field_names[] = lt_nametab[].    insert ls_input_fields into table lt_input_fields.

* 2. Update the opportunity data in opport_h table – update the current phase and end date  clear: ls_nametab, lt_nametab[], ls_input_fields.    ls_opport_h-curr_phase                 = ‘code for new sales stage’.    ls_nametab               = 'CURR_PHASE'.    append ls_nametab to lt_nametab.    ls_opport_h-expect_end                  = ‘new date for expected end date’.    ls_nametab              = 'EXPECT_END'.    append ls_nametab to lt_nametab.
ls_opport_h-ref_guid                    = ‘this is the GUID again, in RAW16’.    append ls_opport_h to lt_opport_h.    ls_input_fields-ref_guid        = ‘this is the GUID again, in RAW16’.    ls_input_fields-ref_kind        = 'A'.    ls_input_fields-objectname      = 'OPPORT_H'.    ls_input_fields-field_names[]   = lt_nametab[].    insert ls_input_fields into table lt_input_fields.

* 3. DONE, call CRM_ORDER_MAINTAIN on this information
call function 'CRM_ORDER_MAINTAIN'
      exporting        it_opport_h       = lt_opport_h      importing        et_exception      = lt_exception1      changing        ct_orderadm_h     = lt_orderadm_h        ct_input_fields   = lt_input_fields      exceptions        error_occurred    = 1        document_locked   = 2        no_change_allowed = 3        no_authority      = 4        others            = 5.    case sy-subrc.      when 0.        ls_save_guid = iv_guid.        append ls_save_guid to lt_save_guid.
endcase.

* 4. SAVE the changes (all updates must be saved and committed before they change in CRM)
    call function 'CRM_ORDER_SAVE'      exporting        it_objects_to_save = lt_save_guid      importing        et_saved_objects   = lt_saved_objects      exceptions        document_not_saved = 1        others             = 2.    case sy-subrc.      when '0'.        clear lv_lin.        describe table lt_saved_objects lines lv_lin.        if lv_lin = 1.          read table lt_saved_objects into ls_saved_objects index 1.          lv_order_object_guid = ls_saved_objects-guid.          lv_order_object_id   = ls_saved_objects-object_id.

* 5. Call the function to COMMIT the changes to CRM.
          call function 'BAPI_TRANSACTION_COMMIT'.        endif.    endcase.
*DONE, your opportunity has now been updated.

In a previous blog I http://scn.sap.com/community/crm/blog/2013/02/07/crmorderread-simple-example-for-those-new-to-crm-andor-abap gave a very simple example of how to read an order using CRM_ORDER_READ.

Then in another blog I explained how to UPDATE an order: http://scn.sap.com/community/crm/blog/2013/02/07/crmordermaintain-simple-example-to-update-an-order-for-those-new-to-crm-andor-abap
Now I’ll give a simple example of how to create an order using CRM_ORDER_MAINTAIN.

This blog will show you how to CREATE an order from scratch using ABAP.
I’ve tried to make this as simple as possible but while including the most important (useful) information.
For this example I will create an order with two tables populated: orderadm_h and opport_h (which signifies that this is an OPPORTUNITY that I’m creating)

include crm_object_names_con.  data:
*      All the tables to be created  lt_orderadm_h      type  crmt_orderadm_h_comt,  ls_orderadm_h      type  crmt_orderadm_h_com,  lt_opport_h        type crmt_opport_h_comt,  ls_opport_h        type line of crmt_opport_h_comt,
* Other important things  lt_input_fields    type  crmt_input_field_tab,  ls_input_fields    type  crmt_input_field,  lt_nametab         type  crmt_input_field_names_tab,  ls_nametab         type  crmt_input_field_names,  lt_save_guid       type  crmt_object_guid_tab,  ls_save_guid       type  crmt_object_guid,  lt_saved_objects   type  crmt_return_objects,  ls_saved_objects   type  crmt_return_objects_struc,  lv_lin             type   i,  lv_order_object_id type  crmt_object_id,  lv_order_object_guid  type  crmt_object_guid32.
* Calculate the “handle” that will join all these attributes together   call function 'CRM_INTLAY_GET_HANDLE'    importing      ev_handle = ls_input_fields-ref_handle.
* 1. Populate orderadm_h with the process type and description  ls_orderadm_h-handle       = ls_input_fields-ref_handle.  ls_orderadm_h-process_type = ‘process type string’.  ls_orderadm_h-description = ‘this is a description’.  ls_orderadm_h-mode         = 'A'.  append ls_orderadm_h to lt_orderadm_h.
* 2. Prepare table first. 
* The lines you enter into table lt_nametab MUST be entered (appended) 
* in alphabetical order, as lt_nametab is sorted.
* See here that the 3 entried are the three attributes you populated in ls_orderadm_h above.  ls_nametab = 'DESCRIPTION'.  append ls_nametab to lt_nametab.  ls_nametab = 'MODE'.  append ls_nametab to lt_nametab.  ls_nametab = 'PROCESS_TYPE'.  append ls_nametab to lt_nametab.

* 3. Populate lt_input_fields now 
* You need to add this table that you want to create to the input fields.
  ls_input_fields-ref_kind = 'A'.  ls_input_fields-objectname = 'ORDERADM_H'.  ls_input_fields-field_names[] = lt_nametab[].  insert ls_input_fields into table lt_input_fields.
* 4. Prepare the next table you want to create for this opportunity: opport_h  clear: ls_nametab, lt_nametab[].
* 5. Populate ls_opport_h with appropriate values (see examples or attributes to populate)  ls_opport_h-ref_handle      = ls_input_fields-ref_handle.  ls_opport_h-exp_revenue     = iv_expt_sales.  ls_opport_h-startdate       = iv_sc_sdate.  ls_opport_h-expect_end      = iv_sc_cdate.  ls_opport_h-curr_phase      = iv_sales_stage.  ls_opport_h-probability     = iv_chanceofsuc.  ls_opport_h-source          = iv_origin.  ls_opport_h-type            = iv_serv_line.  ls_opport_h-mode          = 'A'.  append ls_opport_h to lt_opport_h.
* 6. Prepare the lt_nametab table – remember to be alphabetical again!  ls_nametab = 'CURR_PHASE'.  append ls_nametab to lt_nametab.  ls_nametab = 'EXPECT_END'.  append ls_nametab to lt_nametab.  ls_nametab = 'EXP_REVENUE'.  append ls_nametab to lt_nametab.  ls_nametab = 'MODE'.  append ls_nametab to lt_nametab.  ls_nametab = 'PROBABILITY'.  append ls_nametab to lt_nametab.  ls_nametab = 'SOURCE'.  append ls_nametab to lt_nametab.  ls_nametab = 'STARTDATE'.  append ls_nametab to lt_nametab.  ls_nametab = 'TYPE'.  append ls_nametab to lt_nametab.
* 7. Add to lt_input fields the new table you want to create.  ls_input_fields-ref_kind = 'A'.  ls_input_fields-objectname = 'OPPORT_H'.  ls_input_fields-field_names[] = lt_nametab[].  insert ls_input_fields into table lt_input_fields.

* 8. You’re ready to call crm_order_maintain now
call function 'CRM_ORDER_MAINTAIN'      exporting        it_opport_h       = lt_opport_h      changing        ct_orderadm_h     = lt_orderadm_h        ct_input_fields   = lt_input_fields      exceptions        error_occurred    = 1        document_locked   = 2        no_change_allowed = 3        no_authority      = 4        others            = 5. 

* 9. Read the table that has been changed and get the GUID that was created.
case sy-subrc.
      when '0'.        read table lt_orderadm_h into ls_orderadm_h index 1.        ls_save_guid = ls_orderadm_h-guid.        append ls_save_guid to lt_save_guid.
endcase.

* 10. SAVE the changes (all creations must be saved and committed before they exist in CRM)
    call function 'CRM_ORDER_SAVE'      exporting        it_objects_to_save = lt_save_guid      importing        et_saved_objects   = lt_saved_objects      exceptions        document_not_saved = 1        others             = 2.    case sy-subrc.      when '0'.        clear lv_lin.        describe table lt_saved_objects lines lv_lin.        if lv_lin = 1.          read table lt_saved_objects into ls_saved_objects index 1.          lv_order_object_guid = ls_saved_objects-guid.          lv_order_object_id   = ls_saved_objects-object_id.
* 11. Call the function to COMMIT the changes to CRM.          call function 'BAPI_TRANSACTION_COMMIT'.        endif.    endcase.

*Your new opportunity will now exist in CRM – use CRM_ORDER_READ to read it, using its GUID

Preliminary note: this project was developed on SAP Netweaver 7.02 SP11 with GW 2.0 SP04 Developer edition available here... so actually there's no need for a CRM system to be able to play with it (despite the title of this blog), as soon as component WEBCUIF is present in your system.

If you do not know BMDG (Bol Master Data Generator) yet, you might want to take a look at the following links:

CRM7.01: what if you could create complex master data models in one click?

CRM7.01: bol master data generator

To sum it up very quickly, it's a tool that allows me to create any kind of master data more easily than any other tool I had my hands on. And only too prerequisites are required:

1) The data to be created should exist as BOL object (ex.: "BuilHeader" for Business partner).

2) A "Template" describing how the bol objects will be created should be stored in a customizing view cluster.

When both prerequisites are met, it's only a matter of copy/paste to create any data model, as much complex as you like (see the video included in one of my previous blog post).

But: until now the "template" creation could be quite long depending on the number of objects to be created (ex.: 2 business partners with one sales order each), and the number of rules to be implemented (ex.: name of the second BP should be the same as the first BP + "_COPY" as suffix), etc.

I believe this period is over.

BMDG is now shipped with a complete WebUI application (component name is "ZBMDG_MAIN") that let's you:

• Search for existing templates
• Create new templates with a nice tree view where all parent/child relationships are determined automatically between bol objects
• Edit templates
• Delete templates
• Copy existing templates
• Execute templates to see the results
• Etc.

So in case you're interested in saving a lot of time when creating/importing data into your system, feel free to join BMDG project on SAP code exchange.

Here is a short video showing how it works:

SAP has been building and expanding its In-Memory application portfolio ever since the introduction of SAP HANA in 2008. SAP Global IT has been the partner for the internal HANA adoption starting day one. The internal adoption followed the four steps of product evolution since then. If you start your HANA roadmap today, you might start with any of these steps.

[picture: 4 phases]

First came the SAP HANA Accelerators. Accelerators were a perfect way to introduce SAP HANA into the market as they provided a quick and easy way to leverage in-memory technology to speed up existing reports in the SAP Business Suite. For SAP Global IT, this became a double starting point: The IT Application Services team made first consulting and project experience with the product SAP HANA. IT Infrastructure Services started to setup first HANA appliances for the business projects, as well as for an increasing demand within the SAP development organization.

Technically data was replicated out of the SAP Business Suite Database into SAP HANA, computations were then done inside the SAP HANA platform, and results were pushed back out into the SAP Business Suite. In this model, the casual user wouldn’t notice any difference in terms of functionality for user interface except for the fact that the reports came back at significantly improved speed. The SAP COPA Accelerator is an example of one of these HANA
Accelerators and has created a high business value for the controlling department.

[picture: SAP and HPI share the passion for Design Thinking to create business value]

It was time to make SAP HANA the primary data store for an application and SAP NetWeaver Business Warehouse was the perfect candidate. For the SAP internal adoption the New BI program built the framework (and created some confusion on customer side, if this might be a new product name) for the initial technical setup and identification of business value projects to showcase the new analytical possibilities. Deployment of Planning powered by SAP HANA, the infrastructure move to a scale-out architecture including high-availability and an alerting and monitoring with SAP Solution Manager have been subsequent steps. This system has been live for more than 12 months. The reduced data layer complexity, the minimal data latency time, and the much lower TCO (compared to run a BWA and a classic DB in parallel before) are still fascinating.

[picture: HANA Appliance Hardware]

SAP then started building new applications natively on top of the HANA platform. These applications all focused on helping companies leverage their growing data to solve specific business problems in ways that were not possible using existing technologies because of speed, cost and complexity related issues. These applications accelerated the adoption of the HANA platform by providing enterprises with very focused use cases to leverage In-Memory technology to harvest the power of their Big Data.

One of the most impressive internal examples is the Environmental Resource Management application build for SAP Global Facility Management, it is able to consume Smart Meter information from all SAP Office buildings every 15 minutes and able to provide operational transparency on real-time data and calculated information via SAP UI5 dashboards.

[picture: Oliver Bussmann announcing CRM on Hana go-live at CeBIT 2013]

SAP announced CRM on HANAat SAPPHIRE NOW Madrid. So, this was the next logical step for the SAP Runs SAP initiative. SAP Global IT in close collaboration with all other functions and teams migrated our business-critical CRM system to SAP CRM powered by SAP HANA through a project that was completed in record time, making us the first customer to go live with the new solution on March 5 (see announcement).

This is the voice of Robert Enslin, CRM user, president of Global Customer Operations, and member of Global Managing Board of SAP AG: “Real-time access to our customer pipeline allows us the ability to consistently analyze our business and know exactly where to focus additional resources and planning efforts. SAP Global Customer Operations is a vocal advocate of how SAP constantly delivers innovative business applications based on SAP HANA, in addition to serving as a highly-active internal customer. With the migration of our own CRM system to SAP CRM powered by SAP HANA, we now benefit from accelerating the solution non-disruptively and providing decision-making insights from the account level through senior management, anytime, anyplace.”

This is a great statement and a good reason to celebrate. So what’s next?

Expect a series of blogs and papers for our CRM on HANA project with details for project best practices, performance improvements,hardware setup and much more in the next weeks. Meet the SAP Runs SAP experts at the SAP Global IT booth at SAPPHIRE NOW in Orlando in May.

The internal HANA adoption program moves on full speed with further new applications, the SAP HANA Analytics Framework and – of course – ERP on HANA. This will be an exciting year!

Now available: The CRM on HANA Cookbook

Best regards,

Matthias Wild - proud to be part of SAP Global IT where SAP runs SAP.

Preliminary note: this project was developed on SAP Netweaver 7.02 SP11 with GW 2.0 SP04 Developer edition available here... so actually there's no need for a CRM system to be able to play with it (despite the title of this blog), as soon as component WEBCUIF is present in your system.

If you do not know BMDG (Bol Master Data Generator) yet, you might want to take a look at the following links:

CRM7.01: what if you could create complex master data models in one click?

CRM7.01: bol master data generator

CRM7.01: secret weapon for data model creation

The great news it that, as of version 3.00, not only can the Bol Master Data Generator helps you create master data, but it can also change existing ones! Indeed you will now be granted the ability to change any kind of data by using bol query objects (or dynamic query objects) to retrieve what you need to modify. For more details about how it works you can check this video I created with an example based, as usual, on the FLIGHT model:

I will probably include one last thing to make it complete when time allows: a file upload functionality... I believe this will make it the perfect tool to manipulate master data: I know SAP delivered the Data Import Tool in CRM EhP2 for Utilities, but, unlike BMDG, it is sad to see that this standard solution is Industry-specific and I've been told that some coding is required to make it work for any kind of object...

So in case you're interested in saving a lot of time when creating/importing data into your system, feel free to join BMDG project on SAP code exchange.

General Information

Prerequisites and Preparation

Production Cutover

The ramp-down procedure is a standard process: unscheduled long running jobs, block-out the end users, clean up queues, isolate the system, and finally shut down the system. Cutting the high availability cluster at this stage has some significant advantage: One side is used for the actual upgrade and migration while the other side remains original. This original system can be used as a quick failback in case something goes wrong. After successful migration, this original system can be used as a reference system (for audits, for example).

Lessons Learned

The original row-compressed database size of 3 TB converts to 1.1 TB on SAP HANA. About 15,500 business users are supported, of which 5000 are “active” users with more than 400 steps each week. The entire OS/DB-migration project took 2.5 months.

  

Performance is key. Start early with load testing to optimize the performance. During testing, we found that SAP HANA is on average significant faster (search improved up to a factor of 250). However, some transactions should be optimized for the SAP HANA platform. During the first week of production with SAP HANA, it is advisable to have a support team of SAP HANA and SAP CRM experts to help fine-tune the system.

  

To conclude, the entire SAP HANA migration can easily be performed on a weekend. If this is not sufficient time, you should consider the nearly zero downtime option using SLT replication

 

References and Further Information

• SAP Business Suite on SAP HANA http://help.sap.com/soh
• SAP CRM on SAP HANA http://help.sap.com/crm_hana
• SAP CRM on SAP HANA Cookbook https://cookbook.experiencesaphana.com/crm/
• 1771591 - SAP HANA Appliance Software SPS 05 Release Note
• 1730098 - EHP2 FOR SAP CRM 7.0 ON HANA - Release Information Note

 

Best regards, Peter Boegler, Enterprise Architect and
Cutover Manager, SAP CRMonHANA

Aim of this blog is to promote the Interactive reporting functionality of CRM Analytics.

Interactive Reporting works in the following way:

First, the user should be a BP and proper org assignment must be done

The report displays only transactions that the current user has created. The user cannot see transactions from other users.

If the user is a manager, then they can see their transactions and the transactions created by their team.

Here, by transactions I mean documents and by user I mean the user executing the report.

Quota Planning

The quota planning page allows sales managers to define quota values for each quarter for directly assigned employees and organizational units. Sales managers can then define the quotas for the next lowest level and transfer the planning to the sales manager on the next lowest level of the organizational hierarchy. Sales managers can also plan quota at a detailed level, or set monthly quota distribution.

Sales quotas are shown as target lines in the following pages:

• Target to Date
• Closing Date
• Sales Pipeline

The totals are calculated for the year.

Configuration for management

The Quota Planning is done in such a way that the quota for a particular organizational unit is set by the Manager who owns this
org unit.

The target value shows in "Target to Date" is the quota value set by higher manager and not the value accumulate from lower
org units.

Suppose there exist following org structure:

Org O1
      Manager M1
     Org O2
        Manager M2
       
Org O3
        Org 04

M1 and M2 are marked as "Head of own organisational unit" in PPOMA_CRM and they have the authorization to set quota value for their subsequent own org units.

If M1 set quota value for O2, this will appear as O2's target value, the quota value set by M2 (manager of O2) for O2's subsequent org unit
(O3 and O4) will sum up to the line "total" as the accumulate value.

If you logon system with M2, you will see the target value set by M1 shown in the first line of the quota planning form, also the "target"
value beside the chart.

To sum up, the target shown in the "Target To Date" is the quota set by the manager of the upper org unit.

Introduction

Grantor Management provides a solution for providing financial assistance to Government organizations. Grantor supports end-to-end process of collecting data from grantee and disbursing funds based on rules. Key features of grantor process include Program management, Application, Assessment, Agreement, Change Request, Claims and Payments. Application and change request uses web request form to capture data specific to grantee. Application is generated from application form (web request) automatically, form can be filled either by an applicant externally or internally by a processor. As soon as application form is submitted the application is generated based on form data.

Web Request is a form based interface in CRM to support request of specific services in a web browser using internet. The requestor fills the data and submits back to the CRM system which generates a transaction with the attribute web request in the CRM system. The transaction related data is managed in the transaction and request-specific XML data is linked to the transaction as request.  XML data structure holds data throughout the session of the application form process which increases the performance of the application. Limitation of XML web request is on holding table data on the form, and the data will not be retained in stateless application. CRM should use shared memory or server cookies to store the data or implement enhancement to insert rows into XML data structure.

Web Request framework

Web request is configured in CRM->E-Commerce->E-Service->Web request-> Define Request categories. Under request category, data structure with fields used in the form will be defined. Request category implementation will be defined to link form values to one order object fields. Views on request category can be defined with BSP or ADOBE forms.  Link between the Request category and transaction type is defined in process assignment block of Program. Data stored in request category structure will be available throughout the process of capturing data from form until the creation of application.

Below diagram illustrates how the web request is called during runtime. HTML page built in the web browser is based on the HTML formatting defined in the BSP layout as well as the attributes of the input fields defined in the request data structure. The data on the request data structure is derived using the server page scripting. The relationship between an input field of the HTML layout and the field content is created through XPATH.

Implementation of CRM_SERVICE_WEBREQ badi plays a major role in data exchange during server events. To access and set the data in the XML structure in runtime, class CL_UXS_XML_SERVICES is used. Method GET_VALUE_VIA_XPATH is used to get data from the form fields and SET_VALUE_VIA_XPATH is used to set data to the form fields.

XML request data is stored in content repository. SAP presets the content category CRM_WEBREQ for web requests and corresponding content category CRM_WEBREQ in the SAP database.

Tables enhancement in Web Request

Standard grantor process doesn’t support tables in web request. Projects need tables on the form to capture multi line data.

1. Method changes for adding Tables to Web Request -

       a. Insert Path – A static method of class CL_UXS_XML_SERVICES=>XSLT_INSERT_PATH is enhanced to insert a new child node into the XML if a new

           line should be added.

       b. Delete Path –A static method of class CL_UXS_XML_SERVICES=>DELETE_ELEMENT_VIA_XPATH is needed to delete a node from the XML if a line   

           should be deleted.

       c. Reading lines on BSP Layout – Add the method GET_NUMBER_OF_LINES to class CL_UWS_FORM_RUNTIME_BSP_SCR.

2. BSP application changes –

       a. Create a page attribute index with type I.

       b. In Event handler add additional rows.

       c. Add/delete button to handle the event in layout.

          For rendering data on views include code changes in layout to get number of lines using           

          CL_UWS_FORM_RUNTIME_BSP_SCR=>GET_NUMBER_OF_LINES and getting data from request category structure.

3. BADI changes - To update data in tables implement the BADI CRM_SERVICE_WEBREQ, methods FORM_ON_CREATION, FORM_ON_INITIALIZATION, 

    FORM_ON_EVENT.

Summary

By including tables feature in web request, data stored in tables will be carried forward throughout the screens, and enhancements related to changing the form data from application life cycle will be minimized.