Notas y Trucos SAP

20/4/2018 Notas y trucos SAP (Bitacora) | Trucos y anotaciones para el día a día con Sap
Notas y trucos SAP (Bitacora)
Trucos y anotaciones para el día a día
con Sap
Truco 94. Activación automáticas de nuevas rutinas VOFM en la orden de transporte
Publicado el 2 febrero, 2018
6 Votes
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).
https://saptricks.wordpress.com/ 1/49
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.
¡¡¡Buen fin de semana!!!
Anuncios
Prueba Netflix Prueba Netflix

VER AHORA VER AHORA
Un mes gratis Un mes gratis
Report th i s ad Report th i s ad
Compart ir:
 Correo electrónico Tw ittear  Imprimir Share
Me gusta
A un bloguero le gusta esto.
Publicado en Abap, Formacion, Sap Basis, SAP MM, Sap SD | Etiquetado rv80hgen, vofm, xpra | 4 comentarios
Truco 93. Abrir una transacción de Customizing en un sistema productivo.
Publicado el 31 diciembre, 2017
9 Votes
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
SAP Note 77430 – Customizing: Current settings
SAP Note 133079 – MD25/MD26: Planning calendar as master data
SAP Note 557503 – OB58: Current settings in test system
SAP Note 538451 – Current settings in nonproduction systems
SAP Note 522215 – Current settings in nonproduction systems
SAP Note 512698 – Customizing of DIP profiles in the production system
SAP Note 40672 – System changeability and client control
SAP Note 149752 – Route definition not maintainable in produc. system
Gracias igualmente a Caetano Almeida su entrada sobre el tema en los blogs de Sap.
Feliz 2018 a todos.
Compart ir:
Me gusta
Sé el primero en decir que te gusta.
Publicado en Formacion, Sap Basis | Etiquetado customizing en productivo, ob52, ob58, production system customizing, scc4, vkoa | 2 comentarios
Truco 92. Añadir documentos en el Content Server (Archivelink) a partir de mensajes.
Publicado el 26 agosto, 2017
10 Votes
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:
Truco 44. Gestion Documental en Sap (I). GOS.
Truco 45. Gestion Documental en Sap (II). ArchiveLink.
Truco 46. Gestion Documental en Sap (y III). DMS.
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 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.
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.
Compart ir:
Me gusta
Publicado en Formacion, Sap Basis | Etiquetado Archivelink, Gestion documental | Deja un comentario
Truco 91. Análisis de modificaciones del precio medio variable de un material.
10 Votes
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.
Compart ir:
Me gusta
Publicado en Formacion, SAP MM | Etiquetado Average Price, mb51, MB5B, MBEW, MBEWH, MBMAPCHANGES, MR51, Nota 1506200, Nota 2198317, Nota 2256487, Precio
Medio Variable | 2 comentarios
Truco 90. Campos de cliente en la determinación de precios.
10 Votes
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).
¡¡¡¡Feliz verano a todos!!!!
Compart ir:
Me gusta
Publicado en Formacion, SAP MM, Sap SD | Etiquetado Campos cliente en precio, MM, Pricing, SD, User fields in pricing | 2 comentarios
Truco 89. Excluir un almacén de la verificación de disponibilidad (ATP).
Publicado el 4 junio, 2017
6 Votes
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 MARDDISKZ 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.
Compart ir:
Me gusta
Publicado en Formacion, Sap SD | Etiquetado ATP, AVAILABILITY CHECK, VERIFICACION DISPONIBILIDAD, V_V2 | Deja un comentario
Truco 88. Utilidad para carga de condiciones de precio.
Publicado el 7 enero, 2017
17 Votes
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.
Link a un ejemplo de fichero de carga: plantillacreacionpr00.
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.
Otros ejemplos de código:
https://blogs.sap.com/2013/08/13/rvconditioncopyexamplewithscales/
http://www.se80.co.uk/sapfms/r/rv_c/rv_condition_copy.htm
http://abapbox.blogspot.com.es/2011/02/changepriceofconditionrecordsby.html
https://archive.sap.com/discussions/message/2550343#2550343
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:
Que tengáis buena lectura.
Compart ir:
Me gusta
A 2 blogueros les gusta esto.
Publicado en Formacion, SAP MM, Sap SD | Etiquetado Condiciones, MEK1, RV_CONDITION_COPY, VK11 | 11 comentarios
Truco 87. Utilidades para actualizar estatus en documentos de ventas.
13 Votes
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).
Hay muchas más utilidades y reports para tratar otras situaciones. Os dejo la nota de sap KBA con número
2006809howtofixdeliveryrelatedinconsistencies donde se informa de muchos de ellos.
Un saludo a todos y buena lectura.
Compart ir:
Me gusta
Publicado en Formacion, Sap SD | Etiquetado Delivery status, RVDELSTA, Sales order status, SDVBUK00, status documentos ventas, Status entregas, vbuk, vbup | 2
comentarios
Truco 86. Proteger agrupaciones libres de clientes o proveedores por autorizaciones.
7 Votes
¡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.
Espero que os sea de utilidad.
Compart ir:
Me gusta
A un bloguero le gusta esto.
Publicado en Formacion, Sap FI, SAP MM, Sap SD | Etiquetado Autorizaciones clientes, Autorizaciones proveedres, F_KNA1_BED, F_LFA1_BEK, KNA1, LFA1 | Deja un
comentario
Truco 85. Variantes de transacción en el registro de facturas de compras (MIRO).
12 Votes
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.
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).
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).
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.
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”.
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”).
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.
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!!
Compart ir:
Me gusta
A 3 blogueros les gusta esto.
Publicado en Formacion, Sap Basis, SAP MM | Etiquetado Customize MIRO, miro, Personalizar MIRO, Transaction variant, Variante transaccion | 1 Comentario
Entradas antiguas
Notas y trucos SAP (Bitacora)
Blog de WordPress.com.

Notas y Trucos SAP

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Notas y Trucos SAP

Hochgeladen von

Copyright:

Verfügbare Formate

20/4/2018 Notas y trucos SAP (Bitacora) | Trucos y anotaciones para el día a día con Sap

Prueba Netflix Prueba Netflix

 Correo electrónico Tw ittear  Imprimir Share

 Correo electrónico Tw ittear  Imprimir Share

 Correo electrónico Tw ittear  Imprimir Share

 Correo electrónico Tw ittear  Imprimir Share

 Correo electrónico Tw ittear  Imprimir Share

 Correo electrónico Tw ittear  Imprimir Share

 Correo electrónico Tw ittear  Imprimir Share

 Correo electrónico Tw ittear  Imprimir Share

 Correo electrónico Tw ittear  Imprimir Share

Das könnte Ihnen auch gefallen