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 , , , | 4 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 , , | 6 comentarios

Truco 82. Campos adicionales en el Pool de Facturacion en Ventas (VF04).


Hace tiempo ya hablamos de la forma de incluir campos adicionales en los informes comerciales (ver post del blog https://saptricks.wordpress.com/2011/08/29/truco-17-anadir-nuevos-campos-en-informes-comerciales/). Por ejemplo, utilizando esta técnica podíamos ampliar la información visualizada en la transacción VA05, Listado de pedidos.

En el EHP 7, Sap ha realizado una mejora de los informes comerciales con la business function “LOG_SD_REPORT_OPT – Sales and Distribution, Optimization of Lists”.  Al activar la BF, se producen muchos cambios en los informes comerciales (hablaremos de ellos en un próximo post), entre ellos cambios en la funcionalidad de los informes, modificación de las exits o ampliaciones que podemos utilizar, etc. Ya lo analizaremos en detalle.

En nuestro ejemplo de hoy, vamos a ver la forma de ampliar los campos que se muestran al usuario cuando se ejecuta la transacción VF04, Pool de facturación, que es la herramienta más utilizada para los procesos de facturación en Ventas (SD).

En primer lugar, tendremos que realizar la ampliación de la estructura VKDFIF, que es la utilizada por Sap para mostrarnos los resultados en el Pool de facturación.

vf04_1

Para realizar esta ampliación, utilizaremos la transacción SE11. La ampliacción se realizara añadiendo una estructura APPEND en la estructura VKDFIZ, tal y como vemos en la imagen anterior. Esta estructura es la que Sap deja disponible en la estructura VKDFIF para poder añadir nuestros propios campos.

A continuación, realizaremos la programación para llenar de valores los nuevos campos ampliados. Para ello, utilizaremos un proyecto de ampliación (transacción CMOD), con el componente V60P0001, exit EXIT_SAPLV60P_008 (include ZXV6PU08).

Crearemos un nuevo proyecto de ampliación, asignado el componente indicado. Crearemos el include ZXV6PU08, lugar donde incluiremos el código abap necesario.

vf04_2

La tabla interna C_VKDFIF tiene los campos que se muestran en el pool de facturación, incluyendo los nuevos campos añadidos. Recorreremos la tabla con un loop e incluiremos la lógica de programación necesaria para llenar de contenido los nuevos campos.

En mi ejemplo, he incluido el número de pedido del cliente.

Posteriormente, activaremos la ampliación y al ejecutar la transacción VF04, ya estarán disponibles los nuevos campos añadidos.

vf04_3

Normalmente se añade información como el destinatario de mercancía, su nombre, campos de referencia, etc.

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

Truco 81. Debug en procesos de fondo.


Hace tiempo hablamos de la forma de realizar debug en las transacciones o reports de Sap, incluso cuando estábamos en ventanas modales en las que no está disponible el cuadro de comando (ver entrada https://saptricks.wordpress.com/2013/04/28/truco-53-debug-en-ventanas-popup/)

En ocasiones, el debug necesitamos realizarlo en procesos de fondo (por ejemplo, un job planificado en el sistema) o en las actualizaciones que se lanza de forma asíncrona cuando grabamos los datos en un proceso (por ejemplo, al facturar pedidos de ventas o entregas en SD).

Para el caso de los procesos de actualización, bastaría con activar la opción correspondiente en los parámetros de usuario cuando estamos en la herramienta de debug. Esto se realiza desde el punto de menú Opciones –> Visualizar/Modificar parametrizaciones que tenemos disponible desde la ventana de debug.

debug1

Cuando lo que queremos hacer es realizar un debug sobre un proceso que se ejecuta en fondo, tenemos disponibles varios métodos para realizar el proceso. En detalle, cada una de las opciones serían:

Jobs que están en ejecución

Accederemos a la transacción SM50, donde podemos consultar los procesos que se encuentran en ejecución en nuestro sistema. Nos posicionaremos encima del proceso a debugear y seleccionaremos la opción de menu Programa/Modo –> Programa –> Debugging.

debug2

A continuación se nos pedirá confirmación de la acción y entraremos a la herramienta de debug de la forma habitual.

debug3

Jobs finalizados.

Para realizar la misma operación, pero en este caso sobre jobs que ya hayan concluido, accederemos a la transacción SM37 y seleccionaremos el job que queremos analizar.

debug4

Escribiremos el comando JDBG en el campo de transacción, tal y como vemos en la imagen siguiente:

debug5

El programa del job seleccionado se ejecutará en modo debug, con un comportamiento de proceso en fondo (con la variable de sistema SY-BATCH = ‘X’).

debug6.jpg

Forzar debug en jobs de fondo.

En ocasiones, los jobs que se estan ejecutando son rápidos y no nos da tiempo a acceder a la SM50 para lanzar el debug sobre ellos. Para solucionar este problema, utilizaremos un pequeño truco.

Cuando realicemos la definición de los jobs con la transacción SM36, añadiremos siempre un paso previo, que incluirá la ejecución del programa BTCLOOP.

debug7

El programa BTCLOOP genera un bucle infinito, que hace que tengamos el programa disponible en la SM50 para poder tomar el control de el con el debug (como hemos indicado anteriormente).

debug8.jpg

Bastará con cambiar el valor de la variable I a 1, y el programa continuará su ejecución, realizando el debug hasta donde nos interese (habiendo puesto, por ejemplo, puntos de breakpoint en el programa que nos interesa analizar).

Referencias: http://scn.sap.com/community/spanish/blog

Gracias a  DAIRO LEONARDO LOZANO RODRIGUEZ y su entrada en los blogs del SCN de Sap: http://scn.sap.com/community/spanish/blog/2015/10/16/como-hacer-debug-a-procesos-en-fondo-jobs

 

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

Truco 80.Varias cuentas bancarias en el maestro de proveedores.


En ocasiones, nuestros proveedores trabajan con varias cuentas bancarias para la gestión de los pagos que se les han de realizar (por ejemplo, mediante transferencia bancaria a su número de cuenta).

Sap nos permite registrar en los datos maestros del proveedor (transacciones XK01/FK01/MK01) la información, que se encuentra en datos generales, en la pestaña Pagos (es información a nivel de mandante, compartida por todas las sociedades que utilicen un proveedor). Esto significa que no tenemos una forma automática de distinguir, por ejemplo, las cuentas bancarias que se utilicen en una sociedad u otra, o para unas operaciones determinadas.

Bancos0

Para solucionar este problema, a cada cuenta se le puede informar una etiqueta, llamada tipo de banco (campo TpBc), que podrá ser utilizada posteriormente de varias maneras para la selección del banco de pago en las operaciones que realicemos con nuestro proveedor.

Esta etiqueta es un texto libre y nos puede valer, por ejemplo:

  • Informar el número de la sociedad donde se vaya a utilizar.
  • Establecer una prioridad de cuentas utilizando el valor.
  • Indicar una codificación que indique la utilización de la cuenta.

Selección manual de cuenta en las operaciones.

Cuando posteriormente estemos realizando contabilizaciones contra la cuenta del proveedor (por ejemplo, registro de una factura financiera en la transacción FB60), en la pestaña Pago podremos seleccionar el banco del proveedor que queremos utilizar para el posterior pago. La selección se realiza con los valores de tipo de banco definidas en el maestro del proveedor (incluye un matchcode de búsqueda).

bancos1

Esa misma opción está disponible si el registro lo realizamos, por ejemplo, en la transacción MIRO (registro de facturas de compras de logística).

bancos2

Selección automática de cuenta en las operaciones.

Cuando estemos realizando, por ejemplo, propuestas de pago utilizando la transacción F110, y no se haya indicado la cuenta bancaria por la que realizar el pago al proveedor en las facturas o partidas abiertas del proveedor, el sistema se comportará de la siguiente manera:

  • Solo hay una cuenta bancaria en el proveedor: el sistema asignará dicha cuenta para la realización del pago.
  • Hay varias cuentas bancarias, pero no hemos mantenido el tipo de banco en las cuentas del proveedor: el sistema asigna la primera cuenta que encuentra en la ficha del proveedor.
  • Hay varias cuentas bancarias, y hemos mantenido el tipo de banco en las cuentas del proveedor: el sistema ordena las diferentes cuentas por el tipo de banco (de forma ascendente), y asigna la primera cuenta de la lista.

Esta sería la situación en la que no se ha informado de un tipo de banco en las facturas.

En el caso de que si se hubiera informado, el sistema utilizaría dicha cuenta al realizar las propuestas de pago.

Automatización de la asignación de cuenta bancaria.

Puede darse el caso que el comportamiento del sistema no nos valga, pues:

  • No queremos tener que asignar manualmente el banco en cada una de las facturas que registramos.
  • Hemos indicado el tipo de banco en las cuentas, pero la asignación estándar por prioridad (orden) no nos vale para nuestra operativa.

En ese caso, podremos configurar la lógica de funcionamiento del sistema utilizando los siguientes elementos de SAP:

  • Asignación en el momento de crear las facturas (FB60/MIRO): podremos automatizarla utilizando una sustitución en finanzas (se configuran con la transacción OBBH)
  • Asignación en el momento de crear las propuestas de pago (F110): podremos utilizar la BTE 1810, que se configura con la transacción FIBF.

bancos3

En los siguientes links tenéis información adicional sobre la forma de configurar estos elementos:

Referencias: http://www.learnsaptips.com/2016/05/the-use-of-vendor-partner-bank-type-in.html

Feliz verano a todos, y gracias por vuestras visitas.

bancos5

bancos4

Ya hemos superado los dos millones durante los últimos meses.

 

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

Truco 79. Aprobación de modificaciones en campos sensibles del maestro de proveedores/clientes.


Hace ya algún tiempo hablamos de la posibilidad de proteger determinados campos en el maestro de proveedores o clientes, de forma que solo los usuarios con las autorizaciones oportunas (objeto de autorización F_KNA1_AEN  para clientes o F_LFA1_AEN para proveedores) podrían modificar una lista de campos que nosotros previamente habríamos definido en el customizing como campos sensibles.

Tenéis todos los detalles en este entrada del blog:

https://saptricks.wordpress.com/2013/03/06/truco-47-proteccion-de-modificaciones-de-campos-en-maestro-de-clientes-y-proveedores/

Puede ocurrir un caso parecido, en el que nosotros queramos permitir modificaciones en el maestro (tanto de clientes o proveedores) en campos sensibles, pero que sea requerido que las modificaciones de dichos campos sean validadas por un segundo usuario. Existe una parametrización en el estándar que nos permite indicar que campos, cuando sean modificados, serán sensibles para aprobación. En ese caso, la emisión de pagos se bloqueará en el sistema para el interlocutor, hasta que se realice la validación de los cambios por parte del responsable.

A continuación vamos a ver la configuración de esta funcionalidad y como afecta a la forma de trabajar en el sistema.

Por un lado, realizaremos la parametrización de los campos sensibles a las modificaciones:

  • Clientes: ruta de customizing Gestión financiera –> Contabilidad de deudores y acreedores –> Cuentas de deudor –> Datos maestros –> Preparar creación de datos maestros de deudores –> Def. campos sensibles p.ppiio.verif.p/2 o mas pers.   o transacción S_ALR_87003378.
  • Proveedores: ruta de customizing  Gestión financiera –> Contabilidad de deudores y acreedores –> Cuentas de acreedor –> Datos maestros –> Preparar creación de datos maestros de acreedores –> Def. campos sensibles p.ppiio.verif.p/2 o mas pers.  o transacción S_ALR_87003179

En nuestro ejemplo, hemos configurado tres campos sensibles para el maestro de proveedores.

FK08_1

En principio, a nivel de parametrización ya no habría que configurar nada más.

Cuando entremos a modificar el maestro de proveedores (o clientes), con cualquiera de las transacciones disponibles, como son la MK02, FK02 o XK02  (VD02, FD02 o XD02 para clientes), el sistema nos permite realizar la modificación de los campos. Pero al grabar, aparece el siguiente mensaje:

FK08_2

El mensaje nos indica que se han modificado datos sensibles y que otro usuario autorizado tendrá que confirmar los cambios con la transacción FK08 (FD08 para clientes). Si miramos en las tablas del maestro de proveedores, podemos ver que se guarda la información del status de confirmación.

FK08_3

El bloqueo determina que no se puedan realizar propuesta de pagos al proveedor utilizando la transacción F110 hasta que no se realice la confirmación. La operativa terminará cuando otro usuario diferente (el mismo usuario no podrá nunca realizar la confirmación), entre a la transacción FK08 y verifique que los cambios son correctos.

FK08_4

Al realizar la confirmación se podrán consultar cuales fueron los cambios en los campos sensibles antes de proceder a la confirmación o al rechazo de los cambios. Si el usuario Confirma los cambios, se eliminará el bloqueo de pago. Si el usuario rechaza los cambios, el interlocutor continuará bloqueado y, lo que es importante, no se echarán para atrás las modificaciones de forma automática.

FK08_5

En ese caso, cuando volvamos a entrar a modificar o a consultar el proveedor, nos aparecerá el mensaje de que los cambios siguen sin confirmar. En esta situación, alguien tendría que verificar las modificaciones y echarlas para atras en el caso de que fuera necesario, volviendo a confirmar que todo queda correctamente en la FK08.

FK08_6

Es una forma estándar y sencilla de controlar que las modificaciones en campos sensibles de los maestros de clientes o proveedores son visados por un responsable que verificará la corrección de datos maestros importantes (Datos de impuestos, cuentas, condiciones de pago, información para tesorería, direcciones, etc).

También existe la posibilidad de realizar confirmaciones (o rechazo) de los cambios de forma masiva, utilizando la transacción FK09 (FD09 para clientes).

FK08_7

De esta forma, el usuario responsable puede analizar todos los cambios realizados en el sistema y proceder a su tratamiento.

Autorizaciones necesarias:

Para que el usuario puede ejecutar las transacciones:

  • Objeto S_TCODE: con las transacciones FK08 y FK09 (el resto de usuarios no tendría que tener acceso a estas transacciones.
  • Autorizaciones propias del maestro de proveedores (idem para clientes con el objeto KNA1).

F_LFA1_AEN Acreedor: Autorización modificación p.campos determinados
F_LFA1_APP Acreedor: Autorización para aplicación
F_LFA1_BEK Acreedor: Autorización de cuentas
F_LFA1_BUK Acreedor: Autorización para sociedades
F_LFA1_GEN Acreedor: Datos centrales
F_LFA1_GRP Acreedor: Autorización de grupos de cuentas

Referencias:

Gracias a Anupa Wijesinghe y a sus colaboradores por el gran trabajo de divulgación que hacen en su blog learnsaptips.comhttp://www.learnsaptips.com/2016/02/dual-control-in-vendor-master.html

Publicado en Formacion, Sap FI, SAP MM, Sap SD | Etiquetado , , , , , | 6 comentarios