Cuando alguien me pregunta sobre son los cambios más relevantes con los que se va a encontrar al pasar a S/4HANA, suele responderle que, dependiendo del módulo, los cambios son más o menos importantes. Y que es fundamental irnos a las Simplification List donde se explica con todo detalle el alcance de los cambios, modificaciones en los modelos de datos, nuevas transacciones o transacciones que quedan obsoletas, cambios en la funcionalidad, etc. Y es importante tener en cuenta que no tenemos por que esperar una revolución en la funcionalidad, seguramente la mayoría de cosas que conocemos y hemos utilizando durante tantos años siguen estando ahí y simplemente se ven afectadas por pequeños cambios o ajustes. Y si es posible que algunas funcionalidades complementarias se vean sustituidas por nuevos componentes a los que Sap ha decidido darles continuidad en contra de otros que van a quedar obsoletos y serán eliminados.
En las próximas tres entradas del blog vamos a hablar de algunos de los cambios más relevantes que nos encontraremos en el módulo de Ventas (SD) si venimos desde R3 y vamos a dar el salto a S/4HANA.
Básicamente, aparte de los cambios tecnológicos y la aparición de las aplicaciones Fiori, alguno de los cambios en lo que a ventas respecta son:
- Simplificación en el modelo de datos. Cambios en el modelo de datos de Pricing.
- Cambios en la gestión de los acuerdos de Rappel.
- Cambios en la gestión del Control de Crédito.
Veamos en detalle cada uno de ellos.
Simplificación en el modelo de datos.
Tal y como se explica en las notas 2267306 y 2198647, el diccionario de datos ha sido rediseñado, incluyendo los siguientes cambios.
- Eliminación de las tablas de status VBUK y VBUP: en R3, disponíamos de dos tablas centralizadas donde podíamos consultar el estado de los documentos de venta (VBAK/VBAP), entregas (LIKP/LIPS) y facturas (VBRK).
En S/4HANA, estas tablas han sido eliminadas y los correspondientes campos han sido movidos a las correspondientes tablas de cabecera y lineas de los documentos.
De esta manera, conseguimos incrementar el rendimiento del sistema, pues:
- Podremos tener el estado de los datos de cabecera o posición de un documento con un único select a la base de datos.
- Las vistas que contienen información de la cabecera/posición de los documentos y los estados se pueden contruir sin necesidad de una condición JOIN (por ejemplo, VBAKUK, LIKPUK, LIPSUP)
Ademas se han realizado cambios en otras tablas:
- Tabla de flujo de documentos (VBFA): la tabla ha sido optimizada para reducir su crecimiento y mejora su rendimiento, con un cambio en la clave de la tabla.
- Tipo documento comercial (campo VBTYP): el campo ha sido ampliado de 1 a 4 caracteres (pasando del elemento de datos VBTYP al VBTYPL).
- Eliminación de redundancias en las tablas de indice de documentos: En R3, estos objetos eran tablas de la base de datos que guardaban información redundante de los documentos para optimizar accesos. En S/4HANA estas tablas han sido eliminadas y pasan a ser vistas CDS, son accesibles directamente desde ABAP.
Por si no las conocíais, estas vistas nos permite acceder a un conjunto limitado de las tablas de ventas de una forma mucho más rápida:
-
- VAKPA: Pedidos por funcion de interlocutor.
- VAPMA: Posiciones de pedido por material
- VLKPA: Entregas por función de interlocutor.
- VLPMA: Posiciones de entrega por material.
- VRKPA: Facturas por función de interlocutor.
- VRPMA: Posiciones de factura por material.
Cambio en el modelo de datos de Pricing.
Aquí tenemos unos de los grandes cambios que se ha realizado a nivel técnico, tal y como se explica en las notas 2267308 y 2220005. Por entrar en contexto, en las versiones anteriores de Sap los cálculos de precios que se realizaban en los documentos (tanto en compras como en ventas), se almacenaban en la famosa tabla KONV.
Allí teníamos almacenadas todas las condiciones de precio con sus valores según la definición de los esquemas de cálculo realizada por parametrización.
En S/4HANA, esta tabla desaparece y es sustituida por la tabla PRCD_ELEMENTS, con la que tendremos que familiarizarnos a partir de ahora. Básicamente, se han realizado cambios en varios campos y ampliado longitudes, con el objetivo de dar más flexibilidad en el ámbito del cálculo del precio.
Pero ademas, tenemos otros cambios importantes que sin son realmente relevantes y nos permite aumentar la flexibilidad y opciones de configuración de la técnica de condiciones:
- Longitud de campos mejoradas para permitir mayor flexibilidad en el pricing y la técnica de condiciones:
- Secuencias de acceso: el numero de accesos posible a tablas de condición se ha incrementado de 99 a 999.
- Número de tablas de clientes para condiciones: se han duplicado, con lo que será díficil quedarnos sin tablas de cliente para la definición de condiciones de precio. Recordemos que son las tablas que podemos definir entre los rangos 501 y 999 o 9AA y 9VV.
- Eliminación de campos redundantes en la tabla de cabecera de condiciones de precio (KONH): el campo VAKEY que se construye con la clave de las tablas de condición ha sido eliminado de todas las cabeceras de las tablas de condición (KONH, NACH, KOND3, KONDN o KONHM). Esto reduce el tamaño de las tablas o problemas al cambiar las tablas de condición. Idem con el campo VADAT.
-
- Longitud de la clave de las tablas de condición ampliada: en R3 teníamos una limitación de 100 caracteres al definir la clave de las tablas de condición (tablas AXXX, donde XXX es el número de tabla de condición). En S/4HANA tendremos disponibles 255 caracteres y no tendremos nunca un problema de longitud.
Para entenderlo, la suma de la longitud de los campos que indicábamos como clave al definir las tablas de condición nunca podía superar la longitud de 100 caracteres. Eso podía tener limitaciones en determinadas circunstancias si estábamos utilizando muchos campos. Con la nueva longitud esa limitación desaparece al disponer de 255 caracteres.
Como veis, muchos cambios técnicos pero que en principio son solo mejoras y son totalmente transparentes para los usuarios.
En los próximos posts veremos otros cambios que si tienen realmente implicación en la funcionalidad disponible para el usuario final con respecto a lo que tenían anteriormente. Espero que os sea de utilidad.