✒️La estructura de los sistemas SAP

Se conocerá la estructura de los datos del sistema SAP, tales como cliente, customizing (adaptación) dependiente de cliente y customizing inter-cliente (cross-client), datos maestros y transacciones, datos de usuario y repositorio de objetos serán descriptos.

1.- La estructura de datos en un sistema SAP

Conocer la estructura de datos es muy importante para los usuarios, desarrolladores y administradores para entender cómo funciona SAP.

SAP tiene una estructura de datos especifica. Adicionalmente las configuraciones del negocio (customizing) que son relevantes para ciertos clientes del sistema SAP, también contiene configuraciones y el repositorio de objetos que son inter-clientes (cross-client).

El repositorio es un almacenamiento central para los objetos desarrollados del Workbench ABAP y es inter-cliente, estos objetos se almacenan en paquetes (packages).

Los paquetes son contenedores para objetos de desarrollo relacionados semánticamente, diferentes objetos de desarrollo (programas, tablas, pantallas, módulos de función, clases, etc) pueden ser agregados a un paquete.

Los paquetes están caracterizados por ciertas propiedades:

• Anidado (nesting)
• Interfaces (interfaces)
• Visibilidad (visibility)
• Accesibilidad (accesibility)

Transacción SPAK: Permite crear y administrar los paquetes con Package Builder.

El grabado y el transporte de modificaciones de objetos está controlado por el Sistema de Transportes y Cambios (CTS = Change and Transport System) utilizando la asignación de objetos de repositorios a paquetes.

2.- El customizing

Este término de customizing (puede decirse adaptaciones), describe las configuraciones de negocio de un sistema SAP. Sus funciones provistas tanto generales como aquellas que pueden ser específicas para una industria son adaptadas a los requerimientos específicos de la empresa en el proceso de Customizing.

El customizing comprende cosas simples y básicas como la definición de plantas y almacenes, hasta cosas más complejas como funciones de compras basadas en planificación de producción o liquidación de nómina.

Una cantidad de customizing estándar como definiciones de país, lenguaje, uso horario se incluyen por SAP desde la instalación.

SAP diferencia entre customizing dependientes de cliente y customizing inter-clientes.

Customizing inter-clientes contiene configuraciones que son independientes de una unidad de negocio particular y tienen una validez general, puede incluir el calendario, impresión o acceso en unidad.

3.- Los clientes

Los sistemas SAP se dividen entre unidades de negocio o clientes (mandantes).

El cliente es la parte comercial, organizacional y técnica contenida en el sistema SAP y consiste en configuraciones de negocio (cuztomizing dependientes de cliente), sus propios datos maestros y transaccionales y sus datos de usuario.

Estos datos de usuario son datos dependientes de cliente o específicos del mismo.

Los tipos de datos dependientes de un cliente se relacionan entre sí, si se ingresa información en unas aplicaciones, el sistema verificara si lo que se ingresa concuerda con la configuración especifica de ese cliente (customizing). Si existen inconsistencias la información será rechazada. Esto significa que la información es significativa en términos de negocio solo en el cliente con el Customizing correspondiente.

Ejemplo; los códigos de compañía, plantas y almacenes.

Los datos maestros y transacciones son dependientes del cliente, como el registro de maestro de materiales, órdenes y facturas al igual que los datos de los usuarios.

Los roles del cliente se utilizan en un sistema SAP, el cliente customizing puede ser configurado para las configuraciones dependientes de cliente en el sistema de desarrollo.

En el sistema de calidad el cliente puede crearse para propósitos de pruebas y en productivo para trabajo productivo. Los roles se asignan a los clientes desde la transacción SCC4.

4.- El repositorio de objetos

Como administradores es recomendable conocer la estructura para poder identificar a los grupos dependientes del cliente/mandante y los independientes del cliente/mandante.

Cuando se realizan cambios en el sistema, SAP nos solicitara generar una orden de transporte y para identificarlos podemos ingresar a la transacción SE10 y ver los tipos que son Customizing que son los dependientes del mandante y las Workbench que son los independientes del mandante. Su diferencia es el campo MANDT; en Customizing cuando nos logeamos en otro cliente/mandante no se visualizará el cambio y se tiene que transportar, aunque se esté en la misma instancia. Y en Workbench (cross-client) se visualizarán los cambios en todos los clientes de la misma instancia SAP.

Así como el Customizing dependiente del cliente e inter-cliente, es posible realizar ajustes adicionales a la estructura de datos de un sistema SAP. Se pueden realizar cambios o mejoras en el repositorio de objetos:

• Extensión del repositorio a través de desarrollos del cliente (customer developments): Se pueden crear objeros de repositorio propios como tablas, programas, transacciones, etc. Los desarrollos del cliente son usualmente realizados en el espacio de nombres del cliente y comienzan con la letra Y o Z, también requerir el nombre de espacio propio SAP que comienza y termina con el carácter /. Los objetos creados bajo el nombre del espacio tendrán un nombre que empezará con /Firma/, tal como /Firma/Evaluacion1.

Este tendrá un máximo de 8 caracteres incluyendo /, como /Firma/.

• Mejoras de cliente (customer enhancement): El repositorio es suplementado por sub-objetos del cliente, ejemplo un programa estándar de SAP puede ser suplementado por código propio del cliente en puntos predefinidos en el código conocidos como customer exits (salidas de cliente). Las estructuras de las tablas pueden ser ampliadas con campos propios utilizando appends (agregados).
• Modificaciones al estándar del sistema SAP: Cambios a objetos estándar de SAP (programas, tablas, estructuras) se conocen como modificaciones. El Repositorio de objetos que viene con el sistema SAP no es extendido sino directamente modificado:

1. Modificaciones manuales.
2. Modificaciones con el asistente de modificaciones.
3. Modificaciones con el asistente de notas.

5.- El landscape de tres sistemas

SAP recomienda un landscape de tres sistemas múltiples basados en la conformación de la estructura de datos de un sistema SAP, en la que existe solo un repositorio de objetos por sistema.

Nunca se debe desarrollar en un sistema SAP que se utiliza como productivo.

Como el repositorio es inter-cliente, SAP recomienda que no se desarrolle en el mismo sistema al mismo tiempo que se utilice de forma productiva, ya que puede conllevar un riesgo de una inconsistencia de datos.

Si se requiere realizar cambios en el repositorio, SAP recomienda que se utilice al menos dos, pero idealmente tres sistemas separados. Un sistema para desarrollos, un segundo para pruebas y calidad y un tercero para productivo.

Este landscape de tres sistemas facilita el siguiente proceso:

• Desarrollos propios de cliente y configuraciones customizing requeridas en el sistema de desarrollo, estas configuraciones realizadas como todos los cambios (desarrollos, mejoras y modificaciones) al repositorio se registran en el sistema de desarrollo.
• Los cambios son luego transportados al sistema de calidad y se verifican allí sin influenciar la operación en productivo. Una prueba de aceptación usualmente no es posible realizar en desarrollo ya que los datos reales no están disponibles en este sistema para una prueba real. La principal razón es que el sistema de desarrollo no ofrece un ambiente estable para una prueba comprensiva e integral (muchos desarrolladores trabajan en un número de diferentes proyectos al mismo tiempo).
• Al aprobarse satisfactoriamente, todos los objetos y configuraciones en el sistema de calidad pueden ser transportados al sistema de productivo. Diferentes clientes pueden ser creados para propósitos específicos. Si realizamos un Customizing dependiente de cliente en el sistema de desarrollo y queremos verificarlo antes de transportarlo a los demás sistemas, puede utilizarse un cliente de prueba en el mismo sistema de desarrollo para ese propósito. Clientes con roles específicos son usualmente creados en cada sistema, cliente de desarrollo en el sistema de desarrollo, de pruebas en el de calidad y cliente productivo en productivo. Generalmente los clientes principales de cada sistema tienen el mismo número ya que por defecto cuando transportamos el cliente origen es igual al cliente destino, esto último no es obligatorio.

Agradecimiento:

Ha agradecido este aporte: Juan Poderoso Blasco