Truco 92. Añadir documentos en el Content Server (Archivelink) a partir de mensajes.


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.

Mensajes1

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.

Mensajes2

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.

Mensajes3

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).

Mensajes4

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.

Mensajes5

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.

Mensajes6

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.

Mensajes7

Igualmente, desde la transacción OAAD con 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.

Mensajes8

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.

Mensajes9

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.

Anuncios
Publicado en Formacion, Sap Basis | Etiquetado , | Deja un comentario

Truco 91. Análisis de modificaciones del precio medio variable de un material.


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.

MBEW1

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.

MBEW2

  • 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.

MBEW3

  • 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.

MBEW4

  • 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).

MBEW6

  • Incluye documentación sobre la forma de calculo y los escenarios incluidos en la herramienta.

MBEW5

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.

Publicado en Formacion, SAP MM | Etiquetado , , , , , , , , , , | 2 comentarios

Truco 90. Campos de cliente en la determinación de precios.


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.

Truco90_2

  • 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).

Truco90_3

  • 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.

Truco90_4

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. 

Truco90_5

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 :

Truco90_6

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).

Truco90_8

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.

Truco90_7

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.

Truco90_10

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.

Truco90_9

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: Truco90_11

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.

Truco90_12

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).

Truco90_13

¡¡¡¡Feliz verano a todos!!!!

Verano2017

 

 

 

Publicado en Formacion, SAP MM, Sap SD | Etiquetado , , , , | 1 Comentario

Truco 89. Excluir un almacén de la verificación de disponibilidad (ATP).


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.

OVZ9

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).

Truco89_2

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”.

Truco89_3

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.

Truco89_4

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.

Truco89_7

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.

Truco89_5

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.

Truco89_6

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:

https://wiki.scn.sap.com/wiki/display/SCM/Available+userexits+in+ATP

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.

Publicado en Formacion, Sap SD | Etiquetado , , , | Deja un comentario

Truco 88. Utilidad para carga de condiciones de precio.


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.

copiacond8

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)

condiciones2

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.

Condiciones1.png

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).

condiciones5

  • 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.
  • Link  a un ejemplo de fichero de carga: plantilla-creacion-pr00.

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).

condiciones3

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.

condiciones4

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.

Otros ejemplos de código:

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:

condiciones6

Habría que mapear el fichero de carga con la correspondiente estructura del documento:

condiciones7

Idem si utilizamos una grabación de batch input de la transacción VK11 o MEk1, por ejemplo:

condiciones9

O el metodo direct input que también esta disponible para cargas iniciales de condiciones:

condiciones8

Condiciones10.png

Que tengáis buena lectura.

Publicado en Formacion, SAP MM, Sap SD | Etiquetado , , , | 5 comentarios

Truco 87. Utilidades para actualizar estatus en documentos de ventas.


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).

status-1

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.

status-2

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.

status-3

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).

status-4

status-6

En la imagen siguiente ver los status de un pedido (399), la entrega siguiente (80000312) y la correspondiente factura de ventas (90000294).

status-8

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.

Status-7.png

  • 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.

status-5

  • 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).

Hay muchas más utilidades y reports para tratar otras situaciones. Os dejo la nota de sap KBA con número 2006809-how-to-fix-delivery-related-inconsistencies donde se informa de muchos de  ellos.

Un saludo a todos y buena lectura.

 

 

Publicado en Formacion, Sap SD | Etiquetado , , , , , , , | 2 comentarios

Truco 86. Proteger agrupaciones libres de clientes o proveedores por autorizaciones.


¡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:

autor_1

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.

autor_2

Finalmente, a nivel de ventas, lo indicaremos en la pestaña Ventas, en el campo Grupo Autoriz.

autor_3

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).

autor_4

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

autor_5

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.

Espero que os sea de utilidad.

Publicado en Formacion, Sap FI, SAP MM, Sap SD | Etiquetado , , , , , | Deja un comentario

Truco 85. Variantes de transacción en el registro de facturas de compras (MIRO).


Hace tiempo hablamos de como personalizar las transacciones estándar utilizando las variantes de transacción, a través de la transacción SHD0 (ver post del blog en este link). Esta funcionalidad nos permitía establecer valores iniciales en los campos, ocultar otros, hacer obligatorios aquellos que nos pudiera interesar, etc.

Nuestro truco de hoy va por el mismo camino, pero vamos a personalizar la transacción de Registro de facturas de Compras (MIRO). En concreto, cuando hacemos un registro de facturas contra pedido, tenemos la posibilidad de seleccionar las posiciones de pedido que queremos “matar” con la factura, pudiendo seleccionar una variante de visualización acorde con el tipo de operativa que estemos realizando.

miro1

Estas variantes de visualización son configurables y nos permiten, por ejemplo, determinar el orden de los campos en la pantalla, ocultar campos que nunca vayamos a utilizar, hacer obligatorios algunos de ellos o solo visibles (sin posibilidad de modificación), etc. Puede ser otra manera de facilitar el trabajo al usuario y mejorar su productividad.

Para realizar la configuración accederemos a la ruta de customizing Gestión de Materiales –> Verificación de facturas de logística –> Factura recibida –> Actualizar variantes p.lista posiciones (o por la transacción OLMRLIST).

miro2

Indicaremos los siguientes valores:

  • Transacción: MIRO
  • Variante de imagen: el nombre de nuestra variante. Será el que luego seleccionemos en la transacción MIRO para trabajar con nuestra propia configuración de campos.
  • Programa: SAPLMR1M
  • Dynpro: 6310

A continuación pulsaremos el botón Crear y procederemos a realizar la grabación de una factura de ejemplo (es necesario tener preparado un pedido para hacer la grabación de la variante).

miro3

Al terminar la grabación, nos aparecerá una pantalla como la que vemos en la imagen. En ella aparece toda la lista de campos del resumen de posiciones. Lo que podemos configurar para cada uno de los campos (también se pueden configurar botones o iconos), será lo siguiente:

  • Con contenido: se en el campo hemos introducido algún valor, al marcar esta casilla se propondrá el valor correspondiente (si la desmarcamos no se propondrá este valor).
  • Solo salida: nos permite hacer un campo solo visible, sin posibilidad de modificación.
  • Invisible: si se marca, nos sirve para ocultar un campo.
  • Obligatorio: nos permite hacer que un campo sea requerido (aunque en el estándar no lo sea).

Modificaremos los diferentes campos de la forma deseada y realizaremos la grabación de la variante. Una vez guardada, podremos probar su funcionamiento con el correspondiente botón de Test (tecla F8), igualmente en la transacción OLMRLIST.

miro4

El comportamiento de los campos ha sido modificado según nuestras necesidades. ¿Y que ocurre si queremos cambiar el orden de los campos en la pantalla?. Ningún problema, también se puede realizar. Para ello, una vez creada la variante, accederemos a la transacción OLMRLIST e indicaremos el nombre de la variante. Seleccionaremos el botón “Modificar con procesamiento”.

miro5

Modificaremos el orden de los campos seleccionandolos y arrastrandolos hasta la posicion deseada (Drag and drop). Así para todos los campos, hasta terminar la configuración. Al pulsar Intro, nos aparecerá la pantalla para confirmar entradas y abandonar la configuración (pulsando el botón “Finalizar y grabar”).

miro6

Nota: las variantes se guardan en una orden de transporte de Workbench, preparadas para ser transportadas al sistema de calidad o productivo.

La variante estará lista para ser utilizada en la transacción MIRO. Al entrar en la transacción, seleccionaremos la nueva variante de visualización.

miro7

En mi ejemplo, he creado una variante donde aparecen al principio los siguientes campos:

  • Importe
  • Cantidad
  • Indicador de Iva.
  • Pedido.
  • Posición.
  • Material.
  • Texto del material.
  • Tipo imputación
  • Cuenta de mayor
  • Centro de coste
  • Orden
  • Pep
  • Activo
  • etc.

Podemos tener sin problema diferentes variantes según el tipo de operativa de compras que estemos realizando para facilitar el trabajo al usuario en la grabación de las facturas y en la comprobación de la información en el momento del registro (información de impuestos, datos de imputación, materiales, textos, si las posiciones son de devolución, información de cantidades e importes del pedido, detalle de imputación, etc).

¡¡Feliz 15 de Agosto!!

 

Publicado en Formacion, Sap Basis, SAP MM | Etiquetado , , , , | 1 Comentario

Truco 84. Transporte de variantes de Layout en Informes ALV.


Como todos vosotros conocéis, los informes que se muestran en formato ALV dentro de Sap son una herramienta muy útil para consultar la información y personalizar las listas de resultados utilizando las variantes de visualización o disposiciones del ALV (también conocidos como Layouts).

layout1

Con estas variantes podemos personalizar los campos que se visualizan (del catálogo disponible en cada informe), definir valores de clasificación, ordenación, filtros, etc. Toda esta configuración queda guardada dentro del Layout y se recupera cuando se selecciona en la lista de resultados (o al ejecutar el informe en algunas transacciones).

En ocasiones nos puede interesar transportar los layouts de un mandante a otro, o de un sistema a otro. No hay ningún problema, Sap nos habilita la opción para poder realizar este transporte, que no se realiza de forma automática (pues no se trata en si de un objeto de customizing).

Para hacer el transporte, seleccionaremos la opción Opciones –> Disposición –> Gestionar (puede haber varias formas de acceder a esta opción según la transacción en la que nos encontremos).

layout2.jpg

A continuación se nos mostrará una lista con los Layouts definidos en la transacción en la que nos encontremos. Con la opción de menú Layout –> Transportar podremos incluir en una orden de transporte los Layouts que deseemos transportar.

layout3

El sistema nos pedirá una orden de transporte de Customizing. Al ser importada la orden en el destino, tendremos disponibles todos los Layouts que hayamos configurado, por ejemplo, en nuestro de desarrollo para probar un desarrollo Z o una transacción estándar.

Feliz lectura!!!.

 

Publicado en Formacion, Sap Basis | Etiquetado , , , | Deja un comentario

Truco 83. Configuración tabulacion en una pantalla de SAP.


En nuestros propios desarrollos Z, podemos configurar que cuando el usuario pulsa la tecla Tabulación (TAB), el cursor pase de un campo a otro en un orden establecido. Esto, que parece una tontería, puede ahorrar horas de trabajo a un usuario que trabaja siempre con la misma transacción y se limita a completar un número limitado de campos en una pantalla con mucha información que no siempre introduce.

¿Y que ocurre cuando estamos hablando de las transacciones estándar?. El programa que utilizamos para conectarnos a nuestro Sap (SAPGUI), nos permite, en sus opciones de configuración, personalizar, por cada equipo, el orden de fabulación en las pantallas según las necesidades del usuario.

tab1

Para ver la configuración de la tabulación y realizar la personalización, podemos acceder al menú contextual pulsando la tecla Control (CTRL) y el botón derecho del ratón en cualquier campo de la pantalla. Las opciones marcadas en rojo en la imagen aparecen al pulsar la tecla Control (no son visibles si utilizamos el menú contextual normal).

Para ver la configuración de esta opción, vamos a realizar un sencillo ejemplo con la transacción de registro de facturas de acreedor en compras (transacción FB60).

tab2

Deseamos que al entrar el usuario en la transacción, el cursor se posicione en un campo. Para ello, nos posicionamos en el campo Acreedor y pulsamos la tecla CTRL y el botón derecho del ratón. Seleccionamos la opción “Secuencia de tabulación local: Punto de acceso”.

A continuación iremos realizando la secuencia de tabulación por los diferentes campos de la pantalla de la siguiente manera:

  • Nos posicionaremos en el campo origen y pulsaremos la tecla CTRL y el botón derecho del ratón, seleccionando la opción “Secuencia de tabulación local: Elemento de Salida”. Con esto determinamos el origen en la tabulación.
  • Nos posicionaremos en el campo destino y pulsaremos la tecla CTRL y el botón derecho del ratón, seleccionando la opción “Secuencia de tabulación local: Elemento de Entrada”. Con esto determinamos el destino en la tabulación.
  • Repetiremos la secuencia para todo el conjunto de campos que deseemos.

Tras terminar la configuración, podemos visualizar el resultado de la configuración seleccionado la opción “Configurar secuencia de tabulación local”.

tab3

El icono correspondiente en la barra de estado (ver imagen), nos indica igualmente que se ha configurado la tabla de tabulación para la pantalla en la que nos encontramos.

Cuando el usuario para el que hemos realizado la configuración acceda a su equipo y entre en la transacción FB60, el curso se le posicionará en el Proveedor (Acreedor). Ira introduciendo la información y al pulsar la tecla TAB, ira pasando por los diferentes campos de la pantalla en el orden configurado. Sin duda es una funcionalidad que nos puede permitir mejorar la productividad del usuario y ahorrarle mucho trabajo al usuario (sobre todos aquellos que trabajan con grandes volúmenes de información, introduciendo datos en el sistema).

Espero que os sea de utilidad. ¡Feliz verano a todos!.

 

Publicado en Formacion, Sap Basis | Etiquetado , , | 7 comentarios