SAP Mandante (Cliente)

Vamos a explicar algo básico, pero no por ello menos importante. Además es algo que damos por hecho y, normalmente no tenemos en cuenta porque no solemos tener que manejar más de uno. El mandante (o cliente) en SAP.

¿Qué es el Mandante?

En SAP, un mandante o cliente se refiere a una instancia separada en un mismo sistema SAP que puede ser utilizado por diferentes empresas de un grupo de empresas o bien distintas unidades organizativas de la misma empresa. Usando un símil con el armario de la imagen superior. Es como tener un armario con varios cajones, uno para cada área de negocio que quiera separar.

El mandante es ese código de 3 cifras que cuando entras en SAP viene por defecto, normalmente 100 pero pudiendo venir otro. Además en las tablas pones el campo MANDT. Siendo 3 cifras podríamos tener hasta 1000 mandantes, a mí con uno me vale.

Nunca encuentro el mandante 404

¿Para que sirve tener más de un mandante?

Cada mandante tiene su propio conjunto de datos, configuraciones (customizing) y usuarios que lo hacen único. Esto permite a diferentes organizaciones o divisiones operar en un mismo sistema SAP mientras mantienen su información y accesos separados.

Imagínate que eres el CIO de un grupo de empresas y quieres implementar un ERP para gestión del grupo. Pero no quieres que los datos de una de las empresas interfieran con los de la otra. Para ello creas dos mandantes uno con la configuración y datos de la empresa A y otro con la configuración y los datos de la empresa B. ¿Bonito no? Te ahorras hierro, mantenimiento de sistemas, etc. Volviendo al símil del armario, solo gastas en comprar uno, solo mantienes en buen estado ese, solo te ocupa el lugar de uno, etc… Pero también tiene sus inconvenientes ya que hay elementos comunes a todos los cajones, y eso puede producir problemas.


Customizing independiente de mandante

Pues aquí empieza el primero. En general, el customizing o configuración de SAP es dependiente de mandante. Es decir, por ejemplo tienes unos tipos de documentos para la empresa A y otros para la B. O tienes unos datos transaccionales propios para cada mandante, pedidos, facturas, materiales, clientes, etc… (No digo que puedas tener una contabilidad B, ¿no?)

Pero hay algunas configuraciones que son independientes de mandante (Cross-Client) que SAP te avisa que vas a configurar algo independiente de mandante, que tengas cuidado porque afectará a todos los mandantes por igual.


Workbench

Lo mismo pasa con el workbench, es decir todos los objetos del repositorio como son reports, clases, módulos de función, elementos de datos, etc… Este es el mayor riesgo porque se comparte el código y eso hay que tenerlo en cuenta a la hora de hacer una u otra cosa. En símil del armario es como si haces cambios en los rodamientos donde abre y cierra cada armario, o si pintas el armario de un color porque uno te lo ha pedido así.


SELECT a tablas dependientes de mandante

Si bien hemos dicho que el workbench se comparte, cuando hacemos una SELECT a una tabla dependiente de mandante, no necesitamos indicar explícitamente el Mandante en el que estamos, por defecto lo tendrá en cuenta, lo mismo al crear registros.


Mandantes especiales (000, 001, 066)

En los sistemas SAP, además de los mandantes que se hayan creado para la gestión de la empresa o área de negocio, existen una serie de mandantes «especiales» que tienen, cada uno de ellos, un propósito particular.

  • Mandante 000: Es un mandante de referencia proporcionado por SAP. Contiene la configuración estándar de SAP, pero no incluye datos maestros o transaccionales. Se utiliza comúnmente como base para crear nuevos mandantes mediante la función de copia de mandante. Además para ciertas tareas del antiguo (en paz descanse) Middleware de SAP CRM, era necesario entrar a configurar.
  • Mandante 001: Se trata de un mandante ejemplo, una base para crear nuevos mandantes limpios.
  • Mandante 066 (Early Watch): Se utiliza principalmente para propósitos de soporte remoto por parte de SAP. Permite a SAP acceder al sistema para diagnósticos y optimización del rendimiento.

Copia de Mandante

Este proceso permite duplicar la configuración de un mandante existente en otro nuevo. Es especialmente útil cuando se necesita establecer un mandante para desarrollo, pruebas o formación, basado en la configuración actual de un mandante productivo. La copia de mandante incluye tanto la configuración (customizing) como los datos maestros, permitiendo un entorno de trabajo completo y coherente, pero cuidado, que el workbench no se pasa en una copia de Mandante, con lo que si tienes los sistemas de desarrollo y test hechos un desastre, solo pasas datos y configuración (NOTA: No tengas los entornos hechos un desastre).

Para mí este proceso es fundamental realizarlo periódicamente desde producción a test, con un proceso de blanqueo de datos si se requiere en medio, para poder establecer un escenario de resolución de incidencias óptimo.


Copia Homogénea

A diferencia de la Copia de Mandante, y aunque nos salgamos un poco del tema, la copia homogénea es una copia tal cual de un sistema a otro. Es muy útil y usado para escenarios de upgrades, cuando necesitamos crear un Sandbox (sí, sí, arenero, los ingleses no se andan con chorradas) para probar los upgrades sin afectar la cadena de transportes.

Quedamos a las 5 en el arenero a jugar

En casos extremos se puede usar para hacer borrón y cuenta nueva desde Producción a Desarrollo, pero como ya os he dicho antes, esto sería porque tenéis un sistema de desarrollo descabalado y sin control, con muchas modificaciones descontroladas. El problema de la copia homogénea es que todo se copia, y claro, tendremos un periodo de reconfigurar muchas cosas y de quitar ciertas que no se necesitan en entorno no productivo. Por ejemplo, salida de emails.

¿Cómo ver los mandantes que hay?

Para ver los mandantes que hay en el sistema podemos acceder a la transacción SCC4. Además esta transacción nos permite administrar cada uno de los mandantes indicando su tipología y su gestión de cambios y transporte.


En conclusión

Si bien es algo que siempre pasamos por alto, porque lo habitual es que tengamos un mandante  de trabajo por entorno. Podemos encontrarnos, o incluso proponer, un escenario distinto, donde haya varios mandantes en la misma instancia de SAP, y tenemos que ser conscientes de lo que implica y las capacidades que da.

El porqué del GUID

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?

guid

GUID Frustación
¿Pero esto qué es?

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 2128 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

201201270459118101

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.

to32

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