Estructuras de Sistemas SAP
El Software SAP necesita ser adaptado según requerimientos de las compañías, todo esfuerzo extra debe ser mínimo cuando importamos Support Packages o durante Upgrade del sistema.
Estructura de Datos en SAP
Se presentan configuraciones de negocio (customizing), relevantes para ciertos clientes, y configuraciones y repositorios inter-clientes (cross-client)
El repositorio es el lugar almacenamiento para los objetos de desarrollo Workbench ABAP y es intercliente, que se almacenan en paquetes (packages)
Estos paquetes son contenedores de programas, tablas, pantallas, módulos de función, clases, etc. Cuentan con las siguientes propiedas: Anidado (nesting), Interfaces, Visibilidad (visibility), Accesibilidad (accesibility).
SPAK: Package Builder, creación y mantenimiento de paquetes.
El grabado y transporte de modificaciones de objetos está controlado por el Sistema de Transportes y Cambios (CTS, Change and Transport System) utilizando asignación de objetos de repositorio a paquetes.
Customizing
Configuraciones de negocio (Adaptaciones). Las funciones generales o específicas para una industria son adaptadas a los requerimientos específicos de la empresa.
Desde cosas simples y básicas, como definición de plantas y almacenes hasta cosas complejas como funciones de compra basadas en producción o liquidación.
Existen Customizing estándar, como definiciones de país, lenguaje, huso horario, como parte de las instalaciones.
Customizing dependiente de cliente y Customizing inter-clientes.
Customizing inter-clientes: Configuraciones que son independientes de unidad de negocio y tienen validez general. Calendario, impresión, acceso a ayuda, etc.
Clientes
Unidad comercial, organizacional o técnica contenida en un sistema, consiste en configuraciones de negocio (customizing depende de cliente), sus datos maestros y transaccionales y datos de usuarios. Los datos de cliente se conocen como dependiente o específicos de cliente.
Esos datos están relacionados entre sí. Cuando ingresamos información, el sistema verifica si concuerda con la información específica. De haber inconsistencias, se rechaza la información. La información es significativa en términos de negocio, solamente en el cliente con Customizing correspondiente.
Códigos de compañía, plantas y almacenes, son ejemplos de customizing dependiente.
Varios roles son utilizados. Se puede configurar para dependencia en el sistema de desarrollo. Un cliente en QAS puede configurarse para pruebas y en PRD para trabajo productivo. Los roles se asignan a clientes usando SSC4.
Repositorio de Objetos
Es posible realizar ajustes adicionales a la estructura de datos. Se pueden realizar cambios o mejoras en el repositorio. Se pueden realizar en diferentes formas:
· Extensión de repositorio: a través de desarrollos del cliente (customer developments): Es posible crear objetos de repositorio propios tales como tablas, programas, transacciones, etc. Usualmente son realizados en el espacio de nombre y deben comenzar con Y o Z. Se puede requerir un nombre de espacio propio de SAP que empiece y termine con carácter /. Como /FIRMA/
· Mejoras de cliente: (customer enhancement): suplementado por sub-objetos. Un programa estándar puede ser suplementado con código propio del cliente en puntos predefinidos en el código, como customer exits (salida de cliente). Las estructuras de tablas pueden ser ampliadas con campos propios utilizando appends (agregados)
· Modificaciones Estándar: Cambios a objetos estándar (programas, tablas, estructuras) son conocidos como modificaciones. El repositorio no es extendido, es directamente modificado. Dependiendo del tipo de objeto son posibles: Modificaciones manuales, con asistente de modificaciones y asistente de notas.
Landscape de tres sistemas
Se recomienda múltiples sistemas, basados en la conformidad de estructura de datos, en la que existe un solo repositorio de objetos. Nunca se debe desarrollar en PRD. Es condiciones normales, 3 sistemas son suficientes.
Debido a su repositorio inter-cliente, no se recomienda que se desarrolle en un sistema de uso productivo, por el riesgo de inconsistencia de datos. Es recomendable usar al menos 2, pero 3 sistemas idealmente. DES, QAS y PRD.
Proceso recomendado:
Customizing y cambios (desarrollos, mejoras, modificaciones) se registran en DES
Los cambios son transportados a QAS, para ser verificados, sin influenciar PRD. Generalmente las pruebas no son posible de realizar en DES, debido a que los datos reales no están disponibles. Además, muchos desarrolladores trabajan en diferentes proyectos al mismo tiempo.
Luego de pruebas satisfactorias, los objetos y configuraciones pueden ser transportados a PRD. Diferentes clientes pueden ser creados para propósitos específicos, si queremos probar un Customizing dependiente en DES, puede utilizarse un cliente de prueba en el mismo DES.
Clientes con roles específicos son grados para cada sistema, Desarrollo en DES, pruebas en QAS, productivo en PRD.
Generalmente los clientes principales cuentan con el mismo número, ya que por defecto al transportar el cliente origine es igual al destino. No es obligatorio.