A todos los que venimos de SAP R3 nos ha pasado y todos lo que se acercan a SAP CRM es lo primero (de muchas otras cosas) que les chirría. ¿Qué es ese campo tan largo llamado GUID que me complica la vida para buscar los datos en las tablas?

En SAP R3 estamos acostumbrados a, por ejemplo, coger el número de pedido de la tabla VBAK y con eso recorrerte todas las tablas donde esté referenciado el número de pedido, por ejemplo la VBAP. Pero cuando llegamos a SAP CRM vemos que el ID de documento o el ID de interlocutor comercial no es el dato que enlaza toda la información relativa a ese objeto. Vemos con frustración que tenemos que copiarnos un campo de 32 caracteres alfanuméricos para ir con el a buscar en otras tablas la información que estamos buscando. Además en algunos casos SAP CRM tiene entre dos tablas, una tabla intermedia que transforma el GUID original en otro GUID con el que ir a buscar el dato. Al final te acostumbras pero el principio, junto con muchas otras cosas, resulta bastante frustrante.

Al final de todo esto te haces con ello y terminas usando el NotePad de Windows como portapapeles para ir guardando los Guids y no liarte. Pero terminas acostumbrandote casi sin preguntarte porqué se está usando el famoso GUID y qué ventajas nos ofrece.

Antes de nada un poco de información general. El GUID es un acrónimo de Globally Unique Identifier y según Wikipedia es una implementación del estándar UUID (Universally unique identifier) que sirve para «cualquiera puede crear un UUID y usarlo para identificar algo con una razonable confianza de que el identificador nunca será usado inintencionadamente por cualquiera para cualquier cosa«. Teniendo en cuenta que el GUID se genera habitualmente con 128 bits y se suele mostrar con 32 caracteres (aunque puede ser de 16, 22 o 32) nos daría un total de 2¹²⁸ GUIDs disponibles y, por tanto, la probabilidad de que se repitan en el sistema es casi despreciable.

Sabemos entonces la principal ventaja, es un identificador único de objetos en el sistema (Interlocutores, Documentos, Bdocs, materiales…).

¿Pero cual es el motivo principal por el que se usa?

El motivo principal es la INTEGRACIÓN entre sistemas. SAP CRM se integra con SAP R3, con Mobile, con sistemas externos. Y cuando dependes de un sistema externo porque no actuas como sistema de datos maestros no puedes controlar tan fácilmente los rangos de números y los solapamientos.

• Imaginemos un escenario mobile offline, sin conexión directa con el Backend de CRM hasta que el comercial no llegue a la oficina. El comercial está visitando clientes y generando pedidos. Al generar un pedido en su PDA se le da un número de pedido pero en ese momento no se está preguntando al servidor si ese número está libre o no. Para ello también se genera un GUID que será siempre identificador único y soluciona el problema de los solapamientos.
• Imaginemos también el escenario más común con SAP R3, cuando se crean pedidos en SAP R3 no se pregunta a SAP CRM por si existe algún otro documento en el sistema con esa numeración. Al bajar a SAP CRM se genera el GUID y se guarda en la CRMD_ORDERADM_H. Como todos sabemos podemos tener documentos con la misma numeración en SAP CRM (oferta 1223 y pedido 1223 y actividad de contacto 1223…), lo que nunca se repite es el GUID.

¿Cómo se genera el GUID?

La forma habitual de general GUIDs es usando el módulo de función GUID_CREATE

Que puede generar un GUID único en el sistema con 16, 22 o 32 caracteres.

¿Por qué hay tres tipos de GUIDs y como convertirlos?

Tenemos tres tipos de GUIDS:

• GUID_16: Usado en datos maestros. Business Transaction GUID, Business Partner GUID, Address GUID, Installed Base GUID, etc..
• GUID_22: Usado en DMC (Data Mapping Conversion) las tablas que empiezan por DMC_.
• GUID_32: Usado para BDOCs.

Para poder convertirlos podemos usar el módulo de función GUID_CONVERT.

Si os ha gustado este tema de los GUIDs siempre podeis ser más freaks que el primo de Chewaka y compraros esta camiseta