EEWB is not very flexible

We only want to see the Customer Data Tab for ‘Person’. Not
for Organization or Group.
The BP transaction has been extended with a New Table and
CI using the EEWB (Easy Enhancement Work Bench).
Does anyone know how I might display the Customer Data
conditionally only for a certain BUT000-TYPE. (VALUES: 1 =
Person, 2 = Organization, 3 = Group)?
✍ ANSWER
You can use TRANSACTION CODE: BUPT. Create a new
Data Set and assign the View that got created via EEWB.
Now add this Data Set to your desired BP role. This way,
your new file will be only visible to that particular role, and
not on any other screens.
Just remember when using the EEWB that if you replicate
your objects it will revert all other object back to standard.
Thus you will and can lose other objects created within the
EEWB. So as a final setup you should copy or replicate your
programs into the other standard SAP development tools,
such as a standard BADI as an example.

How can I get Sales Order from R/3 to CRM

I want to know how to transfer the sales order from R/3 to
CRM, and how to bill for that particular Sales Order such
that it replicates in R/3.
My Scenario is:
I have to get the Sales Order from R/3 and I have to bill for
that particular Sales Order in CRM and this bill document
has to replicate R/3 also.
✍ ANSWER
Billing does not replicate from CRM to R/3, but the financial
data will transfer to R/3 F/I (just no invoice in VF02, VF03).
To transfer the order it has to be configured in both systems
and middleware parameters set up.

We are an existing SAP CRM customer upgrading to SAP CRM 7.0 and are debating whether to convert all of your pending Interaction Center (IC) service tickets to the new CRM Web Client service request format. What would be your advice?

Prior to SAP CRM 7.0, the service ticket was the business transaction recommended by
SAP for service issues related to the Help Desk in the IC.

However, as of SAP CRM 7.0, SAP introduced a new business object type called the
service request, which can be used in the Interaction Center, as well as in other CRM
business roles such as the Service Professional role.

New customers should use the service request rather than the service ticket.

Existing customers who are already using the service ticket should migrate to the new
service request when possible (although you can still continue to utilize the IC service
ticket). In order to facilitate the migration, it may be necessary to create a custom report to
handle the conversion of open (pending) service tickets to service requests.

What are the difference between Interaction Record and other Business Activities?

When an interaction record is created the system creates an ‘anchor' document flow link
(relationship type INTO with object type CRMCICANCH). This differentiates an interaction
record from all other Activity Business Objects (BUS2000126).

This additional anchor is used in navigation: when navigating from the interaction history or
inbox to an interaction record, the system will use this anchor to determine whether an
activity is of type interaction record or not. An interaction record typically has other screens
than a normal business activity.

The BW extractor makes also use of this anchor object to differentiate interaction record
related statistics from regular business activities.

We sell computer hardware, and need to log customer technical issues. We have been debating whether to use Service Tickets, Service Order, Complaints Management or Cases. Could you explain what each of these are and when they might be used?

Service Ticket Management
The service ticket is the most common type of service-related business transaction.
Service tickets are commonly used as the default transaction for logging product defects,
bugs, or any other technical issues.

After creating a service ticket as a follow-up transaction to the interaction record, agents
can perform technical analysis of problems (using multi-level categorization) and provide
solutions within defined service-level agreements (SLAs). If necessary, agents can also
dispatch or escalate service tickets to second-level support using pre-defined business
rules.


Service Order Management
Service orders are very similar to service tickets (in fact they share the same underlying
technical structure) but are used whenever it is necessary to schedule a repair, installation,
or other field-service related appointment -- especially if spare parts/service parts are
required.

Unlike service tickets, which do not support spare parts/service parts, the service order
allows agents to assign the relevant spare parts/service parts required for a repair,
maintenance or installation.


Complaint Management
Complaints are a very specific type of service transaction. In SAP CRM, complaints are
created as follow-up documents to support product returns, exchanges, or refunds. A
complaint is appropriate when a customer has a problem or issue with delivery shipment
or billing invoice.

Agents can create a complaint from a reference document such as sales order or billing
invoice. Agents can also generate appropriate follow-on tasks such as credit/debit
memos, QM notifications, free-of-charge shipments, and returns.

In SAP, complaints are NOT used to record situations in which a customer is calling to
"complain" about bad service or defective products; rather interaction records and service
tickets are best suited for such situations.

We are planning to implement Employee Interaction Centre (EIC). We can do it either in CRM or ERP. What is your advice?

If the focus is on native HR functionality requiring process depth within your EIC service
offering, then the ERP option is recommended.

Relevant functionalities not yet available with the SAP CRM EIC deployment option include
the handling of concurrent employment scenarios employee authentication integration to
HR processes and forms.

The SAP CRM solution provides greater depth of Interaction Center related functionality
that is not available within the ERP solution.

These functionalities include:
•        Campaign management
•        Case management
•        Multi-tenancy capabilities enabling client switch & BPO environments
•        Standard help desk processing methodology including service request handling  &
problem management
•        Intent driven interaction
•        Billing and charging for delivered services
•        User interface flexibility and personalization

Is CRM already in place, planned or a potential future need/consideration?
If not, from a technical standpoint - why take on the overhead of CRM?

The ERP based solution is geared towards implementations involving a central HCM
system running on ERP 6.0 and customers who want a HR specific call center solution to
support HCM Service Delivery.

If so, it is likely that the EIC will ultimately be realized within the context of the SAP CRM
Interaction Center. Consideration should also be given to note 1256691 indicating that "the
functions provided in Enhancement Package 4 for SAP ERP 6.0 for the Employee
Interaction Center component (PA-EIC) constitute the final range of functions."  

SAP's direction is to establish one common shared services platform based on CRM
technology and other SAP Business Suite components to offer functions following the
latest business trends such as multi-functional shared services.

The CRM technology will thereby be further leveraged to build this shared services platform
in additional to providing functional enhancements for comprehensive scenario coverage
across shared service center topics.

How Do Modification-Free Enhancements Work?

 You can perform modification-free enhancements at predefined positions in code.
There you have anchor points or enhancement options, as they are called in the
terminology.

At these points you can insert your enhancements.  You can do this without changing the
compilation unit that you are enhancing.  The inserted implementations are processed at
the appropriate position in the compilation unit, but they are themselves not part of this unit.

They cannot, for example, belong to another package.  Let us take a look at the example of
a source code enhancement in a report in order to illustrate this better.  We are not looking
at details of coding, but the key steps.

Anchor point, at which you can plug in an enhancement.

Enhancement which is executed here but is itself not a physical part of the code it is
plugged into

You can – to a certain extent – compare this enhancement technology with a closet system
where you can insert various elements at particular positions. Instead of drilling the wood in
the side walls, you can insert various boards and other elements where the manufacturer
has already inserted hooks or holders at important positions.

There are different types of holders or attachments at various positions.  At each holder
type, you can insert exactly one type of element: boards at small dowel positions, CD
elements at wider dowel positions, and drawer elements at multiple dowels. It seems like
the elements are an integral part of the entire closet but, in fact, they are attached to the
closet parts through holders.

The different enhancement technologies correspond to these different types of elements
described above. These technologies become attached at different types of anchor points
or enhancement options of the Repository objects.

Therefore, you cannot simply insert enhancements into Repository objects at any position
you like without modifications, but only where there are so-called enhancement options in
place. At these enhancement options, you can also attach only certain elements – so-
called enhancement implementation elements.  

A concept that standardizes and structures all previous enhancement possibilities cannot
do without a certain amount of complexity. The structure it is based on, however, is
extremely simple.

.        •        On the one hand, you have hooks or, to put it correctly, enhancement options
where you can insert enhancements. There you define enhancement options, which is why
one can speak of the definition side.

.        •        On the other hand, you have enhancement implementation elements that you
can affix to these hooks or enhancement options.

The rest is simple detail: There are various types of hooks or enhancement options, and
there are also various enhancement implementation elements.  The enhancement options
are grouped together to enhancement spots and these, in turn, to even larger units.

The same applies to units on the implementation side.  Between the different units of a
side and between those of the implementation and definition side, you have assignments
of different cardinality.

Explain the general ways of how a CRM can be enhanced?

 There are several ways to enhance the CRM system. Some of them are:

- Transaction Launcher

You can add external applications to the CRM WebClient User Interface using the
transaction launcher and SAP ITS (Internet Transaction Server). These could be for
example,

-        Web sites of your choice
-        Transactions in an ERP system
-        Administration transactions in the CRM system


- BSP Components Workbench

This is at a technical level and typical changes carried out are e.g. Adding a completely
new View.
It assist with the Component Enhancements.


- UI Configuration Tool

Allows to make changes such as:
Adding or removing fields
Changing field labels
Adding Headers
Making fields mandatory
Displaying assignment blocks (direct, lazy)

Customer specific changes to the UI must be performed using a Role Configuration Key



- Easy Enhancement Workbench

Easy Enhancement Workbench (EEWB) is a development tool that does not require
technical knowledge to be used.

It automatically creates transportable ABAP objects, updates events and implements
BADIs.

What is the Easy Enhancement Workbench?

 Easy Enhancement Workbench

The Easy Enhancement Workbench is a development tool with which SAP applications (called Business Objects in the following document) can be extended in a simple manner.
Customer enhancements to a Business Object are defined via wizards. The Workbench then does all development work for the user; databank tables, screens and application logic are created automatically. Finally the customer enhancement is included in the SAP standard.
This also allows users without ABAP knowledge the simple possibility of extending the SAP standard.
An extension created using the Easy Enhancement Workbench does not differ technically from one created manually. In both cases transportable ABAP objects are created and the same Customer Exits, Business Transaction Events or BAdIs are implemented
 The difference lies exclusively in the manner in which the objects required are created. The automation offered by the Easy Enhancement Workbench is achieved by template objects that are adapted to the extension definition and created by a generator.
The functionality of the Easy Enhancement Workbench is therefore only available for specially prepared Business Objects, mainly from the CRM environment.
The type of extension is also predefined In most cases the customer is offered the possibility to add user-defined databank tables or fields.
In most cases the extension takes place system-wide. For example, when extending a Business Object in the CRM the data exchange to the connected SAP system is extended and a new table is also created in the SAP system.
The system landscape must be set up in order to be able to use system-wide generation. The system landscape must be set up in order to be able to use system-wide generation.
Cross-application components →General application functions → Easy Enhancement Workbench →Maintain system landscape.

Structure of the Easy Enhancement Workbench
To make use of the Easy Enhancement Workbench as simple as possible, we returned to the well-known concept of the ABAP Workbench; the screen allocation and navigation are identical.
The hierarchy of the object list is adapted to the structure of a customer project:
The project is at the highest level. A project combines several enhancements and offers the possibility of defining the project documentation and community. All generated objects belonging to a project are transported together; it is not possible to transport an individual enhancement. Additionally, the package (development class) of the generated objects is determined in the project.
Enhancements are displayed at the next level. An enhancement refers to a business object and an enhancement type. The definition of the enhancement takes place via business-object-specific wizards. Enhancements can also be documented.
When an enhancement has been defined and generated, the object type PostProcessing typically appears at the next level. These are activities that must be executed manually by the user. An enhancement is only considered to be ready when it has been generated correctly and all required PostProcessing activities have been executed.
In order to facilitate monitoring of the generation and to make the technical flow transparent, all generator calls are displayed as tasks in the object list. After an enhancement has been generated all generated objects in a task are visible and can be displayed by double-clicking them.
Additionally, all described object types have an error log that permanently stores errors that have occurred and displays them

What is the GUID Concept in CRM and explain how it is used?

GUID means Global Unique Identifier. You use a GUID when you need to identify an object/component with a unique id. GUID is a unique key for any object in CRM. In CRM, they are either 16 bit, 22 bit or 32 bit of char and hexadecimal in nature, 2 types of GUIDs Header & item. For header, there will be a unique GUID and for each item-line, there will be another unique GUID.

GUIDs are created using the Function Module “GUID_CREATE” in SAP CRM. From the ‘Export’ parameters, you will know that there are only three types of GUIDs.

A small gift: function modules to data exchange in 16 bit, 32 bit and 22 bit exchange – “GUID_CONVERT”.

One more use of GUID is persistence services and hiding the database accesses.  Different business objects of different types may share the same key format and hence may have the same business key although they are of different types and are stored in different tables as the above reply shows. But when we deal with them as ABAP Objects we need to uniquely identify one business object; we can do that using GUID.

When any object is to be transferred to other system it’s the GUID that is used, as there are no replicas and easy to distinguish.

E.g. Consider a Company ‘A’ has 2 departments-Sales1 and Sales2, and in that there are sub departments-products and finance. Now each product and finance of both sales1 and sales2 will have employees with same object_id. So to avoid the dilemma crm creates a GUID for each employee which differentiates each of them.