¡Feliz año nuevo a todos!. Comenzamos el año 2017 hablando de la manera de proteger la modificación de algunos clientes o proveedores utilizando autorizaciones.
En entradas anteriores del blog hablamos de algunas maneras de restringir modificaciones en los maestros de clientes y proveedores:
Protección de la modificación de algunos campos (algunos usuarios pueden modificar todos los campos; el resto de usuarios tienen campos “grisados” y no pueden modificarlos): ver entrada en este link.
Autorización de modificaciones: se establecen campos sensibles en los datos maestros, y las modificaciones a estos campos tendrán que seguir un flujo de autorización por parte de un usuario responsable: ver entrada en este link.
Valores por defecto iniciales al crear clientes o proveedores: ver entrada en este link.
Con la funcionalidad que vamos a ver hoy, podremos crear “GRUPOS” o “LISTAS” de clientes o proveedores, y restringir las actividades de modificación sobre estas cuentas. Lo primero que hay que hacer es, a nivel de datos maestros, indicar la “etiqueta” que nos permitirá luego restringir las actividades que se pueden realizar para todos los clientes o proveedores incluidos en ese grupo de autorizaciones.
Vamos a ver el ejemplo para clientes (para proveedores será similar). Por ejemplo, para los datos generales del clientes (a nivel de mandante), lo indicaremos en la pestaña Datos de Control, campo Autorización:
Indicaremos un valor alfanumérico (es una etiqueta sin ninguna validación).
Si queremos hacerlo a nivel de sociedad, lo indicamos en la pestaña Gestión de cuenta, campo Autorización.
Finalmente, a nivel de ventas, lo indicaremos en la pestaña Ventas, en el campo Grupo Autoriz.
En segundo lugar, por autorizaciones, controlamos quien tiene permisos para hacer cosas con ese grupo de clientes. Con el objeto de autorización F_KNA1_BED, indicamos la etiqueta en el campo BRGRU, y la actividad permitida en el campo ACTVT (si estamos preparándolo para proveedores, utilizaremos el objeto de autorización F_LFA1_BEK).
Crearemos un rol de autorizaciones (transacción PFCG), asignando el objeto F_KNA1_BED a los usuarios que podrán tratar esta agrupación de clientes, con las actividades deseadas. El resto de usuarios no tendrán que tener esta autorización.
Cuando un usuario intente modificar el cliente, y no tenga autorización para ello
La autorización aplicará tanto en datos generales, a nivel de sociedad o de área de ventas siempre que hayamos indicado la correspondiente etiqueta en el campo Autorización, y no dispongamos del objeto F_KNA1_BED con ese valor.
Con esta autorización podemos crear agrupaciones de clientes libres para que tengan un tratamiento restringido, fuera del control que se puede hacer por un criterio mas general como es el grupo de cuentas (que se puede controlar igualmente con el objeto de autorización F_KNA1_GRP o F_LFA1_GRP) o por sociedad (objeto F_KNA1_BUK o F_LFA1_BUK). Recordemos que siempre que creamos un cliente o un proveedor, le asignamos un grupo de cuentas que determinan importantes funciones de control como la numeración de estos, campos que se mantienen en las fichas y las funciones de interlocutor que pueden desempeñar en los documentos que se creen en el sistema.
En nuestro post de hoy vamos a hablar de algunas utilidades que tiene Sap para realizar verificaciones o correcciones en los status de los documentos de ventas.
Como ya sabreís, Sap va almacenando los status de tratamiento de los documentos de ventas (ofertas, pedidos, entregas) en las tablas VBUK (cabecera) y VBUP (posiciones).
Tenemos diferentes status para las diferentes operaciones que se pueden realizar en un documento (por ejemplo, factura, movimiento de mercancia, status WM) y un status global que determina si el documento está concluido. No todos los documentos/posiciones tienen que tener todos los status relevantes.
El status global se muestra cuando visualizamos el flujo de documentos para nuestros documentos de ventas (por ejemplo, para el pedido en la VA03, oferta en la VA23, entrega de salida en la VL03N o factura en la VF03, entre otras). También podemos ver el flujo de documentos de forma masiva para varios documentos con la transacción IW12 o de forma gráfica para un documento con el report RV75FGRF, tal y como os muestro en la imagen.
Os dejo un interesante artículo de Oscar Arranz sobre este tema en este link.
También se pueden ver los estatus en los documentos en la pestaña Status o Gestión (depende del documento).
En la imagen siguiente ver los status de un pedido (399), la entrega siguiente (80000312) y la correspondiente factura de ventas (90000294).
En el pedido tenemos el status de entrega (SE) y entrega total (ET) que los otros documentos no tienen. También el status de rechazo (RZ) con una A, que indica que el documento no esta rechazado y el status total (ST), con una C que indica que está concluida (tendria una A si esta pendiente, B si esta concluido parcialmente o blanco si no es relevante el status).
Para la entrega, vemos que son relevantes otros status como el SM (salida mercancia) o SF (factura). El de factura aparecerá en el documento que sea relevante para facturar (en función de una facturación basada en pedido o en entrega). Aqui aparece el status de Picking y otros relacionados con la preparación de las entregas, confirmación, etc.
Para factura, ademas del status total, tenemos uno diferente, el SC (status de contabilización), que nos indica si una factura ya ha sido contabilizada.
En ocasiones, los status de los documentos no se actualizan correctamente o se realizan cambios en la parametrización que pueden afectar a estos. Para estas situaciones, Sap nos ofrece una seria de utilidades para revisar los status de los documentos y actualizarlos de la forma correcta según la configuración del sistema.
Entregas: report RVDELSTA. Valido para entregas de salida y entregas entrantes (según se describe en la nota Sap 506510). Verifica los status y actualiza el status si hay cambios relevantes.En la imagen, la actualización de una entrega que se habia concluido por error (forzandola), y al recalcular con el report vuelve a dejarlo como pendiente.
Documentos de ventas: report SDVBUK00. Recalculo de status de los documentos de ventas, segun la nota 207875. Analiza todos los status del documento y los modifica si hay diferencias entre lo guardado en la base de datos y lo calculado.
Transacción LX47: actualiza el status de picking de la entrega cuando se utiliza WM. Para los casos en que se ha completado la OT, pero no se ha actualizado correctamente el status de picking en la entrega.
Podemos consultar la nota 1478022 para entender el funcionamiento del report SDVBUK00.
Otras situaciones que se pueden tratar con reports estandar o liberados a través de notas. Por ejemplo, para cerrar documentos antiguos cuando vayamos a realizar archivado (ojo a la utilización de estas herramientas, verificar antes de su utilización todas las implicaciones que pueda implicar el uso de herramientas que omiten el comportamiento estándar):
SHP_DELIVERY_COMPLETE: según la nota 992587. Se ejecuta con la transacción VL_COMPLETE. Nos permite cerrar el status de una entrega completada parcialmente.
SDARCHLP: según la nota 775540. Para cerrar el status de facturas en operaciones de archivado donde no se quiera controlar la situacion de los documentos (por ejemplo, archivado total por dejar de utilizar una sociedad en un sistema).
Para completar nuestro inicio de año, vamos a hablar de otro de los temas en los que Sap, bajo mi punto de vista, más flojea. En el R3 (ya veremos lo que nos preparan en S4/HANA), las herramientas para la carga y actualización de condiciones de precios (tanto en ventas, compras o en cualquier otro componente que utilice la técnica de condiciones) brillan por su ausencia y producen una gran carga de trabajo para los usuarios.
En una entrada anterior hablamos de la forma de poder copiar condiciones, pivotando sobre uno de los datos maestros al nivel en el que estan definidas las condiciones (ver enlace), lo cual es claramente insuficiente.
Tenemos otras alternativas aparte de la VK11 para crear condiciones (o MEK1 en compras), como son las transacciones VK31/VK32 (requiere parametrización adicional para añadir otras tablas, ver link) o las V_I7 o V/I5 mediante indices (requiere definir indices para las tablas de condición, lo cual puede afectar al rendimiento del sistema; por estándar se ofrecen muy pocos índices)
El tratamiento de grandes volúmenes de datos es muy farragoso, requiere utilizar componentes adicionales (como Sap Vistex, que es un Addon que se licencia aparte) o realizar desarrollos para poder facilitar la vida a los usuarios. Como consuelo (y esperanza que sea la tónica que siga S4/HANA), en el sistema SAP TM (Transport Management), las herramientas para definición de condiciones han dado un salto cualitativo muy evidente, disponiendo en el estándar la funcionalidad de descargar plantillas de condiciones y realizar su carga directamente utilizando hojas excel.
Antes el dilema de preparar una herramienta para cargar tarifas, os voy a contar uno de los módulos de función que he comprobado que funcionan bien y otras posibles alternativas (como muestra de posibilidades para realizar esta tarea, seguramente habrá otras disponibles).
Alternativa 1. Uso del módulo de función RV_CONDITION_COPY.
Con este módulo de función, podemos fácilmente montar una utilidad Abap para hacer carga masiva de registros de condición. Yo lo he probado personalmente y funciona correctamente. Además, cuando se crean registros de condición cuyos intervalos de validez colisionan con los registros existentes, estos se limitan correctamente.
Este módulo de función ha de usarse de forma conjunta con otros dos para que funcione correctamente:
call function ‘RV_CONDITION_SAVE’. call function ‘RV_CONDITION_RESET’.
Se puede utilizar tanto para cargar condiciones en ventas (aplicacion V) o compras (aplicación M). En mi ejemplo, lo he utilizado para cargar condiciones de precio de ventas (clase de condición PR00, definidas por organización de ventas, canal y material). Os recomiendo la lectura de documentación del módulo de función, pero lo más importante de la llamada a este MF sería:
En la estructura ls_komg tenemos la clave de los registros de condición: por ejemplo, en mi ejemplo estamos llenando la tabla A004 que nos permite definir condiciones por organización de ventas, canal y material. En esta estructura pondremos los valores para el nivel al que estamos definiendo las condiciones.
En la tabla copy_records tenemos los valores de la condición (tabla del tipo komv): importe, cantidad o porcentaje, moneda, unidad de medida, cantidad base, etc. Importante el campo KRECH, que indica el tipo de cálculo (según como se haya definido la clase de condición que estemos cargando).
En la tabla copy_staffel (tabla del tipo condscale) tenemos los valores de escalados si se definen para la condición.
Importante en la llamada al MF indicar el modo de mantenimiento (maintain_mode) y la tabla de condicion que estamos modificando (condition_table). Los números de las tablas los podemos obtener de la secuencia de acceso asignadas a las clases de condición.
Os dejo el link al ejemplo de código programado (ejemplo sencillo de carga de una excel a un ALV y luego carga en base de datos pulsando un botón).
Link al código Abap de ejemplo: zpruebas_condiciones. Hay que definir un status llamado MAIN para el programa con los botones y el código de función “PRUEBA” o “DATA_SAVE” para que funcione.
Resumiendo, el programa nos permite cargar la excel y nos muestra un listado con las condiciones subidas (ahí podríamos haber añadido todas las verificaciones necesarias de los datos cargados, mostrar descripciones, semáforos de resultado de actualización, etc).
Al pulsar el botón Carga BD o Grabar, se realiza la creación de los registros de condición. Podemos consultarlos con la VK12 o directamente a través de la tabla A004.
La herramienta se podría evolucionar con desarrollo para permitir la carga de varias clases de condición, diferentes tablas, etc. Seguro que los abapers nos pueden hacer una verdadera herramienta de gestión de actualización de precios para las necesidades de nuestra empresa.
Alternativa 2. Uso de la Bapi BAPI_PRICES_CONDITIONS.
Una alternativa es utilizar la BAPI_PRICES_CONDITIONS. En principio es más sencilla de utilizar, pero no actualiza los registros de condición existentes para limitar los periodos de validez. Esto puede ser un problema y crear inconsistencias en las tablas.
Alternativa 3. Utilización de LSMW.
Bien con el metodo Direct Input, realizando una grabación o con Idocs podriamos realizar igualmente la grabación de los datos.
Por ejemplo, si usamos idocs:
Habría que mapear el fichero de carga con la correspondiente estructura del documento:
Idem si utilizamos una grabación de batch input de la transacción VK11 o MEk1, por ejemplo:
O el metodo direct input que también esta disponible para cargas iniciales de condiciones:
En nuestro truco de hoy vamos a hablar de un problema bastante frecuente. En ocasiones necesitamos reservar el stock de un almacén, y que este no sea tenido en cuenta en la verificación de disponibilidad que hacemos en los documentos de ventas o en los pedidos de traslado (o en otros procesos de producción o gestión de stocks).
Alternativa 1. Usar stock bloqueado o en control de calidad.
Una de las posibles alternativas es llevar el stock a “apartar” a uno de los stocks normales de los que dispone Sap (control de calidad o bloqueado). Si en la configuración de la verificación de disponibilidad (transacción OVZ9) no se incluyen estos stocks, tendremos el problema solucionado.
Recordad que esta configuración se realiza a nivel del valor de Verificación de disponibilidad (dato que está en el maestro de materiales a nivel de centro, en la Vista de Ventas o en la vista de Planificación de necesidades 3) y de la regla de verificación (gestionada por ámbito de aplicación, por ejemplo, Pedidos, Entregas, etc).
El principal inconveniente de esta alternativa es que nos obliga a realizar movimientos de material pasando los stocks de libre utilización a control calidad/bloqueados para reservar el stock y en sentido contrario para liberarlo).
Utilizaremos para ello los movimientos de traslado que vemos en la imagen, según el stock origen/destino que estemos gestionando.
Alternativa 2. Excluir un almacén a nivel del material.
Una posible alternativa es, para un material concreto, definir que un almacén se tiene que quedar fuera de la verificación de la disponibilidad.
Para ello, en la vista de Planificación de necesidades 4, indicaremos el almacén y el valor 1 “Stock del almacén no se incluye en la planificación de necesidades”, en el campo “Indicador de planificación de necesidades”.
Esto hará que el almacén, para este material, quedará excluido de la verificación de disponibilidad e igualmente en la planificación de necesidades.
En la imagen vemos un pedido de venta, y el material 56, aun disponiendo de stock, al estar este stock en el almacén 0004, no ha sido considerado como disponible y, por tanto, no se han confirmado cantidades.
En el otro material de la imagen (57), no se ha excluido el almacén en las vistas de planificación y el stock esta totalmente disponible.
Es una forma sencilla de excluir determinados almacenes a nivel de material, lo que lo hace más flexible. El único inconveniente podría ser que afecta también a la planificación, y que obliga a mantenimiento de datos maestros.
Nota: si en los datos de entrega del pedido de venta se hubiera puesto, ademas del centro, el almacén (y en este caso pusiéramos el almacén excluido, el sistema si realizaría la verificación de disponibilidad). En ese caso, el sistema hace la comprobación contra el almacén indicado. Y si ponemos otro almacén, el sistema verificará el stock solo contra dicho almacén. Esto puede ser una buena alternativa para el propósito que estamos buscando.
El almacén de las posiciones se puede inicializar al crear los documentos con los valores oportunos, aunque tiene efectos secundarios al no considerar otros almacenes. Por ejemplo, con la exit MV45AFZZ (form USEREXIT_MOVE_FIELD_TO_VBAP).
Este aspecto lo podemos controlar en la parametrización de la verificación de disponibilidad (transacción OVZ9), marcando el flag “Sin inspección de almacén”, que fuerza a que la verificación de disponibilidad se siga haciendo a nivel de centro, aunque hayamos indicado un almacén en el pedido.
Alternativa 3. Excluir un almacén a nivel de parametrización.
La tercera alternativa sería parametrizar la vista V_T001L_D, donde podemos indicar por centro/almacén, que un determinado almacén se excluye de la verificación de disponibilidad y de la planificación de necesidades.
A tener en cuenta que esta parametrización es un valor de propuesta para los materiales que se creen en el Centro/Almacén que estemos configurando. En ningún caso, es una parametrización con efecto inmediato, sino que habrá que definirla para los almacenes que queramos excluir y a su vez modificar los materiales ya creados en el almacén correspondiente.
Los materiales que se creen nuevos en ese almacén ya tendrán la información de la forma deseada.
En el caso de querer tirar atrás la configuración, podremos utilizar la transacción MM17 para realizar la correspondiente actualización en masa y modificar el valor del campo MARD-DISKZ con el valor deseado.
Alternativa 4. Exits.
La última alternativa, a riesgo de cada uno, es intentar “meter mano” en el estándar y con las exits, cambiar el comportamiento del sistema.
Mi experiencia me dice que es una tarea complicada y casi nunca libre de efectos secundarios, sobre todo cuando estamos interactuando en algo tan importante como la verificación de disponibilidad.
En este enlace del SCN teneis algunas de las exits disponibles:
Por ejemplo, la exit ATP00001 que podemos gestionar a través de la transacción CMOD, donde se pueden modificar los resultados estándar de la verificación de la disponibilidad.
En ocasiones, necesitamos añadir campos adicionales en la determinación de precios, tanto en Compras (MM) o en Ventas (SD). Estos campos pueden ser campos de cliente añadidos en las transacciones estándar (utilizando las exits o badis disponibles) o simplemente campos estándar que Sap no ha puesto como disponibles en el esquema de cálculo y que por tanto no son relevantes para poder definir condiciones de precio utilizandolos.
Si tenemos esta necesidad, es sencillo habilitar que estos campos estén disponibles para ser utilizados en tablas de condición.
Las siguientes estructuras de comunicación son relevantes en la determinación del precio:
KOMK (determinación del precio cabecera de la comunicación)
KOMP (determinación del precio posición de la comunicación)
KOMG (campos permitidos para estructuras de condición)
Por razones técnicas se utiliza la estructura de comunicación KOMG que representa la suma de KOMK y KOMP y que contiene todos los campos que se emplean principalmente para la determinación del precio. Con la inclusión de nuevos campos en KOMK o KOMP se incorporan automáticamente los campos en KOMG.
Para añadir los campos deseados en estas estructuras, utilizaremos los siguientes INCLUDES:
datos de cabecera en la estructura KOMKAZ (INCLUDE disponible en KOMK o KOMG)
datos de posición en la estructura KOMPAZ (INCLUDE en KOMP o en KOMG)
Las estructuras KOMK y KOMP son compartidas tanto en ventas como en compras.
Adicionalmente, tendremos que realizar dos acciones para dejar configurado el sistema:
Habilitar los nuevos campos para poder ser utilizados en tablas de condición: para ello accederemos mediante el customizing a la ruta Gestión de materiales –> Compras –> Condiciones –> Fijar determinación de precio –> Ampliar catálogo de campo para tablas de condición en la parte de compras. Para la parte de ventas, utilizaremos la ruta Comercial –> Funciones básicas –> Determinación de precio –> Control de la determinación de precio –> Definir tablas de condiciones –> Condiciones: Campos permitidos.
Implementar las correspondientes exits para llenar de valor los nuevos campos de las estructuras de intercambio: los nuevos campos añadidos no tendrán valores informados en los esquemas de cálculo. Habrá que llenarlos de valor en las correspondientes exits, que son:
Compras: realizaremos la implementación de las ampliaciones LMEKO001 (cabecera) y LMEKO002 (posiciones), a través de la SMOD. En estas exit llenaremos de valor los campos modificando las estructuras E_KOMK o E_KOMP. También se puede realiza la modificación utilizando la badi
ME_PO_PRICING_CUST (métodos PROCESS_KOMK o PROCESS_KOMP).
Ventas (pedidos): las rutinas se encuentra en el include MV45AFZZ. Realizaremos la asignación de los campos en las estructuras TKOMK o TKOMZ usando los correspondientes form:
USEREXIT_PRICING_PREPARE_TKOMK (campos de cabecera)
USEREXIT_PRICING_PREPARE_TKOMP (campos de posición)
Ventas (facturas): las rutinas se encuentra en el include RV60AFZZ. Las rutinas para el aprovisionamiento de los nuevos campos en la facturación se encuentran en el elemento RV60AFZZ. Utilizaremos los form:
USEREXIT_PRICING_PREPARE_TKOMK (campos de cabecera)
USEREXIT_PRICING_PREPARE_TKOMP (campos de posición)
La parte importante que quiero tratar en este post tiene que ver en como se comporta el sistema respecto al precio cuando cambiamos el valor de estos campos que hemos definido como “relevantes” para el calculo de precio u otras condiciones (descuentos, recuerdos, costes indirectos, gastos de transporte, etc).
En condiciones normales, un cambio en un valor de estos campos, no va a ser relevante para el precio y este no se va a volver a “calcular” de forma automática. Tendremos que ser nosotros, quienes, de forma manual, accedamos a la pestaña condiciones del documento (posición) y forcemos el recálculo del precio para que sean relevantes los cambios en los campos añadidos en el esquema.
Pero existe una forma de automatizar esta acción y que las modificaciones en los campos sean relevantes de forma automática y el sistema recalcule el precio. Para ello, podremos utilizar las siguientes exits o badis:
Compras: implementaremos la badi ME_DEFINE_CALCTYPE.
Ventas: implementaremos la exit MV45AFZB, en el FORM USEREXIT_NEW_PRICING_VBAP.
En ambos casos tenemos los valores anteriores de los campos y los valores nuevos (por ejemplo, en ventas tenemos en VBAP los valores actuales y en *VBAP los valores anteriores, pudiendo detectar cambios que hagan relevante un recalculo del precio). A la vuelta de las exits devolveremos el valor para el recalculo de precio oportuno, como si estuvieramos recalculando el precio del documento de forma manual (por ejemplo, el valor B para efectuar una determinación de precio completa o C para recalcular solo las condiciones que no se hayan introducido de forma manual).
Ejemplo practico: Campo almacén relevante para precio en los pedidos de ventas.
En primer lugar añadiremos el campo a la estructura KOMP (include KOMPAZ), utilizando la transacción SE11. Usaremos un APPEND para que no sea una modificación del estandar :
A continuación llenaremos de valor el campo para que este disponible en el esquema de cálculo (includes MV45AFZZ y RV60AFZZ, form USEREXIT_PRICING_PREPARE_TKOMP).
Habilitaremos el campo para ser usado en tablas de condición (en la ruta de parametrización Comercial –> Funciones básicas –> Determinación de precio –> Control de la determinación de precio –> Definir tablas de condiciones –> Condiciones: Campos permitidos.
Crearemos nuestras propias tablas de condición utilizando el nuevo campo y las asignaremos a la secuencia de acceso de alguna clase de condición (en nuestro ejemplo, para el precio, condición PR00) para poder definir condiciones de precio a ese nivel.
Implementaremos la exit para determinar como se recalcula el precio cuando haya modificaciones en los campos añadidos. Para ello, implementaremos la exit MV45AFZB, en el FORM USEREXIT_NEW_PRICING_VBAP. Si el campo almacén cambia, se efectuara una nueva determinación de precio.
En nuestro ejemplo tenemos un precio distinto según el almacén en el que se realice la venta. Aquí podemos ver las condiciones de precio que hemos definido para el ejemplo:
Al crear o modificar un documento de ventas, cuando se cambie el almacén el sistema buscará de nuevo condiciones relevante para el precio y habremos conseguido nuestro objetivo. Para el almacén 0001, el precio son 20 euros.
Al cambiar el almacén, el sistema automáticamente nos ha cambiado el precio a 25 (sin necesidad de recalcular el precio para las posiciones).
Cuantas veces nos hemos encontrado con el típico problema de tener un precio medio variable en la valoración de un material (vista de contabilidad) y no ser capaces de entender cual es el motivo u origen de ese valor.
Normalmente, intentamos buscar una explicación mirando algunas de estas cosas:
Tablas de la base de datos: en la tabla MBEW tenemos la información actual de la vista de contabilidad, donde podemos ver el precio medio variable. En la tabla MBEWH tenemos el histórico de precios para periodos anteriores (siempre que haya movimientos habrá registro para un mes). Puede ser una primera aproximación para analizar de forma general cambios de precio muy significativos.
Analizar los documentos de material: podemos intentar sacar las modificaciones de precio utilizando la MB51 (listado de documentos de material), pero habrá operaciones que no tendrán reflejo ahí, como el registro de facturas o modificaciones de precio con la MR21 o MR22.
Utilizar el calculo de stock a una fecha: con la transacción MB5B podemos hacer un análisis de los movimientos realizados para un material durante un periodo, incluyendo operaciones que no son movimientos de stock pero que si afectan a la valoración del material.
Documentos contables por material: con la transacción MR51 podemos listar esta información, que es posible nos ayude a encontrar el motivo del cambio del precio. Esta herramienta no distingue entre contabilizaciones hechas con stock libre o stocks especiales (E, Q), y en ocasiones no se puede utilizar correctamente (ver KBA 1506200).
Es posible que en este momento ya hayamos encontrado una explicación al precio que presenta nuestro material.
Con el objetivo de ayudarnos en nuestro propósito Sap libero, a través de la nota 2198317, el report MBMAPCHANGES. Este programa pretende ser la herramienta para que los usuarios puedan analizar los cambios de precios sin necesidad de combinar varias transacciones, contenidos de tablas, etc.
Algunas de las características del report:
Informe en formato ALV, que muestra todos los documentos que han cambiado las cantidades de stock o su valor.
Distingue entre los diferentes tipos de stock: libre utilización, stock especial pedido (E) o de proyecto (Q), que tienen sus propias valoraciones.
Incluye navegación a los documentos de referencia.
Remarca los documentos que tienen cambios significativos en el precio (en mi ejemplo, realice un cambio de precio muy grande con la MR21 y esa linea aparece remarcada en rojo). Si navego al documento puedo ver como me lleva a la transacción CKMPCD, donde consulto del documento de cambio de precio).
Incluye documentación sobre la forma de calculo y los escenarios incluidos en la herramienta.
Nota: el informe se crea al aplicar la nota 2198317, que incluye pasos manuales para su implementación. La nota 2256487 es necesario aplicarla igualmente.
Seguramente con este informe nos hubiéramos ahorrado unas cuentas horas de búsqueda para entender un precio. Entendemos la complejidad de Sap, pero alguna herramienta como esta más a menudo no estaría mal para facilitar la vida al usuario.
Hace algún tiempo hablamos, en una serie de posts, de la gestión documental básica y como podíamos gestionarla en Sap. Os dejos los links a los 3 posts relacionados:
En concreto, hablamos del Archivelink y de como anexar, a los objetos de negocio, ficheros del tipo word (.doc), excel (.xls), pdf, jpg, etc.
Los documentos anexados luego podían ser consultados desde los mismos documentos con la opción Lista anexos en el GOS o a través de la transacción OAAD.
Revisar el correspondiente post donde explicamos toda la funcionalidad asociada y la forma de realizar la configuración de esta.
Nota: en el módulo de ventas es necesario poner el parámetro de usuario SD_SWU_ACTIVE con el valor X para activar el GOS en la transaccion VA02/VA03.
Hay una funcionalidad no demasiado conocida que nos permite, de forma totalmente estándar, generar anexos en el archivelink al procesar los mensajes asociados a los documentos.
Por ejemplo, si queremos que cada vez que se emita una factura de ventas, el sistema automáticamente guarde en la gestión documental dicho documento en formato PDF, lo podríamos realizar de una forma muy sencilla. Es requisito para poder utilizar esta funcionalidad tener un gestor documental instalado (se recomiendo nunca almacenar los documentos en la misma base de datos donde se encuentra SAP) y realizar la parametrización del Archivelink.
Para entender como configuraríamos el sistema, vamos a ver un ejemplo práctico utilizando las facturas de ventas.
Configuración de las clases de mensaje.
En la transacción NACE, seleccionaremos la aplicación V3 Facturacion y la opción Clases de Mensaje. Por ejemplo, para el mensaje estándar de la factura (RD00), podremos configurar en la pestaña “Sistema Archivo” la forma de realizar el archivado y que Clase de documento de los configurados en el Archivelink utilizaremos para almacenar el mensaje en la gestión documental cuando este sea procesado.
En nuestro ejemplo, hemos indicado la clase de documento ZPDF, que previamente hemos configurado utilizando la transacción OAC2. Esa clase de documento es un documento lógico al que se asigna un tipo de documento (tipo de formato). Previamente habremos configurado los repositorios de contenido (transacción OAC0) donde se almacenarán los documentos, y asignado este a la clase de documento ZPDF y el objeto de negocio, VBRK en este caso (transacción OAC3).
Registros de condición de los mensajes.
Al crear los registros de condición para la generación automática de los mensajes (transacción NACR, aplicación V3, clase de mensaje RD00 en mi caso; o transacción VV31/VV32), indicaremos como queremos que sea su tratamiento en los relativo a su inclusión en la gestión documental.
Si indicamos el valor 1 Solo imprimir, solo se realizará su tratamiento convencional (impresión, por ejemplo) y no se generará el documento en el archivelink.
Con los valores 2 Solo archivar o 3 Imprimir y archivar si se generará el correspondiente documento anexado.
Tratamiento de los mensajes.
Cuando se procesen los mensajes (bien de forma automática al grabar los documentos) o bien al tratarlos de forma manual por parte del usuario (transacción VF31 para el caso concreto de las facturas de ventas), el sistema realizará la generación del anexo en el formato correspondiente y lo vinculará al documento tratado, siendo guardado en el gestor documental.
Tras procesar el mensaje, si consultamos la factura desde la VF02, pulsando el botón Servicios para objeto (GOS), opción Lista anexos, podremos ver que se ha generado un anexo en la gestión documental del archivelink asociado a la factura para la que procesamos el mensaje.
Igualmente, desde la transacción OAADcon la opción “Búsqueda técnica” en la sección Documentos podremos realizar la búsqueda de los documentos anexados a la factura podremos realizar la búsqueda o consulta de los anexos.
Si accedemos al anexo, podremos ver que tenemos nuestro formulario de factura perfectamente almacenado en formato PDF y vinculado a la factura original que fue el origen del mensaje.
Todo de una forma estándar y sin necesidad de programación. En una próxima entrada del blog veremos que también se pueden generar de manera similar Listas de spool (listados)en la gestión documental.
En ocasiones, necesitamos abrir una transacción de parametrización en el sistema productivo para poder realizar cambios directamente en este sistema. Se podría realizar de una forma temporal utilizando la transacción SCC4 para mantener las propiedades de los mandantes, pero es totalmente desaconsejable abrir un mandante productivo de forma permanente o permitirlo directamente a los usuarios finales.
Es importante remarcar que solo tiene sentido hacerlo en transacciones cuyos valores ha de mantener directamente el usuario o en aquellas que pudieran ir relacionadas con datos maestros para los que es difícil mantener los mismos valores en un sistema de desarrollo o productivo (por ejemplo en la definición de áreas de Planificación para subcontratistas, transacción OMIZ, donde se indica un proveedor que es difícil que podamos definir igual en todos los sistemas por la definición de los rangos de números). Y habrá llevar cuidado con sobrescribir los valores configurados en productivo con transportes realizados desde el sistema de desarrollo.
Algunos de los ejemplos de transacciones que podemos tener abiertas en productivo:
OB52: periodos contables abiertos en finanzas.
OB58: estructuras de balance, donde se indicas las cuentas contables asociadas.
OB08: tipos de cambio.
OMIZ: areas de planificación (definición de subcontratistas).
OMT3E: parámetros de usuario personalización maestro materiales.
0VTC: definición de rutas de transporte.
Parametros para pedidos de traslado (cliente asociado al centro o almacen): vista V_001W_IV o cluster vista MB_DELIV (transacción SM34).
Según se describe de forma general en la nota 135028 de Sap, la operativa para abrir una transacción de Custo en un sistema productivo sería la siguiente (versión >= 4.6):
Buscamos en el árbol de parametrización (transacción SPRO), la opción de custo que queremos abrir. Una vez localizada, pulsamos en ella con el botón derecho del ratón y seleccionamos la opción “Visualizar información técnica”.
A continuación seleccionamos la pestaña “Obj.actualiz.“. La lista de objetos de parametrización estará en la parte inferior de la pantalla, donde pone Objetos asignados.
Haciendo doble clic en el objeto (V_001W_IV en la imagen), podemos hacer que la parametrización se puede realizar directamente en productivo marcando el flag “Parámetros actuales”. Esta configuración la realizaremos en el sistema de desarrollo y la transportaremos a productivo para hacerla efectiva.
De forma alternativa, una vez conocidos los objetos de parametrización, se pueden modificar igualmente el valor indicado accediendo a la transacción SOBJ.
En el caso de que nos interese añadir la transacción (si el punto de custo dispone de ella) en los menús de usuario, podríamos hacerlo mediante los roles de autorizaciones (transacción PFCG) o en los menús estándar haciendo una ampliación del menú a través de la transacción SE43 o SE43N, tal y como explicamos en una entrada anterior del blog (ver link).
Nota: es posible que para algunas parametrizaciones Sap no permita la configuración descrita en este post.
Bibliografia:
Existen multitud de notas relacionadas con este tópico, algunas de las más interesantes son:
SAP Note 388936 – OMD0, OMIQ: maintenance not possible, message TK430
SAP Note 317650 – Transporting MRP areas between systems
SAP Note 356483 – Customizing: Current settings in the test system
SAP Note 135028 – Transfer IMG activity to current setting
La transacción VOFM nos permite definir las rutinas que utilizamos en diferentes lugares del sistema, como rutinas condicionales en los esquemas de procesamiento de mensajes, rutinas para el control de copia en los documentos comerciales (pedidos, entregas, facturas), rutinas para utilizar en el esquema de calculo (formulas, condiciones, etc).
Por ejemplo, podemos ver en la imagen siguiente unas rutinas de transferencia de datos para la facturación, que utilizaremos en la configuración del control de copia (transacción VTFL para la facturación desde la entrega o VTFA desde el pedido).
Con estas rutinas podemos personalizar el comportamiento del sistema en los diferentes puntos susceptibles de su utilización.
Cuando creamos nuevas rutinas, hemos siempre de acordarnos, al transportar los objetos del sistema de calidad o productivo, de ejecutar el report RV80HGEN, que realiza la generación del código abap correspondiente y la activación de los objetos. Si no realizamos este paso, no funcionará correctamente en el sistema destino la configuración realizada.
En este post os voy a contar un pequeño truco para obviar la ejecución manual de este report. Lo que haremos será, en la misma orden de transporte donde hayamos incluido los objetos de workbench o desarrollo, incluir una entrada para la ejecución automática del programa RV80HGEN en el momento de importar la orden en el sistema destino.
Para ello, una vez localizada la orden, accederemos a la transacción SE09, seleccionaremos la orden y pulsaremos el botón modificar.
Incluiremos la entrada:
ID Programa: R3TR
Tipo Objeto: XPRA
Nombre objeto: RV80HGEN
Cuando realicemos la importación de la orden, veremos que tarda un poco más de lo normal, apareciendo el mensaje “Execution of reports after import”. En ese momento se realizará la ejecución del report RV80HGEN y automatizaremos el proceso de transporte, sin necesidad de ejecutar posteriormente el report manualmente.
En el log de importación de la orden podremos ver el log de ejecución del programa y localizar cualquier problema que pudiera ocurrir.
Desde siempre nos hemos quejado lo compleja que es la actualización del maestro de materiales y las pocas herramientas que proporcionaba Sap (en el producto ERP) para gestionar la creación, mantenimiento o ampliación de los datos del maestro de materiales.
Esto es evidente cuando estamos en instalaciones complejas, con muchos centros, sociedades, etc. La carencia en parte se cubría con alguna de las transacciones clásicas:
Actualización masiva del maestro de materiales: a través de la transacción MM17 Sap nos permite realizar modificaciones masivas en los materiales existentes, siempre respetando las validaciones que se hacen si esos mismos cambios los realizáramos en las transacciones clásicas (MM02). Esta transacción esta básicamente pensada para realizar modificaciones en masa, aunque también permite, con restricciones, ampliar un material.
Ampliación de vistas de almacén: con las transacciones MMSC y MMSC_MASS podemos realizar una ampliación de la vista de almacén del material (centro/almacén). Muy útil cuando tenemos varios almacenes en un centro y queremos extender el material a todos los almacenes.
Ampliación de vistas del material: a través de la transacción MM50 se pueden ampliar las vistas de un material. Por ejemplo, es muy útil para ampliar las vistas de ventas de un material para todas las áreas de ventas o para los centros existentes. Nos permite indicar un material y unidad organizativa modelo para el proceso. El proceso en si no es masivo, ya que equivale a una actualización manual, donde vamos pasando por las diferentes pantallas de las nuevas vistas.
Os dejo un link de Narayana Nagaraju en los blogs de Sap donde se explica en detalle el funcionamiento de esta transacción MM50:
Por suerte, a través de la nota 1880324 Sap liberó a finales de 2013 la transacción MMCC, que permite la creación y ampliación de forma masiva del maestro de materiales. La disponibilidad de esta transacción ha facilitado la vida a los usuarios que gestionan el maestro de materiales.
La transacción permite realizar las siguientes funciones:
Creación de masiva de un numero determinado de materiales tomando como modelo un material existente, seleccionando las unidades organizativas a utilizar como origen y destino.
Ampliar un material ya existente en otras unidades organizativas.
Modificar las vistas de un material existente.
Las tablas que se pueden actualizar con la transacción son las siguientes:
MARA, MARM, MEAN, MAKT, STXH (datos básicos)
MARC, MPOP, MLAN, STXH (datos de centro)
MARD (datos de almacén)
MVKE, MLAN, STXH (datos de ventas)
MLGN, MLGT (datos de WM)
MBEW (datos de valoración, vista de contabilidad)
Os recomiendo leer la nota 1880324 donde se explica en detalle todas las posibilidades de la transacción y la forma de operar según el tipo de operación que deseemos realizar.
Por ejemplo, tenemos un material en nuestro sistema (creado en un centro) que queremos ampliar al resto de centros existentes. Indicamos en la pantalla inicial el material modelo, las tablas a ser creadas (datos de centro, datos de almacén, datos de ventas y datos de valoración) y el tipo de ejecución. Podemos filtrar las unidades organizativas que se leerán del material modelo para la propuesta de copia/creación con los filtros.
A continuación, indicamos el material que queremos ampliar
A continuación indicaremos en cada una de las pestañas las diferentes unidades organizativas a crear y la queremos utilizar como modelo.
Finalmente ejecutaremos y se mostrará un log de las acciones realizadas. Si hay algún problema se mostrará en este momento.
Como resultado, tenemos a nuestro material 259 creado en todos los centros y organizaciones de ventas indicadas.
Como otro ejemplo, la creación de un material que queremos que sea exactamente igual que un material ya creado. Indicamos en la pantalla inicial que queremos crear todas las tablas del nuevo material, material modelo y selección de las unidades organizativas del modelo.
En la pantalla de materiales dejaremos el código de material en blanco para indicar que vamos a crear 1 o n materiales nuevos (si tuviéramos numeración externa indicaríamos el nuevo número de material según la codificación utilizada):
Revisamos las pestañas de los diferentes datos (estarán las unidades organizativas filtradas del material modelo y el código de la unidad organizativa destino, que podremos modificar).
Finalmente ejecutamos y se realizará la creación de los nuevos materiales, en las unidades organizativas indicadas tomando como modelo el material introducido.
Como algunas de las restricciones conocidas, podemos indicar que no se copiaran ni crearan los siguientes datos del maestro:
Vista de clasificación. Podremos utilizar de forma alternativa la transacción CLMM.
Gestión documental (DMS).
Información de configurables.
Datos de areas de MRP.
Datos de calidad.
Información complementaria de los materiales: condiciones de precio, listas de materiales, versiones de productos, etc.
Ademas, otras recomendaciones que indica SAP:
No cambiar el material modelo durante el proceso de copia.
El tipo de material de los materiales a crear se transfiere del material de referencia o modelo y no se puede cambiar.
No permite una selección de las vistas a crear (como en la MM50), sino que trabaja a nivel de tablas.
Adicionalmente, la transacción dispone de una transacción de parametrización (MMCU), donde pueden fijar valores por defecto a los usuarios, que pueden ser seleccionados en la ejecución de la transacción MMCC si se desea.
Igualmente, existe una BADI, llamada BADI_MATERIAL_CC, que nos permite intervenir en el proceso de creación o ampliación de los materiales con nuestros propios criterios (la creación se realiza via IDOC y podemos modificar su contenido antes del lanzamiento de la creación).
Como sabéis, cada país tiene sus propios números fiscales que sirven para identificar a los contribuyentes (empresas, organismos, administraciones públicas, personas físicas, etc). Normalmente es un código de diferente longitud que según el estado tiene una estructura diferente, dígitos de control, etc.
Por ejemplo, en España el identificador fiscal se llama NIF o CIF, con el siguiente formato:
NIF/NIE formato:
[C1 C2 C3 C4 C5 C6 C7 C8 C9]
Donde C1 a C9 son digitos.
Valores:
C1
C2 C3 C4 C5 C6 C7 C8
C9
Alfabético o numérico.
Numérico.
Alfabético.
Reglas:
C1
Dependiendo del tipo de entidad:A Sociedad Anónima
B Sociedad de Responsabilidad Limitada
C Sociedades Colectivas
D Sociedades Comanditarias
E Comunidades de Bienes
F Sociedades Cooperativas
G Asociaciones
H Comunidades de propietarios en régimen de propiedad horizontal
J Sociedades civiles con o sin personalidad jurídica
P Corporaciones Locales)
Q Organismos Autónomos
R Congregaciones e instituciones religiosas
S Órganos de la administración del estado y de las Comunidades Autónomas
U Uniones Temporales de Empresas
V – Otros tipos no definidos en el resto de claves
Para personas físicas:
Este dígito corresponderá con el primer número de su DNI o documento de identidad.
Para extranjeros:
X,L,K,M
C2 C3
Para empresas y organizamos representa la provincia.
Son números aleatorios para las personas físicas.
C4 C5 C6 C7 C8
Numeros aleatorios
C9
Digito de control.
Ejemplo:
A58295296
1er digito: Tipo entidad – “A” Sociedad Anónima –2º y 3er Digito: Ciudad – “58” Barcelona
Sap implementa los algoritmos de chequeo de los identificadores fiscales para que los números introducidos en los clientes o en los proveedores sean correctos respecto a la legislación de cada país.
En la parametrización de chequeo por país, en la ruta de custo Sap Netweaver –> Parametrizaciones Generales –> Configurar países –> Configurar verificaciones específicas de país (o a través de la transacción OY17), podemos ver las reglas de verificación de los identificadores fiscales(en lo referente a longitudes).
En este mismo punto de parametrización podemos ver otros chequeos como los referentes a códigos postales, cuentas de bancos, etc.
Además de esta parametrización, Sap implementa la programación en el correspondiente módulo de función donde está programada la verificación según la legislación de cada país.
Para poder localizar esta programación, existe una vista, llamada V_TFKTAXNUMTYPE (transacción SM30), donde podemos ver los diferentes identificadores fiscales de cada país y la rutina utilizada para realizar la verificación (modulo de función).
Por ejemplo, para el NIF de España se utiliza el Módulo de función BUPA_TAX_NUMBER_CHECK, que a su vez llama al MF TAX_NUMBER_CHECK. La programación se encuentra en el grupo de funciones TSRV (podemos verlos con la transacción SE80).
En el módulo de función TAX_NUMBER_CHECK se realizan las comprobaciones generales de longitudes del identificador según la parametrización de la OY17. Y a continuación realiza la comprobación según el algoritmo específico del país del interlocutor.
Por ejemplo, para España, la verificación se realiza dentro de dicho módulo de función, con las rutinas form:
check_taxcode_es
check_taxcode_companies
check_taxcode_foreigners
check_taxcode_persons
Para la verificación del llamada NIF Comunitario (para la comunidad europea), se utiliza el MF VAT_REGISTRATION_NUMBER_CHECK, que a su vez utiliza el MF EU_TAX_NUMBER_CHECK.
Cuando hay algún cambio legal, Sap libera las correspondientes notas que modifican la lógica de las comprobaciones para adaptar a la legislación actual de cada país.
En la página Wiki de Sap existe una documentación completa de los países soportados por Sap y los diferentes identificadores fiscales existentes en cada país, con sus formatos y chequeos (incluidos en el componente CRM-BF-TAX, válido no solo para CRM, sino también para los módulos FI o SD del ERP).
Tras muchos años de espera (yo llevo casi 20 con Sap y echaba de menos algo así), Sap liberó en 2013 el famoso monitor de pedidos, a través de la transacción VA06 (ver nota 1797205). Esta disponible a partir del EHP5, aplicando los correspondientes niveles de parches.
Básicamente, el monitor nos permite realizar los controles más habituales sobre los pedidos, como:
Pedidos de cliente incompletos
Bloqueos de entrega
Posiciones no confirmadas
Pedidos atrasados
Pedidos con la entrega pendiente de procesar
Pedidos con bloqueos de crédito
Control de los pedidos de venta asociados a pedidos de compra o pedidos a terceros
Mucha de esta información ya la podemos obtener desde otras transacciones, pero en la VA06 tenemos toda la información en un único sitio y podemos ver de forma detallada los status del documento, tanto a nivel de cabecera como de posiciones.
Al acceder a la transacción, podremos ver los criterios de selección disponibles, donde en la parte superior podremos indicar el tipo de selección a realizar, incluyendo todos los pedidos, solo los incompletos o realizar un filtrado selectivo por los diferentes estados posibles del pedido.
En la parte inferior disponemos de las diferentes pestañas para realizar el filtrado de los documentos a seleccionar, pudiendo definirlo por:
Datos del pedido: numero de documento, fecha de creación, solicitante, clase de documento o tipo de posición.
Datos organizativos: organización de ventas, canal, sector, oficina de ventas, grupo de vendedores o centro.
Datos del material: código de material o grupo de artículos.
Ampliaciones: criterios adicionales de cliente.
Interesante la opción disponible en la parte inferior, llamada “Sel.pedido cliente completo si crit.selección son relativos a posición”. Nos permite seleccionar un documento completo en el que alguna de las posiciones cumplan las condiciones de selección.
Tras ejecutar el informe, visualizaremos dos ventanas ALV, donde podremos ver por un lado las cabeceras de los pedidos, y al seleccionar cada documento en ese ventana, las posiciones del documento en el ALV inferior.
A nivel de cabecera, podremos ver muchísimos datos del documento, con especial interés la información sobre el estado: documento incompleto, bloqueo de entrega, bloqueo de crédito, situación de la verificación de disponibilidad, si el documento está retrasado, status del documento sobre si se ha creado entrega o se ha hecho la salida de mercancía sobre esta, etc. Además Sap utiliza semáforos que nos permiten ver la información con más claridad.
A nivel de posición, podemos ver las cantidades de pedido, fecha de entrega, importe, cantidades confirmadas, estado de confirmación, datos incompletos, entrega o salida de mercancia; numero de entrega y su situacion, etc.
La transacción VA06 también puede ser personalizada a través de la BADI SD_OSO_MONITOR, pudiendo alterar tanto los criterios de selección como los resultados del informe.
En la nota 2650306 del OSS se explica como realizar esta personalización, incluyendo un documento con un ejemplo de como hacerlo.
Como material complementario, os dejo un vídeo de un tema relacionado con la VA06, que trata sobre la gestión de los pedidos atrasados y como gestionarlos con la transacción V_V2.
Estas y otros funcionalidades se explican en el curso SAP SD que imparten en saplearn.es y que comienza el próximo 14 de enero de 2018 (3ª Edición). Este año, como novedad, se incluye una sesión donde se explican las diferencias con el nuevo S4/Hana, con sesión práctica incluida. Todavía hay plazas disponibles.
Hoy vamos a hablar de una clásica necesidad en la mayoría de proyectos o durante el soporte a una instalación Sap ya en funcionamiento. Anteriormente, los informes de compras eran difícilmente ampliables, a no ser que utilizaremos algún tipo de enhacement o copia de los informes estándar. Eso hacia complicado el cubrir requerimientos de usuario para añadir nuevas columnas en los resultados de los diferentes informes de compras.
Por ejemplo, en los informes:
Informes de registros info: ME1L, ME1M.
Informes de pedidos: ME2*.
Informes de contratos marco (pedidos abiertos, planes de entrega): ME3*.
Informes de solicitudes de pedido: ME5A, ME5K.
Liberación colectiva de documentos: ME55 para solicitudes de pedido, ME28 para pedidos o ME35 para otros documentos de compra.
Informes de libros de pedido (ME0M) o regulación por cuotas (MEQM)
Historial de precios de pedido (ME1P).
Informes de ofertas: ME4L, ME4M, etc.
A partir de la versión 6, EhP4, Sapp pone a disposición de los clientes la BADI ME_CHANGE_OUTTAB_CUS para poder personalizar todos estos informes estándar.
Con la badi podemos intervenir en los datos que se visualizan en los ALV de estas transacciones, de la siguiente manera:
Cambiar la información estándar que se determina en los informes (por ejemplo, proveedor, material).
Mostrar información estándar adicional, de los documentos o datos maestros.
Mostrar campos de cliente.
La BADI no se llama en las siguientes transacciones: ME80* ( ME80FN, ME80RN) ni en las ME56, ME57, ME58 o ME59N (transacciones para el tratamiento de las solicitudes de pedido y la conversión automática a pedido).
Requerimientos:
Habria que activar la business function LOG_MMFI_P2P ( MM, Integration of Materials Management and Financial Accounting), aunque de mi experiencia os puedo decir que he podido utilizar la badi sin activar la BF y funciona.
Ademas, es necesario utilizar en todas las transacciones indicadas la visualización ALV (se define en la parametrización, asociada a los Alcances de la lista).
En la parametrización se indica por el código de alcance si se utiliza la visualización ALV por defecto.
Igualmente, es un requisito utilizar el parámetro ME_USE_GRID = X, que fuerza la visualización ALV en las transacciones donde no se puede indicar un alcance de lista (por ejemplo, en la ME1L o ME1M).
La BADI no esta disponible en versiones inferiores a la EhP4 ni puede ser bajada a versiones inferiores. No es dependiente de filtro y se puede realizar múltiples implementaciones de ella (se ejecutarán todas). Por ejemplo, podríamos hacer una implementación por transacción que queramos ampliar.
No esta activa por defecto en el sistema.
Ejemplo de Implementación.
En nuestro ejemplo, vamos a ampliar el listado de pedido (ME2X) con varios campos del pedido que son útiles para los usuarios de mi sistema y que no se muestran por defecto. También podríamos haberlo hecho en el informe de liberación colectiva de pedidos (ME28).
Crearemos una implementación de la BADI ME_CHANGE_OUTTAB_CUS utilizando la transacción SE18.
La BADI solo tiene un método, llamada FILL_OUTTAB, que recibe la siguiente información:
Nombre de la estructura: en la variable IM_STRUCT_NAME. En este campo recibiremos diferentes valores según la transacción en la que nos encontremos (por ejemplo, MEREP_OUTTAB_PURCHDOC_REL para los informes de liberación colectiva de pedidos; MEREP_OUTTAB_PURCHDOC para los informes de pedidos, ofertas o contratos ; MEREP_OUTTAB_EBAN para los informes de solpeds; MEREP_OUTTAB_INFREC para los informes de registros info; EORD para los informes del libro de pedidos; MEREP_OUTTAB_QUOTA para regulación por cuotas; MEREP_OUTTAB_PRHIS para el historial de precios de pedido (transacción ME1P) , etc)
Información a mostrar en los resultados del informe: en la tabla interna CH_OUTTAB. Para hacer el tratamiento de la tabla habrá que declarar un field-symbol con la estructura indicada en IM_STRUCT_NAME.
En la implementación de la BADI incluiremos el código personalizado para el llenado de los campos estándar.
En el caso de querer añadir campos en los resultados (tanto estándar que no se muestran como campos de cliente), tendremos que ampliar la estructura de datos correspondiente con un append en la transacción SE11. En nuestro ejemplo, hemos añadido 3 campos estándar y una campo Z.
Si los campos están en las tablas estándar, se llenará automáticamente en la estructura sin hacer nada. En caso contrario, habrá que realizar la lógica de llenado.
Os pego el ejemplo del código utilizado para el ejemplo indicado:
FIELD-SYMBOLS: <fs_outtab> TYPE any, <fs_ebeln> TYPE ebeln, <fs_ebelp> TYPE ebelp. FIELD-SYMBOLS: <fs_zzaedat> TYPE datum.
* check that a purchasing document view is displayed CHECK im_struct_name EQ 'MEREP_OUTTAB_PURCHDOC'.
* loop at the output table and assign a field symbol LOOP AT ch_outtab ASSIGNING <fs_outtab>.
*-- assign the purchasing document number to a field symbol ASSIGN COMPONENT 'EBELN' OF STRUCTURE <fs_outtab> TO <fs_ebeln>. CHECK sy-subrc = 0. *-- assign the purchasing document item number to a field symbol ASSIGN COMPONENT 'EBELP' OF STRUCTURE <fs_outtab> TO <fs_ebelp>. CHECK sy-subrc = 0.
ASSIGN COMPONENT 'ZZAEDAT' OF STRUCTURE <fs_outtab> TO <fs_zzaedat>. CHECK sy-subrc = 0. CLEAR <fs_zzaedat>.
En nuestro truco de hoy vamos a hablar de como desbloquear variantes de selección que haya creado otro usuario (y bloqueado), y que necesitemos modificar (seguramente el usuario ya no estará en la empresa).
Antes de eso, vamos a hablar un poco de las variantes de selección y a ver que comos podemos hacer con ellas.
Como todos sabéis, en cualquier report abap en el que se puedan indicar criterios de selección, Sap nos ofrece la opción de grabar esos criterios de selección en forma de variante, para su posterior reutilización en el mismo programa o para planificar jobs de fondo que utilicen esos mismos criterios de filtrado o selección.
Las variantes se salvan con el botón grabar en la pantalla inicial de los programas y se pueden recuperar como vemos en la imagen previa. Al grabar, podemos configurar las siguientes propiedades de la variante:
Indicar valores para la selección: valores individuales o intervalos incluidos o excluidos, uso de comodines en la selección (*, etc).
Proteger la variante: para evitar que cualquier usuario aparte del creador pueda modificarla.
Restringir su uso solo para procesos de fondo.
Proteger campos: evitar que se pueda modificar el valor indicado en un campo en la variante.
Suprimir campos: eliminar de la visualización campos de la pantalla o el botón para selección múltiple.
Grabar campo sin valores: forzamos a que un campo determinado se grabe en la variantes sin valores de selección, pese a que tuviéramos valores indicados en el campo.
Desactivar GPA: forzar a que no se tomen de la memoria de usuario los campos que se hayan programado de estas manera (funcionalidad SET/GET).
Campo obligatorio: hacer requerido para el usuario que se introduzca algún valor en el campo.
Uso de variables de selección en los campos fecha: se puede trabajar con variables de fecha dinámica, que nos inicializaran el contenido del campo al utilizar la variante (en el momento de recuperarla).
Por ejemplo, podremos indicar la fecha del día actual, fecha del día +/- número de días, primer dia del mes actual o anterior, ultimo día del mes actual o anterior, primer día del próximo mes, primer día laboral del mes actual (utilizando calendarios de la SCAL), etc.
Esto nos permite personalizar la ejecución de programas donde se utilizan campos de fecha (por ejemplo, la transacción MMPV para realizar el cambio de periodos contables de MM, que se podrá planificar con un job de fondo para realizar el cambio de periodo el día 1 de cada mes).
Todas estas opciones se podrán indicar en el momento de grabar la variante.
En el caso de que necesitéis gestionar variantes ya creadas, os recomiendo las siguientes utilidades:
Desbloquear variantes creadas por otro usuario: no es necesario copiar la variante con otro nombre para poder hacerlo. Bastará con utilizar el report RSVARENT.
Transporte de variantes entre sistemas: en ocasiones necesitamos llevarnos las variantes de un sistema a otro. No es necesario crearlas manualmente, podéis utilizar el report RSTRANSP. El sistema nos pedirá el report y las variantes a transportar, y tras seleccionar las deseadas, nos pedirá la orden de transporte para llevarlas de un sistema a otro.
Modificación de los valores de las variantes: todas las variantes se pueden gestionar desde la misma transacción SE38, con la opción VARIANTES.
Desde aquí podremos modificar tanto los valores de la variante, como los atributos detallados. Si necesidad de acceder a la ejecución del programa para realizar el cambio de valores o variables asociadas a la variante.
Espero que os sea de utilidad. Nos acercamos al truco 100 y os adelanto que la primavera va a venir este año cargada de nuevos trucos y muchas novedades en el blog.
Hoy estamos de aniversario. Cumplimos nuestro truco número 100 y ya casi 9 años desde aquel 7 de noviembre de 2010 cuando escribí mi primera entrada en este blog. Ha llovido un poco, la verdad.
Lo que empezó siendo un blog de notas personal sobre SAP fue tomando vida durante estos años, ganando contenido, haciendose mayor al fin y al cabo. Muy orgulloso de él y de que me haya permitido conocer muchas cosas de este sistema y a muchísima gente por todas las empresas por las que he pasado durante los últimos tiempos. Todo un placer haberlo compartido con vosotros.
En nuestro truco de hoy volvemos a temas más funcionales, en concreto del modulo de SD y vamos a hablar de la funcionalidad de consigna de cliente.
Como muchos de vosotros sabéis, en la funcionalidad que Sap tiene disponible en el módulo de SD podemos gestionar los procesos donde nosotros cedemos stock sin cargo a los clientes (el stock sigue perteneciendo al vendedor). Cuando el cliente notifica el consumo de los stocks, se realiza la correspondiente facturación y descuento de esos stocks especiales (stock W).
De forma resumida podéis ver en la siguiente imagen las diferentes operativas disponibles por estándar en la funcionalidad de consigna:
Básicamente, los flujos de consigna consisten en las siguientes clases de documento, cada uno de ellos con el siguiente cometido:
Pedido KB – Reposición de artículos en consignación: nos permite realizar la entrega de stock en deposito al cliente. Es un pedido sin precio, y el proceso comercial termina en la entrega, traspasándose el stock de libre utilización al stock de consigna (W), asociado al solicitante. No hay facturación.
Pedido KE – Toma de artículos en consignación: cuando el cliente nos notifica los consumos del stock de consigna, se genera un documento de este tipo. Nos permite consumir el stock W mediante la entrega y realizar la facturación al cliente de los productos de consigna utilizados.
Pedido KA – Recogida de artículos en consignación: si el cliente nos devuelve el stock en consigna sin haberlo consumido, utilizaremos este circuito. Con la entrega daremos de baja el stock W y lo devolveremos a stock de libre utilización en nuestro almacén. Tampoco hay factura ni precio en este caso.
Pedido KR – Retorno de artículos en consignación: nos permite gestionar la devolución a stock de consigna de un stock previamente consumido. La entrega hace la entrada de stock en stock W, y nos permite abonar al cliente los stocks devueltos (si hay facturación).
Los stocks asociados a la consigna (stock especial W), se pueden consultar con las transacciones clásicas de gestión de stocks (MB52 o MMBE).
También podéis utilizar de forma concreta solo para dicho tipo de stock la transacción MB58.
Los stocks en consigna se encuentran en la instalación del cliente, pero a nivel contable siguen perteneciendo a nuestra empresa, aunque en estos informes de stocks los veremos sin almacén asociado (no están en nuestra ubicación), y siempre asociados a un stock especial W, con identificador el número de cliente (por ejemplo, como vemos en la MB52)
Por defecto, Sap utiliza el solicitante de los pedidos (función de interlocutor AG) para identificar el stock especial asociado a los procesos de consigna.
Aquí es donde vamos a hablar de nuestro truco de hoy. Si necesitáis que los stocks se gestionen asociados a cada uno de los destinatarios de mercancía, podremos hacerlo utilizando funciones de interlocutor especiales. Pensar en el caso de un cliente retailer, con un conjunto de tiendas, donde queremos gestionar de forma separada el stock entregado en cada tienda (en lugar de gestionar de forma general al cliente).
La solución es tan sencilla como utilizar en nuestros documentos de consignación la función de interlocutor SB Respons. stock espec., que deberá de tener el mismo valor en el documento que la función de interlocutor WE Destinatario de mercancía.
Cuando realicemos la entrega, la función de interlocutor SB viajará a la entrega y será tenida en cuenta en el momento de generar los documentos de material. Todos los movimientos de stock especial W utilizarán dicho interlocutor en lugar del solicitante.
La función de interlocutor SB se podrá indicar en los datos maestros del cliente para que sea propuesta al crear los pedidos.
Para el correcto funcionamiento del circuito, habrá que permitir la función de interlocutor en los esquema de interlocutor de los grupos de cuenta (cliente) o documentos de ventas y entregas. Igualmente, habrá que autorizar al grupo de cuentas del cliente el poder desempeñar la función de interlocutor SB (ver bibliografía con todos los detalles de parametrización necesarios).
Recibo con frecuencia consultas sobre problemas relacionados con las estrategias de liberación en compras (módulo MM). Voy a intentar hacer un resumen de los problemas más habituales y la forma de solucionarlos. En primer lugar vamos a enumerar algunos de ellos:
¿Se puede utilizar más de una clase para definir las estrategias de liberación a nivel de los pedidos?.
¿Que pasa cuando tenemos más de una moneda en los procesos de compra y como afecta esto a las estrategias de liberación?.
¿Los valores de clasificación en las estrategias de liberación se transportan entre sistemas dentro de las ordenes de transporte?.
¿Que ocurre cuando borramos las estrategias de liberación, pero no borramos los valores de clasificación?.
¿Tenemos alguna forma de chequear las inconsistencias dentro de las estrategias de liberación?.
¿Que ocurre cuando definimos estrategias de liberación utilizando valores que están en las posiciones de los documentos y los valores difieren entre una posición y otro dentro del mismo documento?.
¿Que ocurre cuando un documento ya esta liberado y se modifica?
¿Se puede definir criterios en las estrategias de liberación Z o propios del usuario, fuera de los estándar?
¿Porque un usuario puede liberar documentos a los que no tendría que tener acceso?.
Estos podrían ser alguno de los problemas más comunes (seguro que hay más), vamos a ver que hacer en cada caso.
1. Clase para las estrategias.
Cuando definimos las estrategias de liberación, en primer lugar creamos un grupo de liberación al que asignamos la clase donde hemos definido las características que utilizaremos en nuestras estrategias (ver la entrada del blog donde hablamos de la forma de configurar las estrategias).
Sap solo permite utilizar una clase. Si intentamos crear un grupo de liberación con otra clase, el sistema nos muestra este mensaje de error al grabar.
Por tanto, no es posible. Esto es importante, porque la clase que definamos para la liberación de documentos de compra (pedidos, contratos, ofertas), solpeds o hojas de entrada de servicio tendrá que tener todas las características necesarias para poder utilizarla en todos los escenarios posibles.
2. Varias monedas en los procesos de compra.
En las estrategias de liberación solemos utilizar el valor neto del pedido como criterio para realizar la definición de estas, requiriendo diferentes liberadores según los importes del documento. Este valor lo tenemos en el campo GNETW en la estructura de intercambio para las estrategias.
Cuando nosotros creamos un pedido, el sistema toma la moneda de la cabecera del documento y la convierte, utilizando el tipo de cambio, a la moneda de la sociedad donde estemos creando el pedido. Finalmente, Sap convierte este importe a la moneda de la característica en la estrategia de liberación (si fuera diferente). En el caso de trabajar con diferentes monedas, tendremos que tener esto en cuenta.
El estándar no soporta el trabajar con varias monedas. Cuando creamos la característica para el importe, le hemos de indicar una moneda (transacción CT04).
Ante esto, para el caso de estar en un sistema con sociedades diferentes que trabajan con varias monedas, tenemos varias alternativas disponibles:
Modificar el comportamiento estándar del sistema utilizando la exit EXIT_SAPLEBND_002 (ampliación M06E0004).
Elegir una moneda como referencia y crear las estrategias haciendo todas las conversiones de importes a esa moneda (por ejemplo, si trabajamos con EUR y USD, yo mis estrategias las defino en EUR). Cuando entre un pedido de la sociedad en USD, se convertirá el importe a EUR y se determinarán las estrategias según este importe. Esta suele ser la forma habitual de trabajar.
Crear dos características para los importes, uno para la moneda EUR y otro para la moneda USD. Tener en cuenta que en todas las estrategias habrá que informar los valores de las dos características.
En este, la condición de la característica del importe que no corresponde a la moneda de sociedad se tendrá que cumplir siempre. Con esta alternativa puede ser complicado configurar el sistema si tenemos más de 2 monedas.
3. Transporte de la parametrización de las estrategias de liberación.
Cuando configuramos las estrategias de liberación, los valores de parametrización (tablas T16FK, T16FV, T16FS, T16FC and T16FG ) son incluidos en la orden de transporte. Pero no así los valores de clasificación que indicamos en nuestra estrategia. Igualmente, si hemos creado una clase nueva o las correspondientes características, estas tampoco serán transportadas.
Esta información tendremos que replicarla en cada sistema, una vez transportada la correspondiente orden de transporte (la clase y las características las crearemos antes del transporte). Es posible automatizar el traspaso de los valores de clasificación utilizando ALE. En una entrada anterior del blog hablamos de este problema y proporcionamos un documento con los elemento a configurar para poder realizar el trasporte de los valores de clasificación en las estrategias. Sobre todo recomendable en sistema donde tenemos gran complejidad en las estrategias de liberación con muchos registros de configuración.
4. Borrado o cambios en la clasificación de las estrategias de liberación.
Si borramos estrategias en la parametrización de SAP, hemos de asegurarnos que también se borra la información de clasificación. Es habitual que esto no se haga y tengamos comportamientos inesperados en la asignación de estrategias a los documentos.
Para ello, nos aseguraremos que hemos borrado la asignación de la clasificación a la estrategia usando la transaccion CL24N.
Otro chequeo interesante es utilizar la CL30N para hacer una simulación de la estrategia que sería asignada a un documento. Indicamos los criterios del documento utilizados en la clasificación, importe, etc y buscamos las estrategias que cumplen la condición. Solo debería de aparecer una.
Si hay mas de una, deberemos de revisar la configuración de nuestras estrategias, ya que es incorrecta.
5. Chequeo de inconsistencias en las estrategias de liberación.
Cuando hacemos cambios importantes en las estrategias de liberación, es posible que la parametrización se nos quede en un estado inconsistente. En dicho caso, es conveniente seguir las instrucciones de la nota 365604, paso 5.
Podremos usar el report RCCLZUOB para chequear la consistencia, con el tipo de clase 032 y tabla de objecto KSSK. También la transacción OMGSCK que nos hace un chequeo general de toda la configuración de las estrategias.
6. Estrategias de liberación utilizando valores de posiciones.
Cuando definimos las estrategias de liberación, hay que tener cuidado si utilizamos campos que se encuentren a nivel de posición. Por ejemplo, el centro receptor o el grupo de artículos.
Según se explica en la nota OSS 47089, Sap intenta agregar el importe de las posiciones que tenga el mismo centro o grupo de artículos (si hemos definido estos campos en las características de la estrategia). Si hay posiciones con diferentes valores, Sap agrega todos los valores llevando el valor de los campos en blanco a la estrategia.
Esto puede hacer que no se determine una estrategia de liberación y tengamos problemas con algunos documentos.
La alternativa que da Sap es definir también una estrategia con el valor del centro o del grupo de materiales en blanco (que será la que aplique cuando se produzca este caso).
Otra opción será realizar controles por exit o badi para evitar que un documento tenga valores divergentes de centro o grupo de artículo en las posiciones. Tambien podemos intentar solucionarlo con las exits de las estrategias de liberación.
7. Modificabilidad de los documentos ya liberados.
Cuando definimos las estrategias de liberación, podemos gestionar como se comportaran estas cuando se realicen modificaciones en los documentos una vez ya liberados. Esto se indica en los indicadores de liberación, que no son más que los estados de liberación. Normalmente habrá uno de los “estados” que indicará que el documento está liberado, y con el valor “Modific.” en la su parametrización podremos configurar el comportamiento deseado:
Los posibles valores son los siguientes:
1 – No modificable: no se podrá modificar el pedido una vez se haya liberado (evitamos cualquier cambio después de su aprobación). Habría que anular la liberación para poder cambiarlo. 2 – Modificable, sin nueva determinación de estrategia: se permite modificar el pedido, y no se determina nunca una nueva liberación. 3 – Modificable, nvo.liberac.en caso nvo.estrat.: se permite modificar. Solo será una nueva liberación si cambia la información del documento y esto produce que se determine una nueva estrategia de liberación. 4 – Modificable, nvo.liberac si nueva estrat.o modif.val: se permite modificar. Será necesaría una nueva liberación si se cumplen las condiciones del valor 3 o el importe de modificación del pedido supera al porcentaje de modificación. 5 – Modificable, nueva liber.si nueva estrat./sal.: idem del 3, pero también afecta cuando el documento ya se ha impreso (en el caso 3 no afecta). 6 – Modificable, nvo.liberac.si nvo.etrat.sin modif.val./sal.: idem del 4, pero también afecta cuando el documento ya se ha impreso (en el caso 4 no afecta).
8. Criterios de selección propios en las estrategias de liberación.
Por suerte, Sap también nos deja la puerta abierta para definir nuestros propios criterios en la configuración de las estrategias de liberación.
En el truco 41 hablamos sobre ello y en la forma de hacerlo. Por un lado, tenemos que ampliar la correspondiente estructura de intercambio con una estructura append:
Solicitudes de pedido: estructura CEBAN.
Documentos de compras (pedido, oferta, contratos): estructura CEKKO.
Hojas de entrada de servicio: estructura CESSR.
Y a continuación utilizar la correspondiente ampliación (exit CMOD) para llenar los campos y que tengan valor cuando llegan al análisis de las estrategias.
Solicitudes de pedido: ampliación M06B0005, que llama al módulo de función EXIT_SAPLEBND_004.
Documentos de compra: ampliación M06E0004 , que llama al módulo de función EXIT_SAPLEBND_002.
Hoja de entrada de servicio: ampliación SRVREL, que llama al modulo de funcion EXIT_SAPLEBND_003.
9. Autorizaciones para las estrategias.
Si utilizamos estrategias de liberación en las solpeds sin clasificación, el objeto de autorización que se utiliza es el M_BANF_FRG.
En el resto de estrategias, cuando se utiliza clasificación (tanto en solpeds, documentos de compra o entrada de actividad en pedidos de servicios), el objeto de autorización utilizado es el M_EINK_FRG.
Cuando accedemos a las transacciones de liberación de solicitudes de pedido (ME29N) o de liberación de pedidos (ME54N), la persona autorizada puede visualizar y modificar el documento y efecturar su liberación con el código de liberación que le otorga la autorización. Se realiza en estos casos la verificación de autorización del objeto M_EINK_FRG.
Cuando se ha creado el pedido, el sistema ha revisado la parametrización del sistema y asignado una estrategia de liberación, incluida en un grupo de liberación.
Igualmente, en la estrategia se habrá asignado los códigos de liberación de los diferentes intervinientes en el proceso de liberación.
La combinación de esos dos valores será lo que necesite el usuario en sus roles de autorización, con el objeto M_EINK_FRG. En mi ejemplo, el usuario DIRECCION tendrá el valor Z1 en el campo FRGGR y Z3 en el campo FRGCO. Si el usuario no dispone de esos valores, no estará habilitado el botón para realizar la liberación.
Ejemplo de definición de Rol de autorizaciones con el objeto M_EINK_FRG
En las transacciones de liberación masiva (ME55 para solpeds o ME28 para pedidos), el usuario ha de indicar su código de liberación en los criterios de selección. Aquí se realizará igualmente la verificación de autorizaciones con el criterio indicado, y el usuario solo podrá ver los pedidos conforme a las autorizaciones asignadas.
10. Analizando nuestras estrategias.
Como hemos indicado, las estrategias utilizan el sistema de clasificación para definir las condiciones que se han de cumplir para que las estrategias apliquen. Tenemos varias transacciones interesantes para poder consultar los valores de la clasificación, como son las CL30N/CL31, CL20N,CL24N
Para mas información ver la entrada del blog donde hablábamos de esto. Y también de la posibilidad de realizar modificaciones masivas utilizando las transacciones CLMM o CL20N/CL24N(ver esta otra entrada del blog).
Bibliografía:
Si tenéis aun más dudas o problemas relacionados con las estrategias, os recomiendo revisar las siguientes notas de sap:
Supongo que muchos de vosotros, que todavía trabajáis con el “viejo” SAP R3 (ECC), tenéis curiosidad sobre los cambios que implica el nuevo ERP y os gustaría tener contacto con un sistema de este tipo y poder experimentar que cosas nos esperan cuando dentro de poco en vuestra empresas migréis al nuevo S4/HANA (en principio hay tiempo hasta el 2025) o quizás participéis en un proyecto de implantación de la nueva versión.
En nuestro truco de hoy vamos a hablar de los cambios más importantes que suponen S4/HANA y la forma de conseguir acceso a un sistema de demo en la nube.
Podemos decir que S4/HANA es la nueva generación del SAP Business Suite, con una evolución tecnológica basada en dos pilares principales:
Base de datos In Memory.
Dejamos de poder utilizar cualquier base de datos (Oracle, SqlServer, DB2, etc) para trabajar exclusivamente con la base de datos de SAP, que también se llama HANA. Con esta tecnología, toda la información se encuentra en memoria, dando un salto exponencial a nivel de velocidad de acceso a los datos, abriendo un abanico de capacidad de proceso, análisis o comunicación con otros sistemas que antes no eran viables con la tecnología de las bases de datos tradicionales.
Las tablas en HANA están basadas en columnas (no en registros como en las bases de datos tradicionales). Esto produce un acceso mucho más rápido (solo los columnas relevantes necesitan ser leídas en las querys).
Igualmente se realiza una mayor compresión de los datos y operaciones de proceso en paralelo. Esto nos permite disponer de capacidades analíticas en el ERP.
A esto se le unen otras mejoras como que desaparecen las tablas agregadas (que se calcularan en tiempo real) o que se ha rediseñado el esquema de base de datos (que comentaremos más adelante).
Mejora de la experiencia de usuario con Fiori.
Como todo no podían ser mejoras técnicas, también ha priorizado el desarrollo de una nueva interfaz de usuario utilizando Fiori (lo que no significa que no tengamos disponible el clásico Sapgui o Netweaver para acceder a nuestras transacciones de toda la vida).
El usuario dispone en su interfaz Fiori de Tiles o cuadros de aplicación para acceder a las transacciones fiorizadas (o convertidas), que pueden incluir también información analítica.
Sap ha desarrollado multitud de aplicaciones Fiori para los diferentes procesos de negocio, dejando la puerta abierta para que sus clientes y partners desarrollen sus propias aplicaciones Fiori (ver documento https://experience.sap.com/documents/sap-fiori-ux-overview.pdf )
Para que os hagáis una idea, así “suena” la aplicación Fiori para crear pedidos de compra.
O una aplicación de finanzas con capacidades analíticas donde podemos ver las partidas abiertas de cliente por fecha de vencimiento.
O un informe de stock para un material, desde el cual podemos lanzar directamente movimientos de material sin necesidad de acceder a otra aplicación (ver la parte inferior de la imagen, donde están las operaciones que se pueden lanzar desde la consulta de stocks).
Toda una revolución en la interfaz de usuario a la que ya le hacia falta una modernización después de tantos años.
Rediseño de las tablas en la base de datos.
Aprovechando el cambio tecnológico de la base de datos, Sap ha realizado un rediseño total de la estructura de tablas, reduciendo el número de estas, eliminando tablas de agregados, etc.
La compatibilidad con las tablas antiguas se mantiene utilizando vistas, para que en nuestros desarrollos podamos seguir utilizando las tablas clásicas.
Para que os hagáis una idea sin profundizar demasiado:
Ventas: desaparecen tablas de status, índices.
Gestión de stocks: todas las tablas de stocks se simplifican en la tabla MATDOC. En la nota 2206980 se explican los cambios más relevantes en las tablas de este módulo.
Contabilidad: se unifican las tablas de finanzas y controlling.
Desaparecen las tablas de agregados y sus valores se calculan en tiempo real a partir de las tablas de movimientos.
Otros cambios importantes.
Aunque la lista de cambios a nivel funcional podría ser muy larga, aquí os dejo algunas de las cosas que más me ha llamado la atención:
Clientes/proveedores: desaparecen las transacciones clásicas de clientes (XD??,FD??,VD??) o proveedores (XK??,FK??,MK?). Todos los interlocutores se gestionan ahora de forma centralizada usando la transacción BP.
Gestión de mensajes: podemos decidir continuar con la clásica gestión de mensajes via NAST o usar la nueva funcionalidad mucho más completa basada en BRF+ (ver nota 2228611).
Gestión de almacén con ubicaciones: desaparece el módulo WM y ahora se integra en Hana el sistema EWM, que anteriormente se vendía como un producto separado. Toda una revolución. EWM incluye aplicaciones de radio frecuencia estándar, gestión de operaciones en el almacén, etc.
ATP: cambios importantes en la verificación de disponibilidad.
Material Ledger: uso obligatorio de este componente para la valoración de los materiales.
Determinación de fuente de aprovisionamiento en MM: cambia la lógica y se simplifica el uso del libro de pedidos (ver enlace).
Para ayudarnos a ver la implicación de los cambios, transacciones que quedan obsoletas, nuevas funcionalidades, etc., Sap ha creado la “Simplifications list“, donde se detallan todas estas cosas, junto con acceso a las notas OSS relevantes en cada ámbito.
Como veis, nos va a tocar volver a aprender lo aprendido, cambiar el chip en muchos temas y al fin y al cabo reciclarnos. Aunque sin olvidar que al fin y al cabo estamos en un producto de SAP y muchas cosas serán iguales o parecidas a las que ya conocíamos.
Sistema de Demo gratuito via Cloud.
Si tenéis interés en empezar a andar el camino, o por los menos investigar sobre lo que nos espera, Sap ofrece una versión trial de S4/HANA Cloud para que podamos empezar a conocer el producto y nos hagamos una idea de sus nuevas funcionalidades. Podéis acceder a ella en el enlace siguiente:
Una vez registrados, tendremos acceso durante un mes a un sistema limitado de pruebas via Cloud (solo están disponibles algunos de los Tiles de la versión completa). El acceso se puede ir renovando para continuar durante más tiempo.
Como funcionalidad interesante de la trial, tenemos unos Guided Tours que nos muestran mediante un asistente alguna de la funcionalidad más importante.
Por ejemplo, el asistente para el proceso “Sales Accounting Overview”.
En otra de las secciones tenemos acceso a vídeos donde se habla de los diferentes módulos y cambios más importantes.
La versión trial va siendo mejorada continuamente y ampliándose las transacciones disponibles, con lo que es una buena opción para iniciarnos.
Enlaces de interés.
Para terminar, os dejo un recopilatorio de algunos enlaces de interés relacionados.
En nuestro truco de hoy volvemos a temas más técnicos, en concreto, vamos a hablar del sistema de Clasificación.
La clasificación es un componente transversal de Sap que esta disponible en diferentes elementos y que nos permite definir nuestro propios valores de clasificación en elementos tan diferentes como el maestro de materiales, clientes o proveedores; elementos de la gestión documental; definición de estrategias de liberación en solicitudes de pedido o pedido; lotes, equipos, avisos, etc. La clasificación también se utiliza en los materiales configurables, de cuyas posibilidades hablaremos próximamente en el blog.
Algunas de las categorías de clase existentes en SAP
Quien no ha tenido la necesidad de añadir criterios adicionales de clasificación en un material o el maestro de clientes o proveedores. La utilización del sistema de clasificación es la opción estándar, sin necesidad de realizar ampliaciones de las pantallas estándar o reutilizar campos que están definidos para otros objetivos.
En la imagen siguiente podéis ver un ejemplo de utilización de la clasificación en el maestro de materiales (categoría de clase 001).
Podemos tener disponibles diferentes clases según la naturaleza de nuestros materiales y asignarlas a estos, informando los correspondientes valores de clasificación. Lo bueno de utilizar esta funcionalidad es que tendremos disponible la búsqueda de los elementos de forma estándar utilizando las ayudas de búsqueda por la clasificación, así como las transacciones CL30N o CL31.
Incluso tenemos la transacción CLMM que nos permite realizar modificaciones en masa de los valores de clasificación.
Otro lugar muy frecuente donde se utiliza la clasificación es en los lotes (categoría de clase 023), donde podemos guardar las propiedades concretas de un subconjunto de stock, de acuerdos a sus propiedades físicas, analíticas, etc.
Para utilizar el sistema de clasificación, habremos de crear en primer lugar las características (transacción CT04). Cada característica puede ser del tipo CHAR, CURR, Numero, Fecha u Hora. Los valores de estas características pueden ser listas de valores indicados en la característica (o en una tabla de verificación), un módulo de función, valores libres (por ejemplo para un numero o una fecha), intervalos, varios valores a la vez, etc.
Una vez definidas las características, crearemos la clase utilizando la transacción CL02, indicando en la categoría de clase el valor correspondiente al ámbito donde se va a utilizar, así como las características relevantes para esa clase.
En nuestro truco de hoy vamos a hablar de la forma de leer la información de clasificación en nuestros desarrollos Z o en las adaptaciones al estándar que realicemos.
Básicamente, disponemos de varios módulos de función que nos permiten obtener toda la información de clasificación de nuestros objetos.
CLAF_CLASSIFICATION_OF_OBJECTS
Es uno de los módulos de función clásicos para leer la clasificación sin necesidad de acceder a las diferentes tablas (AUSP, KSSK, KLAH, etc).
CALL FUNCTION ‘CLAF_CLASSIFICATION_OF_OBJECTS’
EXPORTING
classtype = ‘023’ “Categoria de clase
features = ‘X’ “Leer características
language = ‘S’ “Idioma
object = w_l_object “Objeto. Por ejemplo, el material (ceros a la izda)
objecttable = ‘MCH1’ “MARA,MARC,MCH1 o tabla relevante
t_class = t_lclass “Tabla con la clase leida
t_objectdata = t_objectdata “Tabla con los valores de clasificacion leidos
EXCEPTIONS
no_classification = 1
no_classtypes = 2
invalid_class_type = 3
OTHERS = 4.
IF sy-subrc = 0.
endif.
Por ejemplo, para realizar la lectura de la clasificación de un material (categoría de clase 001), utilizaremos los siguientes parámetros:
En la tabla T_OBJECTDATA obtendremos los valores de clasificación encontrados.
Este modulo de función tiene un pequeño inconveniente, que para los valores CHAR, se recupera el valor de la descripción del valor de la característica en el idioma indicado, y no el valor neutral o del codigo. Por eso es recomendable utilizar el siguiente módulo de función.
La ventaja es que todos los valores de clasificación se devuelven en una única tabla interna.
BAPI_OBJCL_GETCLASSES
Con esta BAPI leeremos todas las clasificaciones de un tipo asociadas al objeto, sin necesidad de indicar la clase a leer. Básicamente, indicaremos:
OBJECTKEY_IMP: la clave del objeto para el que vamos a leer la clasificacion (por ejemplo, para el material indicaremos 18 digitos, con el número del material lleno con 0 a las izquierda (000000000000000043); para un lote MMMMMMMMMMMMMMMMMMLLLLLLLLLL; etc).
OBJECTTABLE_IMP: tabla asociada al objeto. Por ejemplo, MARA para materiales, KNA1 o LFA1 para clientes o proveedores, MCH1 para lotes, EQUI para equipos, etc).
CLASSTYPE_IMP: la categoria de clase que estamos buscando.
READ_VALUATIONS: siempre con el valor X, sino no lee los valores de características en la clasificación, solo la asignación a la clase del objeto.
LANGUAGE: idioma para las descripciones de los valores
Podéis utilizar la transacción SE37 en modo test para comprobar el funcionamiento de los módulos de función:
Los valores de clasificación será devueltos en tres tablas, según el tipo de dato de cada una de las características:
ALLOCVALUESCHAR: características del tipo alfanúmerico (CHAR).
ALLOCVALUESCURR: características del tipo CURRENCY.
AALOCVALUESNUM: características del tipo NUM, DATE o TIME.
Relacionados con este módulo de función disponemos de otros, como el BAPI_OBJCL_CREATE o BAPI_OBJCL_CHANGE que nos permiten crear los valores de clasificación o modificarlos desde un desarrollo.
VB_BATCH_GET_DETAIL
Si estais trabajando con la clasificación en los lotes, recuperar la información de clasificación es muy sencillo utilizando el módulo de función VB_BATCH_GET_DETAIL. Aquí simplemente habrá que indicar el material, el número de lote y centro, marcando el flag GET_CLASSIFICATION en la llamada.
En la tabla internat CHAR_OF_BATCH tendremos los valores de clasificación encontrados:
En nuestro post de hoy vamos a hablar de como realizar el transporte este sistemas de las traducciones que podemos gestionar en los diferentes elementos de Sap (con un ejemplo concreto de traducción de un formulario Smarform).
Como todos sabéis, Sap es un sistema multilenguaje que nos permite trabajar con diferentes idiomas
Normalmente, los idiomas de logon están limitados según los países en los que utilicemos nuestro sistema Sap (por ejemplo, Español, Ingles, Alemán, Italiano, Francés), pudiéndose ampliar los idiomas disponibles con la instalación de los correspondientes paquetes de idioma.
Cuando tenemos disponibles varios idiomas, Sap nos permite traducir los diferentes elementos para que aparezcan en el idioma correspondiente cuando el usuario se conecta al sistema utilizando dicho idioma.
En la imagen, un ejemplo sencillo de traducción del campo “Lista de precios”. Al seleccionar la opción “Traducción” en las transacciones de parametrización, podemos seleccionar el idioma correspondiente e indicar el texto asociado al valor en el idioma deseado.
Esta parametrización queda registrada en la correspondiente orden de transporte, incluyendo los valores de traducción asociados al idioma correspondiente.
Sap nos facilito el trabajo al crear su sistema incluyendo en casi todos los objetos de parametrización una tabla paralela de textos (T189T en este caso), donde se pueden introducir las descripciones en los diferentes idiomas disponibles.
Cuando estamos trabajando con elementos de programación, la cosa se complica un poco más. En los programas Abap podemos traducir los textos de los elementos de selección, atributos del programa, textos de cabecera, etc, sin problema.
Si estamos trabajando con formularios, sabéis que podemos tener diferentes idiomas de comunicación con nuestros clientes o proveedores, y podemos gestionar los mensajes para comunicarlos con ellos en sus idiomas (o de forma general en ingles).
En nuestro truco de hoy nos vamos a centrar en como traducir un formulario (por ejemplo, un smartform) y luego como utilizar la herramienta de transporte de traducciones entre sistemas.
Partimos del supuesto que tenemos un formulario con la tecnología smartform ya creado para los pedidos de compra y nos piden traducirlo a un nuevo idioma objetivo.
Para ello (dada que la opción de Traducción no esta disponible directamente en la transacción Smartforms), accederemos a la transacción SE63 y seleccionaremos la opción de menú Traducción –> Objetos Abap –> Otros textos explicativos.
A continuación, seleccionaremos la opción FS Formularios y estilos –> SSF SAP Smart Form (tal y como vemos en la imagen superior). Finalmente indicaremos el nombre del formulario y el idioma fuente y destino para la traducción (siempre partimos de un idioma base sobre el que realizaremos la traducción al idioma destino).
Al pulsar tratar iremos realizando la traducción de los diferentes textos, pudiendo ver en la parte superior de la imagen el texto en el idioma origen y en la parte inferior los textos traducidos, asociados a cada etiqueta. Nos fijaremos en las etiquetas de cada texto para ver su descripción en Ingles(en este ejemplo), e introducir la correspondiente descripción en Español en la parte inferior, con el correspondiente formato asociado a cada uno de los textos.
Conforme vayamos traduciendo los textos, al activar, estos aparecerán en el formulario cuando el idioma de comunicación con el proveedor (en este caso es un pedido de compra), sea el idioma traducido.
Nota: si estáis trabajando con formularios ADOBE, la opción de traducción si esta disponible en la transacción SFP (donde se programan los formularios), aunque realmente nos llevará igualmente a la transacción SE63 (en la opción FS Formularios y estilos –> PDFB Formularios basados en PDF).
Una vez terminada la revisión de todos los textos, tendremos que realizar el transporte de las traducciones. Como habréis observado, el sistema no nos ha preguntado en ningún momento la orden de transporte en la que incluir.
Para poder realizar el transporte, utilizaremos la transacción SLXT (que ejecuta el report RS_LXE_RECORD_TORDER).
Indicaremos los siguientes valores:
(1) Idioma objetivo (destino) que queremos transportar.
(2) Descripción que se asociará a la orden de transprote.
(3) Tipo de orden: seleccionar la opción Orden de workbench.
(4) Fecha de tratamiento: para hacer la selección, fecha en la que hayamos hecho la traducción del formulario.
(5) Tipo de objeto: SSF en el caso de formularios Smartform.
Se nos generará la correspondiente orden de transporte donde tendremos incluida toda la traducción de los textos del formulario.
Una vez pasada la orden al sistema destino, podremos utilizar sin problema el formulario en el idioma correspondiente.
La herramienta SLXT esta disponible para transportar traducciones de otros elementos, no solo de los formularios (ver bibliografía, donde se muestra un ejemplo de traducción de la transacción IW32).
En nuestro truco de hoy inauguramos una sección donde propondremos típicos ejemplos prácticos de necesidad funcional y como solucionarlos, incluyendo en muchos casos elementos de programación Abap.
Empezaremos con un ejemplo clásico donde necesitamos que un report Z envie por email los resultados calculados y que en modo interactivo se muestran en un ALV. Por ejemplo, en una ejecución del programa en fondo queremos que se envíen los resultados a uno o varios usuarios. O incluso el mismo usuario que esta viendo los resultados de forma interactiva quiere enviar la información a otro usuario de la empresa o un contacto externo (cliente o proveedor).
Para nuestro ejemplo, partimos de un desarrollo Z que nos permite listar información de pedidos de compra.
En el informe añadiremos en los criterios de selección del programa añadiremos un campo para poder introducir los destinatarios de email donde queremos enviar los resultados del ALV ( Select-options: so_email for adr6-smtp_addr. )
Y un botón para que el usuario, cuando lo desee, pueda lanzar el envío del correo electrónico que contendrá como anexo una excel con la información.
Ahora, la parte más compleja. La programación necesaria para convertir la tabla interna que estamos utilizando en el ALV en una hoja excel, construir el correo electrónico y enviarlo a los destinatarios.
Básicamente, utilizamos los siguientes elementos de programación:
Clase cl_salv_bs_tt_util: nos permite convertir una tabla interna a formato excel.
Clase cl_bcs: para gestionar el envío del correo.
Clase cl_document_bcs: para crear el correo, indicar asunto y texto, anexar excel, etc.
En mi programa, he creado un FORM que se ejecuta cuando el usuario pulsa el botón de enviar correo, que se llama lanza_envio_mail.
Desde allí se llama a send_email donde se hace todas las operaciones técnicas de convertir la tabla interna a un xls (form f_build_email_data ) y la construcción del correo electrónico.
FORM lanza_envio_email. * miro si la tabla de emails esta vacia, intento meter el email del user DESCRIBE TABLE so_email LINES lv_num_emails. IF lv_num_emails = 0. SELECT SINGLE adr6~smtp_addr INTO so_email-low FROM usr21 INNER JOIN adr6 ON usr21~addrnumber = adr6~addrnumber AND usr21~persnumber = adr6~persnumber WHERE bname = sy-uname. IF sy-subrc EQ 0. lv_num_emails = lv_num_emails + 1. so_email-sign = ‘I’. so_email-option = ‘EQ’. APPEND so_email. ENDIF. ENDIF. IF lv_num_emails > 0. * Construimos el catalogo para poder hacer la excel. CALL FUNCTION ‘LVC_FIELDCATALOG_MERGE’ EXPORTING i_structure_name = ‘ZME2L’ CHANGING ct_fieldcat = gt_fieldcat EXCEPTIONS inconsistent_interface = 1 program_error = 2 OTHERS = 3. PERFORM modify_fieldcat. * Constuimos el correo desde la tabla interna. PERFORM send_email. ENDIF. ENDFORM.
*&———————————————————————* *& Form SEND_EMAIL *&———————————————————————* * text *———————————————————————-* * –> p1 text * <– p2 text *———————————————————————-* FORM send_email . DATA: lt_binary_content TYPE solix_tab, lv_size TYPE so_obj_len, r_mail TYPE ace_generic_range_t, st_mail TYPE ace_generic_range, lv_count TYPE char2, lv_var TYPE char8. FIELD-SYMBOLS: <fs_mail> TYPE any. REFRESH: lt_binary_content. CLEAR: st_mail, lv_count, lv_var.
* Construye el objeto binario de la excel a partir de la tabla interna PERFORM f_build_email_data CHANGING lt_binary_content lv_size. DATA: v_rundate LIKE sy-datum, v_runtime LIKE sy-uzeit, timestamp(20), lcl_send_request TYPE REF TO cl_bcs, lcl_document TYPE REF TO cl_document_bcs, lv_subject TYPE so_obj_des, lt_main_text TYPE soli_tab, lv_text TYPE soli, lv_filename TYPE sood-objdes, lv_mailto TYPE adr6-smtp_addr, lcl_recipient TYPE REF TO cl_cam_address_bcs, lv_sent_to_all TYPE os_boolean.
*–Run Date and Run Time v_rundate = sy-datum. v_runtime = sy-uzeit. * CONCATENATE v_rundate v_runtime INTO timestamp. WRITE sy-datum TO timestamp MM/DD/YYYY. TRY. * ——– create persistent send request ———————— lcl_send_request = cl_bcs=>create_persistent( ).
* ——– create and set document with attachment —————
* ASUNTO CORREO CONCATENATE ‘Informe de pedidos’ ‘ Fecha:’ timestamp sy-cprog sy-sysid INTO lv_subject SEPARATED BY space.
* Texto de correo (cuerpo del mensaje) CONCATENATE ‘En el Excel anexo se detallan los pedidos pendientes’ ‘en el sistema.’ INTO lv_text SEPARATED BY space. APPEND lv_text TO lt_main_text. APPEND text-001 TO lt_main_text. APPEND text-003 TO lt_main_text. lcl_document = cl_document_bcs=>create_document( i_type = ‘RAW’ i_text = lt_main_text i_subject = lv_subject ). “#EC NOTEXT
* Añadimos la excel al mensaje, poniendo nombre al fichero CLEAR: lv_subject. CONCATENATE ‘Pedidos’_’ v_rundate v_runtime ‘_’ sy-sysid INTO lv_filename. CALL METHOD lcl_document->add_attachment EXPORTING i_attachment_type = ‘xls’ i_attachment_subject = lv_filename i_attachment_size = lv_size “im_size i_att_content_hex = lt_binary_content. “im_tab ).
* add document object to send request lcl_send_request->set_document( lcl_document ).
IF lv_sent_to_all IS INITIAL. MESSAGE i500(sbcoms) WITH lv_mailto. ELSE. MESSAGE s022(so). ENDIF.
* ———— exception handling ———————————- * replace this rudimentary exception handling with your own one !!! * CATCH cx_bcs INTO lcl_bcs_exception. * MESSAGE i865(so) WITH lcl_bcs_exception->error_type. ENDTRY. ENDFORM.
FORM f_build_email_data CHANGING p_lt_binary_content TYPE STANDARD TABLE p_size TYPE so_obj_len. DATA: e_xstring TYPE xstring. DATA: mt_fcat TYPE lvc_t_fcat, ms_fcat TYPE lvc_s_fcat, st_fieldcat TYPE slis_fieldcat_alv. DATA: mt_data TYPE REF TO data. DATA: m_flavour TYPE string. DATA: m_version TYPE string. DATA: mo_result_data TYPE REF TO cl_salv_ex_result_data_table. DATA: mo_columns TYPE REF TO cl_salv_columns_table. DATA: mo_aggreg TYPE REF TO cl_salv_aggregations. DATA: mo_salv_table TYPE REF TO cl_salv_table. DATA: m_file_type TYPE salv_bs_constant. DATA: out_length TYPE i. FIELD-SYMBOLS <tab> TYPE ANY TABLE.
*-It_final here is the final itab same parameter you pass in * your alv grid GET REFERENCE OF gt_eban INTO mt_data.
*-Move your field catalog to mt_fcat make sure to populate *-ms_fcat-seltext, because it can be that in your field cat the headings
*-are in seltext_l or seltext_m or seltext_s LOOP AT gt_fieldcat INTO ms_fcat. “st_fieldcat. * MOVE-CORRESPONDING st_fieldcat TO ms_fcat. * MOVE: st_fieldcat-seltext_l TO ms_fcat-seltext. APPEND ms_fcat TO mt_fcat. CLEAR: ms_fcat, st_fieldcat. ENDLOOP.
IF cl_salv_bs_a_xml_base=>get_version( ) EQ if_salv_bs_xml=>version_25 OR cl_salv_bs_a_xml_base=>get_version( ) EQ if_salv_bs_xml=>version_26.
CASE cl_salv_bs_a_xml_base=>get_version( ). WHEN if_salv_bs_xml=>version_25. m_version = if_salv_bs_xml=>version_25. WHEN if_salv_bs_xml=>version_26. m_version = if_salv_bs_xml=>version_26. ENDCASE.
El resultado el correo enviado podría ser algo parecido a esto, donde podemos personalizar en el código la información del asunto, texto del correo, nombre del fichero anexado, etc.
Con el fichero excel anexado con la información del ALV, todo construido con un desarrollo más o menos sencillo.
