One consultant from customer who has rich experience in ERP SD/MM module asked me a question some time ago. why GUID is used in SAP CRM, instead of using / directly? Because in R/3, ECC or ERP solution, GUID is not introduced. One exception might be the business partners (not customer/vendor/consumer, but business partner like in CRM), if you activate the business partner functionality in ERP, you could also find BP GUID in table BUT000.
Going back to the original question, this time I did some research and now am going to provide an answer which makes sense to me.

1) What is GUID?

Ans: GUID stands for Globally/Generally Unique Identifier. In CRM, they are either 16 bit, 22 bit or 32 bit raw character format(1).

2) Why is GUID used in SAP CRM?

Ans: With GUID, we could prevent issues with number range conflicts and allow for easier access to CRM tables. This rooted at the data model differences between CRM and ERP. CRM has a segment based data model which stores the data of one business object in a logical unit, instead of storing it in a large corresponding table (like in ERP). Therefore when developing CRM, table joins between related tables would be more common than ERP, and with a generic identifier, it would be easier to build up the connection(2).

3) How is GUID created?

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

And for GUID conversion between the different length function module “GUID_CONVERT” is designed to do that.
However, as of SAP NetWeaver 7.00 Enhancement Package 2 and Netweaver 7.10, the class “CL_SYSTEM_UUID” is created for the UUIDs creation and convertion. This class provides both static method to create single UUID directly and normal method for different scenarios. You can refer to SAP Note 935047 to get more about this.

4) What are the different GUIDs in SAP CRM?

Ans: Well…that depends how many different objects there are in the SAP CRM. A simple way to get the answer is to use the “where-used-list” for type “GUID_16”, "GUID_22” and “GUID_32”. We could get the most used GUIDs and their corresponding types:
GUID_16: Business Transaction GUID (all business transactions), Business Partner GUID (Business partner), Address GUID (Business Partner Address), Installed Base GUID (IBIB), Trace GUID (Trace Tool), etc…
GUID_22: Mostly used in Data Migrations (tables start with DMC_*).
GUID_32: STAD Record Transaction ID, BDoc ID (SMW3_BDOC2)

5) Some other GUID related questions in CRM Middleware

-5.1) Is GUID only unique in CRM or GUID is unique across CRM and R3 ?
Ans: Based on the information above, we could say that GUID is unique at least across the whole CRM system. If the range is extended to ERP, the answer might depend on the sync scenarios between CRM and R/3.
If the scenario is CRM business partner <–> ERP customer/consumer/vendor, then obviously, there is no GUID in ERP for these objects, and GUID will not exist in ERP.
If the scenario is CRM Business partner <-> ERP business partner, according to the experiment I did, the GUID should be the same across ERP and CRM!!!

• 5.2) During Data Exchange (Material, Customer Master, Employee, Transaction), any GUID created in CRM is also stored in R3 ? any GUID created in R3 is also stored in CRM ?
  Ans: One thing for sure is that for material (products in CRM), no GUID exists in ERP, so the GUID is only created when the data is Downloaded/Delta_update to CRM. But the GUID is not stored in ERP (because no place to store) For customer master or employee (all business partners in CRM), there is also no GUID except when the employee/customer master is in Business Partner format also in ERP, otherwise the situation is just like Material and transactions. Only when the data is flowed into CRM when the corresponding GUID is created in CRM and none of these GUIDs will be stored in ERP.
  No new GUIDs are created in ERP during data exchange except the “CRM BP <-> ERP BP” scenario.
  (The End)

Information resource & References:
(1) http://wiki.sdn.sap.com/wiki/display/CRM/Basic+CRM+Technical+Concepts
(2) Another version of answer to this question says that because CRM is a mobile system (sales resp. might use mobile devices often to communicate with CRM server), and when the sales resp. creates the order, he normally would not connect to the backend and identify the unique id for the orders but create a normal order ID as he like. To make sure the order is still unique when they sync the order info with backend, GUID will be necessary. But anyway this is also to avoid the number range conflicts. However I don’t quite agree with this explanation because the scenario is not widely used and also makes little sense (real time sync between sales resp. and customer is possible nowadays.) See more details about this explanation: http://www.magnatraining.com/what-is-guid-in-sap-crm/

● Added by Stephen Johannes, last edited by Stephen Johannes on Aug 06, 2009 (view change)
● show comment

Introduction

There are few technical concepts that you need to be familiar with in order to successfull with SAP CRM development. Let’s review some of the basic ideas and concepts

Object-Based/Object-Oriented Programming

CRM is a primarily an object-based and sometimes object oriented ABAP type system. Object based means the application is not fully object oriented, but written in an manner that simulates object-orientation.

GUID as primary key

A globally or generally unique identifer called a GUID is used in CRM. They are either 16 bit, 22bit or 32bit raw character format. The purpose of the guid is prevent issues with number range conflicts and allow for easier read access to the CRM tables.

Single client per instance

In a simple CRM landscape that only has one SAP ERP backend connected to it, you will find there is not a need for multiple clients in development system. This due to the fact the CRM downloads customizing from the ERP system and uses this customizing as the starting point for the CRM customizing. Normally we only have one middleware connection between CRM & ERP as recommended practice. It is therefore recommened then to only have one development client then on the CRM side.

The data model is not the same as ERP

CRM has a unique segment based data model that is similar to HR infotypes in nature. This means not all the information is stored in very large tables for a business object. In addition you should never write select statements to read data in CRM unless you are doing a search for data. Instead you should use the provided API’s contained in the system.

BDC is not supported

The use of BDC as a data input model is not supported by the solution. Instead CRM provides a rich API framework along with XIF adapter which can be used to import/extract data from the system.

You must understand the business process

CRM by nature is a business process driven solution. It is crucial that you must acquire basic understanding of the business processes, in order to develop a technically correct solution.