Notas y Trucos SAP Bitacora Trucos y Anotaciones para El Dia A Dia Con Sap PDF

14/9/2015 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 73. Personalizando el listado de documentos de material (transacción MB51).
Publicado el 11 mayo, 2015
7 Votes
La transacción MB51 es una de las más útiles en la gestión de stocks, pues nos permite realizar una análisis
completo de los movimientos de mercancía realizados en nuestro sistema.
Con el simple uso de la herramienta podemos ver los movimientos por clase de movimiento, con valor, incluyendo
información de los clientes o proveedores implicados en el movimiento, las relaciones con otros documentos
(pedido de compra, pedido de venta, reservas), objetos de imputación utilizados, valoración de los movimientos,
etc.
Igualmente, podríamos visualizar

información sobre el tipo de stock utilizado (por ejemplo stocks especiales), si el movimiento es contra consumo o
contra stock (por ejemplo en una entrada de mercancía de pedido), los motivos del movimiento o el usuario y
fecha/hora en la que se realizo el movimiento. Desde mi punto de vista, uno de los informes más completos y que
me ha sacado de apuros en más de una ocasión.
Una de las cosas menos conocidas de este informe es la posibilidad de parametrizarlo y añadir, tanto en
los criterios de selección como en la lista de resultados, otros campos disponibles en las tablas de
documentos de material (tablas MKPF y MSEG).
Para hacer esto, accederemos a la ruta de customizing Gestión de materiales –> Gestión de Stocks e Inventario –>
Reporting –> Especificar selección de campos p. lista documentos material.
https://saptricks.wordpress.com/ 1/44
Se nos mostrarán los campos asignados actualmente al informe, con un flag en la primera columna si el campo se
utiliza en los criterios de selección y un flag en la segunda columna si se utiliza en los resultados del informe.
Aparte de modificar la configuración de los campos existentes (por ejemplo, modificar un campo ya existente en
los resultados y ponerlo como criterio de selección), podremos añadir otros campos “ocultos” para que aparezcan
tanto en los criterios de selección como en los resultados.
Están disponibles prácticamente todos los campos de las tablas MKPF y MSEG. Y una recomendación, añadir
determinados campos como criterios de selección puede dar lugar a consultas muy lentas debido al tamaño que
suelen tener las tablas que almacenan los documentos de material.
Compartir:
 Correo electrónico Compartir 0 Tweet 3  Imprimir Share 1
 Me gusta
A un bloguero le gusta esto.
Publicado en Formacion, SAP MM | Etiquetado Ampliacion Listados Documentos Material, mb51, MKPF MSEG, SAPMM | Deja un comentario
Truco 72. Determinación automática del Indicador de Impuesto (Iva) en pedidos de
compra (MM).
Publicado el 21 marzo, 2015
2 Votes
Cuando creamos los pedidos de compras en SAP (transacción ME21N), podemos introducir el Indicador de
Impuestos (Iva) a nivel de cada una de las posiciones del documento, en la pestaña Factura.
Esta información se utilizará posteriormente como valor de propuesta en el registro de facturas de compras con la
transacción MIRO o como base para el cálculo de impuestos si estamos utilizando la Autofacturación.
La determinación del indicador de IVA en los pedidos de compras se realiza normalmente a partir
de la información existente en los registros info, donde alimentamos los datos de condiciones a nivel de
Proveedor, Material y Organización Compras / Org.ComprasCentro. En los registros info, ademas de indicar
condiciones de precio, también se detallan plazos de entrega habituales, cantidades de compras, normas de envio,
tratamiento de suministro incompleto o excedido, control de confirmación o el indicador de Iva a utilizar en
esta combinación Proveedor Material.
En ocasiones, nos puede interesar que la determinación del indicador de IVA sea independiente de
los registros Info. En ese caso, utilizaremos el esquema de cálculo como herramienta para inicializar el valor
del campo en los posiciones del pedido. Si la determinación se realiza por el esquema de cálculo, esta tendrá
prioridad sobre el valor existente en el registro info (en el caso de que se encuentren las condiciones oportunas).
Por ejemplo, si queremos determinar el indicador de Iva de una forma general (por organización de
compras), con excepciones por material o por grupos de material o por el país del proveedor,
sería una solución el hacerlo usando el esquema de cálculo.
En mi caso concreto, he tenido que usar esta funcionalidad por los últimos cambios legales para IVA que hay en
España (nuevos supuestos de Inversión del sujeto pasivo), donde la compra de determinados materiales de
Informática, Tablets, pasa a estar exento de Iva (realmente hay una contabilización doble de iva soportado y
repercutivo que da un saldo de Iva cero), lo que se llama Inversión del Sujeto Pasivo.
Veamos los pasos a realizar para configurar esto en nuestro sistema.
Creación de las tablas de condición y secuencia de acceso.
En primer lugar, tendremos que decidir con que criterios queremos determinar los indicadores de
impuestos. Por ejemplo, podremos establecer un criterio general, por Organización de Compras, o criterios
dependientes del material (hay un indicador de tipo de impuesto que se puede mantener en la vista de Compras
del material; los valores de este campo se puede definir en la vista de customizing V_TMKM1, tcode SM31), o
dependientes del pais donde compramos, etc.
En nuestro ejemplo, y para no complicar demasiado las diferentes casuísticas, vamos a definir las tablas de
condición por:
905 OrgCompras/Material
906 OrgCompras/Gpo.artíc
907 OrgCompras
En mi caso no he incluido el país origen o destino de la mercancía (aspecto que puede ser relevante en un ejemplo
real). Por eso, tener en cuenta que ya tenemos tablas de condición estándar para la determinación de impuestos
en compras. Por ejemplo, la 80 (Indicador Impuesto del material en la vista de compras y Pais receptor).
Todo será cuestión de analizar las tablas existentes y nuestros necesidades, y decidir utilizar las estandar o crear
nuestras tablas de condición personalizadas.
La creación de las tablas de condición se realiza con la transacción M/03. Básicamente se indican los
campos que utilizaremos para la creación de los registros de condición (y que por tanto nos determinarán el tipo
de impuesto a aplicar).
Con la opción Vista Técnica se puede configurar la estructura de los campos en la transacción de
creación/modificación de los registros de condición (transacción MEK1/MEK2).
A continuación, incluiremos las tablas definidas en la secuencia de acceso (lista de tablas de condición)
que vayamos a utilizar en la creación de nuestra condición de impuestos. Esto lo realizaremos desde la ruta de
customizing Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar
secuencia de acceso.
Es muy importante indicar las tablas en el orden correcto, pues será la forma en que SAP ira a
buscar los registros de condición. Las condiciones más especificas (con mas nivel de detalle) deberán de ir
primero, y luego las de menos nivel de detalle (mas generales). Y siempre marcar el flag Exclusivo para que el
sistema no siga buscando cuando encuentre una condición.
Creación de la clase de condición ZIVA.
En el estándar ya tenemos definida una Clase de condición para el Iva (la MWST). Pero vamos a crearnos una Z
como copia de esta para no tocar la configuración predefinida. Para ello, accederemos a la ruta Gestión de
materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar clase de condición.
Crearemos la clase de condición ZIVA, en la categoría de condición D Impuestos y no procesable de
forma manual. Importante indicar la secuencia de acceso que hayamos creado previamente con las tablas de
condición oportunas.
Ajustes en el esquema de cálculo de compras.
El último paso de configuración consiste en incluir la nueva condición en el esquema de cálculo que
utilicemos para realizar la valoración de nuestros pedidos de compra. Para ello, accederemos a la
ruta Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar esquema de
cálculo.
Una vez localizado el esquema de cálculo que usemos en nuestro sistema, incluiremos nuestra clase de condición
en la sección de impuestos, y siempre como una condición estadística (solo es informativa, no se va a
realizar ninguna contabilización con ella). Esto es así porque los impuestos los introduciremos en el momento de
registrar la factura.
Creación de registros de condición para la determinación del impuesto.
La creación de los registros de condición la realizaremos con las transacciones MEK1/MEK2/MEK3. Al crear los
registros, el sistema nos pedirá la combinación de claves a utilizar. Esto no es más que elegir entre las diferentes
tablas de condición existentes en la secuencia de acceso que hayamos asignado a la clase de condición.
La secuencia de acceso determinará a que nivel de datos crearemos los registros de condición. Para nuestro
ejemplo, voy a crear el registro de condición a nivel de Organización de Compras.
En el registro de condición indicaremos el porcentaje de Impuesto (que tendrá que estar alineado con
la configuración del indicador de Iva en la tabla FTXP), el periodo de validez y el indicador de impuesto a
utilizar (S5 en mi ejemplo). Este indicador de impuesto será el que luego se ofrecerá como propuesta en los datos
del pedido.
Una vez concluida la parametrización, y dados de alta los registros de condición, al crear los documentos de
pedido, aparecerá la clase de condición ZIVA en los datos de condición a nivel de la posición
(siempre que se encuentren valores en los registros de condición que hagan que la posición del documento
determine el impuesto).
Pero no solo eso, en la pestaña Factura se nos habrá inicializado el campo “Ind.Impuestos” con el valor que
informamos al crear el registro de condición del impuesto.
Y tendremos la solución a la necesidad de determinar los indicadores de impuestos por criterios
generales en el sistema, sin necesidad de tener que informar del dato en todos los registros info
(teniendo en cuenta que no necesariamente siempre vamos a contar con ellos).
Nota Importante: el indicador de impuesto determinado por el esquema de cálculo tiene prioridad sobre el
indicador de impuesto existente en el registro info de condiciones (en caso de que exista este).
Gracias a Bijay Kumar por la información relacionada con este tip en la entrada del SCN:
http://scn.sap.com/thread/1994857.
Compartir:
 Me gusta  Seguir
3 bloggers like this.
Seguir “Notas y
Publicado en Formacion, SAP MM | Etiquetado Iva Pedidos, Iva por defecto en Pedidos, PO Default Tax Code, PO TAXES, Purchase Order Taxes, SAPMM | 2 comentarios
trucos SAP
(Bitacora)”
Truco 71. Exclusión de condiciones de precio en MM/SD.
Recibe cada nueva publicación
Publicado el 14 marzo, 2015 en tu buzón de correo
electrónico.
1 Vote Únete a otros 1.460 seguidores
Introduce tu dirección de correo electrónico
En ocasiones, en nuestro esquema de cálculo de condiciones (utilizado para el cálculo del precio de compra en
MM o del precio de venta en SD), podemos tener diferentes clases de condición que deberían ser
Suscríbeme
excluyentes entre si. Por ejemplo, si tenemos un descuento X y un descuento Y a la vez en el cálculo, uno de
Construye un sitio web con
ellos no debería de ser aplicado. También podríamos utilizar la funcionalidad para seleccionar las condiciones
WordPress.com
más favorables o menos favorables dentro de unos grupos determinados.
Resumiendo, las opciones disponibles serían:
selección de la clase de condición más/menos apropiada dentro de un grupo de exclusión de condiciones.
selección del registro de condición más/menos apropiado de una clase de condición, en caso de que existan
más registros de condición (p.ej., selección entre diversos registros de condición de la clase de condición
PR00).
selección del más/menos apropiado de entre dos grupos de exclusión de condiciones (en dicho caso se
acumulan todas las clases de condición de ambos grupos, comparándose las sumas).
procedimiento exclusivo: si en el documento existe cualquier clase de condición del primer grupo, todas las
clases de condición contenidas en el segundo grupo se fijan como inactivas.
La parametrización es muy sencilla de realizar, constando de 3 pasos. Vamos a ver un ejemplo de un escenario en
el que queremos que un conjunto de condiciones de descuento, no se puedan aplicar nunca en el cálculo si existe
otro/s descuentos específicos.
Parametrización de la exclusión de condiciones.
Si estuviéramos en Ventas (SD), accederíamos por la ruta de customizing Comercial –> Funciones Básicas –>
Determinación de Precio –> Exclusión de Condiciones –> Exclusión de Condiciones para Grupo de Condiciones.
Si estuviéramos en Compras (MM), accederíamos por la ruta Gestión de Materiales –> Compras –>
Condiciones –> Fijar determinación del Precio –> Definir Exclusión de Condiciones.
La filosofía de configuración es exactamente igual, con los siguientes pasos:
Definición de los grupos de exclusión.
En primer lugar, creamos las etiquetas para los grupos de exclusión a los que luego asignaremos las clases
de condición deseadas. Lo realizaremos en la opción “Definir grupos de exclusión de condiciones”.
Asignación de las clases de condición a los grupos de exclusión.
En la opción “Asignar clases de condición a grupos de exclusión”. Para los grupos de exclusión de condiciones que
vayamos a utilizar, indicamos la lista de clases de condiciones involucradas (una o varias).
En mi caso, tengo un grupo para descuentos globales, donde he incluido la condición de descuento por Material
(K004). En el segundo grupo, he incluido la condición Cliente/Material (K005).
La idea es evitar que se use un descuento por Material, si ya existe un descuento Cliente/Material (que se supone
es especifico para un cliente concreto, y más restrictivo).
Configuración de la forma de excluir las condiciones asociadas al esquema de cálculo.
En la opción “Actualizar exclusión de condición para esquema de cálculo”. Este último paso es el más importante.
En el, asociado al esquema de cálculo, indicamos como queremos que sea el tratamiento de exclusión de
condiciones y los grupos de condiciones involucrados.
En mi ejemplo, en el esquema estándar de ventas (SD) llamado RVAA01, he incluido una exclusión del tipo D
(Exclusivo). De esta manera, el sistema, cuando encuentra en el cálculo del precio una de las
condiciones incluidas en el Grupo 1, automáticamente se desactiva cualquier condición existente
del Grupo 2 (si las hubiera).
En nuestro ejemplo, si hay una condición del Grupo ZPR0 (clase de condición K005 Descuento por
Cliente/Material), las condiciones del Grupo ZPN0 (clase de condición K004 Descuento por Material ) serán
desactivadas en el cálculo del precio.
Podemos ver con el ejemplo de un pedido de venta como aparecen las condiciones y como son desactivadas en el
caso de que se cumplan las condiciones.
Otras opciones de configuración.
Además del método excluyente, con el que hemos configurado nuestro ejemplo, tenemos disponibles otros
métodos de configuración, que podemos ver en la imagen.
Estos otros métodos nos permitirían:
A Mas favorable entre las clases de condiciones: solo se indica en este caso un grupo de exclusión. De
las diferente condiciones que se hayan definido en el grupo, nos quedaremos con la más favorable.
L Menos favorable entre las clases de condiciones: solo se indica en este caso un grupo de exclusión.
De las diferente condiciones que se hayan definido en el grupo, nos quedaremos con la menos favorable.
B Mas favorable dentro de la clase de condición: para el caso de que existan varias condiciones de la
misma clase de condición, se quedará con la más favorable (para las clases de condición incluidas en el grupo).
E Menos favorable dentro de la clase de condición: para el caso de que existan varias condiciones de la
misma clase de condición, se quedará con la más favorable (para las clases de condición incluidas en el grupo).
C Mas favorable entre los dos grupos de exclusión: en este caso, se acumulan todas las condiciones de
los dos grupos y se comparan entre sí, quedándonos con el grupo que ofrezca condiciones más favorables.
F Menos favorable entre los dos grupos de exclusión: en este caso, se acumulan todas las condiciones
de los dos grupos y se comparan entre sí, quedándonos con el grupo que ofrezca condiciones menos favorables.
Como veis, es una funcionalidad sencilla de parametrizar y que nos puede permitir manejar las diferentes
situaciones en lo referente al cálculo del precio y la gestión de casuísticas especiales (sin necesidad de recurrir
todavía a las condiciones en el esquema de cálculo, que conllevan programación).
Espero que os sea de utilidad.
Compartir:
 Me gusta
Publicado en SAP MM, Sap SD | Etiquetado Exclusion condiciones precio, Pricing, pricing sap, SAPMM, SAPSD | 3 comentarios
Truco 70. Copia de condiciones de precio en MM o SD.
Publicado el 28 febrero, 2015
2 Votes
En ocasiones, nos encontramos con la necesidad de hacer una copia masiva de condiciones de precio
(precios, descuentos, recargos, portes, etc) y no se nos ocurre otra forma que preparar un fichero de carga y
mediante un legacy (LSMW), Batch Input o un desarrollo a medida realizar la carga de los datos proporcionados
por el usuario.
Existe también la alternativa de realizar una copia con modelo utilizando el estándar de Sap con un mínima
configuración (parametrización y en algunos casos la preparación de un sencillo programa de selección de los
registros a crear).
La alternativa la tenemos disponible tanto en SD (transacciones VK31, VK34, VK11 ,VK14) o en MM
(transacciones MEK1 o MEK4).
Nota Importante: realizar la copia utilizando este procedimiento pivota en torno a uno de los
valores de los registros de condición existentes. Por ejemplo, si tenemos un descuento asociado a un
proveedor, podremos copiar a N proveedores pivotando sobre el campo proveedor. Pero solo podremos pivotar
sobre un campo a la vez.
Por ejemplo, podremos igualmente copiar los registros de un material de un centro a otro.
En nuestro ejemplo, vamos a configurar la posibilidad de copiar unos registros de condición que hemos creado en
nuestro sistema (clase de condición ZRL1 %Descuento proveedor), replicando los registros existentes en un
proveedor a un conjunto de proveedores seleccionados en el momento de la copia.
Parametrización del control de copia.
Para la parte de MM, en la ruta Gestión de materiales –> Compras –> Condiciones –> Fijar
determinación de precio –> Control de copia para condiciones. Dispone de dos opciones de
configuración:
Regla de copia para clases de condición (vista V_T688K): en esta configuración indicamos las clases
de condición origen/destino para las que vamos a poder hacer copia.
Reglas de copia para condiciones (vista V_T688): en esta parametrización indicamos, para la tabla de
condiciones en la que tendremos definidos los registros de condición que vayamos a copiar, el campo sobre el
cual va a pivotar la copia.
Puede ser necesario revisar la configuración de las clases de condiciones (vista V_T685A) y su secuencia de acceso
para obtener la tabla de condiciones que se este utilizando en el sistema para la clase de condición que vayamos a
copiar.
En la sección de configuración Control de copia se indica el programa que nos permitirá hacer la
selección de los registros destino (en nuestro caso, la lista de proveedores a los que copiar la condición) para
los que realiza la copia de las condiciones modelo. Existe una lista de programa estandar con los criterios mas
habituales, aunque podremos crear nuestro propio programa Z tomando como modelo uno existente y adaptarlo a
nuestro criterio de copia.
Aquí también configuramos si te tomará la fecha de los registros de condición existentes como
modelo y si la regla de copia por defecto es la que estemos configurando.
Si estuviéramos en SD, la configuración se realizaría desde la ruta Comercial –> Funciones basicas –>
Determinación de precio –> Control de copia para condiciones. Exactamente con la misma filosofía de
funcionamiento.
Operativa de copia.
Una vez realizada la parametrización, accederemos a la transacción MEK4 e indicaremos la clase de
condición a copiar y la Combinación de claves de la secuencia de acceso asociada a la condición
(determinará la tabla de condición utilizada, que deberá de coincidir con la que hayamos configurado en el
customizing).
Realizaremos a continuación la selección de los registros de condición que vayamos a utilizar como modelo en la
copia.
Una vez presentando la lista de registros, accederemos a la utilidad de copia pulsando los botones Copiar o
Copiar con selección de regla (tal y como vemos en la imagen siguiente).
El sistema nos llevará al programa de selección de los registros destino que hayamos indicado en la
parametrización de las Reglas de Copia para Condiciones. Es este caso, indicaremos el proveedor origen de las
condiciones y los proveedores destino (si lo dejamos en blanco no ofrecerá toda la lista de proveedores).
Tras indicar los criterios de selección, el sistema nos mostrará una lista de los proveedores destino para la copia,
donde podremos seleccionar los valores que realmente queremos procesar.
En el último paso, el sistema nos mostrará la propuesta de registros que van a ser creados. Podremos
tener disponibles varias vistas para visualizar los registros a crear (en mi ejemplo, por periodos de validez y por
importe). Estas vistas se parametrizan en el customizing de Indice de condiciones, opciones Definir Resumenes y
Asignar resumenes.
Desde este lugar podremos seguir añadiendo registros a crear, pues están disponibles los botones Copiar y
Copiar con Sel.regla para afinar en la lista de valores a crear e incluir nuevos valores.
También tenemos disponibles los botones “Modificar Fecha” y “Modificar Importe” para realizar una
actualización masiva de esos valores en el caso de que fuera necesario.
Finalmente grabaremos y se realizara la creación de los registros de condición. Con la transacción
ME3K podremos consultar los registros creados y verificar que la creación se ha realizado correctamente:
Como habéis podido comprobar, un método sencillo para poder realizar una replicación masiva de registros de
condiciones con una configuración muy sencilla. Con la única limitación de poder pivotar sobre un único
valor, aunque nos puede ser muy útil en determinadas situaciones donde hay que realizar un
copiado rápido de condiciones o en aquellos casos donde se producen cambios organizativos que requieren
actualizaciones masivas en los registros de condición.
Espero que os sea de utilidad.
Compartir:
 Me gusta
Sé el primero en decir que te gusta.
Publicado en SAP MM, Sap SD | Etiquetado copia condiciones mm, copia condiciones sd, mek4, pricing sap, vk14, vk34 | 2 comentarios
Los números de 2014
Publicado el 31 diciembre, 2014
3 Votes
Los duendes de las estadísticas de WordPress.com prepararon un informe sobre el año 2014 de este blog.
Aquí hay un extracto:
El Museo del Louvre tiene 8.5 millones de visitantes por año. Este blog fue visto cerca de 510.000
veces en 2014. Si fuese una exposición en el Museo del Louvre, se precisarían alrededor de 22 días
para que toda esa gente la visitase.
Haz click para ver el reporte completo.
Compartir:
 Me gusta
Publicado en Formacion | Deja un comentario
Truco 69. Numeración de Facturas Personalizada. Compras (MIRO) y Ventas (VF01/VF04).
Publicado el 16 agosto, 2014
8 Votes
Hoy estamos de celebración por varios motivos. Por un lado, empiezo las vacaciones después de un año de mucho
trabajo y muchos cambios. Pero orgulloso del camino andado. Por otro lado, estamos de cumpleaños, pues
este post cumple el número CIEN desde que en noviembre de 2010 empece con el blog Saptricks
como un lugar de trabajo personal donde documentar tantas y tantas cosas de Sap imposibles de recordar en
detalle sin mas y otros temas que tenía que investigar en un momento dado y de las que quería dejar constancia.
Y la vez que llegamos a la publicación cien, estamos a punto de llegar al millón de visitas (en unos días
estaremos ahí), en el orden de 40 mil al mes. Toda una alegría y un reto, no es fácil dedicarle el tiempo que a uno
le gustaría, a escribir cosas (tengo mil ideas en la cabeza), a contestar a todas vuestras preguntas. Se hace lo que se
puede. Como os digo, todo un placer, gracias a los más de 1.100 seguidores por vuestro interés. Y lo más curioso,
en mi vida profesional he conocido este año a unas cuantas personas que eran seguidores de mi
blog, y nos hemos desvirtualizado.
En nuestro truco de hoy vamos a hablar de un problema frecuente que suele surgir en los proyectos de Sap: la
numeración de documentos de factura por estándar es bastante limitada, tanto en la parte de
compras (MIRO), como en la de ventas (VF01/VF04). Pero, al menos, Sap nos deja la puerta abierta con
las exits para personalizar el sistema y adaptarlo a lo que nos pida nuestro cliente.
Numeración de facturas en Compras.
Por estándar, en el registro de facturas de compras solo podemos utilizar dos rangos de numeración.
Uno para el registro de facturas manual (MIRO) y otro para el registro de facturas automático (que incluye la
anulación de facturas, autofacturación, liquidación del plan de facturas o recepción de facturas por EDI).
La configuración de los rangos de números la realizamos en la transacción OMRJ. A continuación,
asignamos los rangos por la actividad que hemos indicado (ruta de customizing Gestión de materiales –>
Compras –> Verificación de facturas de logística –> Facturas recibida –> Asignación de números –> Asignación
de números para documentos de logística –> Asignar rango de números a actividad).
Como veis, esto da pocas posiblidades para realizar, por ejemplo, una numeración por Sociedad (podría ser
el criterio habitual más solicitado) o por tipo de factura (factura, abono, carga posterior o descargo posterior; o
diferenciada por proceso).
Para solucionar esto, Sap nos deja la puerta abierta con la ampliación LMR1M003, que gestionaremos
con un proyecto de ampliación de la forma habitual con la transacción CMOD. En este post anterior teneís un
ejemplo de todos los pasos necesarios para crear un proyecto de ampliación por si los desconocéis.
La exit usa el módulo de función EXIT_SAPLMRME_003 y podemos incluir nuestro propio código en el
include ZXM08U14. Tenemos disponibles la mayoría de campos de la cabecera de la factura para determinar
nuestro lógica de numeración (Sociedad, Transacción, Operación, Fechas, Proveedor, etc), así como la
información de las posiciones por si fuera necesario analizarlas.
La configuración sería la siguiente:
1) Habremos de definir los rangos de números a utilizar con la transacción OMRJ.
2) Posteriormente, en el código abap de la exit devolveremos en el parámetro E_NUMKR el rango de números a
utilizar (de los que acabamos de definir).
En mi ejemplo, he creado una tabla Z donde el usuario asigna, por sociedad, el rango de números a
utilizar. Posteriormente, en el código de la exit leemos la sociedad de a factura, recuperamos el rango de
números. Requerimiento cumplido.
Como podéis ver, una forma sencilla de personalizar el comportamiento de la numeración. Tener en cuenta
que la numeración afecta tanto a la grabación de las facturas, como las preliminares o los
documentos retenidos.
El código Abap introducido en la exit sería el siguiente:
Numeración de facturas en Ventas.
En la numeración de las facturas de ventas nos ocurre algo parecido. Los rangos de números se definen
con la transacción VN01. Posteriormente, estos rangos se asocian por Clase de Documento de Factura,
parametrización que se realiza en la transacción VOFA.
En este caso, tenemos igualmente una puerta abierta para personalizar la numeración con la exits de ventas. Aquí
no se utilizan los proyectos de ampliación, sino unos incudes estandar que Sap nos deja “preparados” para
introducir nuestro código. Realmente son una modificación del estandar. En nuestro caso, usaremos el
include RV60AFZZ, en el form USEREXIT_NUMBER_RANGE.
En este caso, la lógica a aplicar sería la misma. En primer lugar, crearíamos los rangos de números a utilizar de la
forma usual, con la transacción VN01. A continuación, en la exit determinaríamos la programación para
determinar el rango a utilizar según la información de la factura a crear (Sociedad, Organización de
Ventas, etc), y devolveremos el valor del rango de números a utilizar en la variable US_RANGE_INTERN.
Es usual utilizar esta misma exit para realizar controles de la fecha de facturación. Por ejemplo, por
temas legales, en España un número de factura no puede tener una fecha de factura anterior a una factura emitida
previamente.
En la exit se podría controlar este aspecto y otros similares a través de tablas Z: una tabla Z para definir el rango
de números a usar (por Sociedad, Organización de Ventas, o por el criterio deseado) y otra tabla Z donde ir
guardándonos la fecha de la última factura por rango de numeración para ir realizando el control, generando un
mensaje de error desde el mismo include.
TIP: podemos tener la misma problemática para la numeración de pedidos de ventas. En este caso, la
asignación a las clases de documento se realiza con la transacción VOV8. Podemos personalizar igualmente su
funcionamiento utilizando el include MV45AFZZ y el form USEREXIT_NUMBER_RANGE. Recordar
que tanto los números de pedidos de ventas como de facturas comparten los rangos de números
(que definimos como ya comentamos con la transacción VN01). Habremos de tener en cuenta este aspecto a la
hora de definir los rangos y la disponibilidad de intervalos de cada uno de ellos.
¡¡¡Buen verano y feliz MILLON!!!
Compartir:
 Me gusta
Publicado en Formacion, SAP MM, Sap SD | Etiquetado Exit numeracion facturas, Invoice number exit, miro, Numeracion facturas, VF01, VF04 | 14 comentarios
Truco 68. Pago a plazos en Facturas de Compras.
Publicado el 31 julio, 2014
3 Votes
En muchas ocasiones, cuando realizamos compras se negocia un pago a plazos con el proveedor. De esta

forma, el importe de una factura podrá ser partido en varios pagos, con diferentes vencimientos que reflejen las
condiciones acordadas con el proveedor.
Para poder registrar estas facturas en el sistema y realizar esta partición, tenemos dos alternativas:
1) Partición manual: activar la partición de importes por Sociedad. Esto nos permite indicar de forma
manual los importes de los diferentes partidas a la hora de registrar las facturas (transacciones
MIRO si lo hacemos desde MM o FB60 si lo hacemos directamente en Finanzas).
2) Partición automática: configurando condiciones de pago a plazos. De esta manera, la partición será
automática, según los porcentajes y condiciones para los vencimientos indicadas en la
parametrización de las condiciones de pago.
Veamos un poco más en detalle como configurar el sistema para poder utilizar cada una de estas dos alternativas.
Partición manual: activar la partición de importes por Sociedad.
En este caso, tendremos que modificar la parametrización de los parámetros globales de la Sociedad
FI. A través de la ruta de customizing Gestión Financiera –> Parametrizaciones básicas de gestión financiera –>
Parámetros globales para la sociedad –> Verificar y completar parámetros globales. También podemos acceder
con la transacción SM30, vista V_001_B.
Marcaremos el flag “Permitir partic.imptes.”. Al activar este indicador, en la transacción MIRO nos aparecerá una
nueva pestaña en cabecera, llamada Part.Importe. Aquí podremos realizar, de forma manual, la
partición de los importes de pago según nuestras necesidades. Cada importe generará una partida
individual en la cuenta del proveedor.
Los datos de vencimiento de cada una de las partidas los determina la Condición de Pago que indiquemos en cada
importe (esto nos permitirá indicar una condición de pago a cada una de ellas de forma oportuna; por ejemplo,
para generar un vencimiento a 30 días, otro a 60 días, etc). De todas maneras, las fechas de vencimiento podrán
ser modificadas posteriormente en el tratamiento de las partidas individuales.
Igualmente, en el registro de facturas de compras desde Finanzas (transacción FB60), también
aparecerá la misma pestaña y podremos realizar las mismas operativas de particionado de importes.
Nota: la información introducida en la partición de importes tiene prioridad sobre la condición de pago indicada
en la factura.
Partición automática: condiciones de pago a plazos.
Sap nos permite configurar condiciones de pago que llevan asociado un pago a plazos. Para poder hacer esto,
hemos de realizar las siguientes tareas de parametrización:
a) Configurar una condición de pago indicando que lleva asociado pago a plazos.
Accediendo a la transacción SM30, vista V_T052. Bastará con marcar el flag “Pago a plazos” para indicar que la
condición llevará un pago asociado en varios importes.
b) Determinar el número de plazos, % importe y condición de pago asociada a cada plazo.
Accediendo a la transacción OBB9. En esta parametrización indicaremos el número de pagos (Partidas
Individuales) que habrá que generar cuando utilicemos la condición de pago, así como los % de importe de
cada uno de los pagos y la condición de pago que se utilizará para calcular los vencimientos de cada
uno de los plazos.
A continuación, verificaremos que la configuración realizada es correcta realizando el registro de una factura
utilizando la transacción MIRO (la condición de pago Z009 estará predefinida en el proveedor o podremos
indicarla en el momento del registro de la factura, en la cabecera, pestaña Pagos).
Haciendo la simulación podremos ver que se generan para la factura 3 partidas individuales diferentes.
Finalmente, realizamos la contabilización de la factura y desde el informe de partidas abiertas (transacción
FBL1N), podemos comprobar como se han generado correctamente los plazos y las fechas de
vencimiento asociadas, para una única factura de compras.
NOTA: la configuración de las condiciones de pago es común para clientes y proveedores. Por tanto,
para realizar la partición de facturas de ventas seguiremos exactamente los mismos pasos en la configuración de
las correspondientes condiciones de pago que vayamos a utilizar en los clientes. Respecto a la posibilidad de
trocear las facturas manualmente, al activar la partición a nivel de sociedad, también aparecerá la
pestaña partición en el registro de facturas de ventas desde FI (transacción FB70).
Si queréis más información acerca de la configuración de las formas de pago, os recomiendo la lectura de la
entrada que nuestro amigo Oscar Arranz publicó en su Blog de Sap.
Igualmente, os dejo el acceso a un documento PDF en Ingles elaborado por SiliconLabs con los pasos detallados
de la configuración de los pagos a plazos.
Un saludo y buen verano a todos.
Compartir:
 Me gusta
Publicado en Formacion, SAP MM, Sap SD | Etiquetado FB60, FB70, installment payment, miro, Pago plazos, SAPMM | 7 comentarios
Truco 67. Valores por defecto al crear Proveedores (o Clientes) en SAP.
2 Votes
Un requerimiento muy habitual en cualquier proyecto de implantación o de mantenimiento de Sap es la
posibilidad de inicializar con valores por defecto determinados campos en el maestro de
Proveedores o de Clientes en el momento de crearlos. Además, es posible que estos valores tengan
dependencia de otros campos del maestro que es posible controlar (por ejemplo, según la Sociedad, Organización
de Compras, Organización de Ventas, Grupo de Cuentas, etc).
Si lo que necesitamos hacer es muy genérico, con valores por defecto sin ninguna lógica de control, podríamos
utilizar las variantes de transacción para inicializar valores por defecto en determinados campos
de las pantallas de las transacciones. Podéis ver las siguientes entradas que hablan sobre ello y la forma de
crear variantes de transacción.
http://sapinsider.wispubs.com/Assets/Blogs/2011/July/SettingUpDefaultFieldValuesfortheVendor
andCustomerMaster
https://saptricks.wordpress.com/2011/05/22/truco13transaccionespersonalizadasconlasvariantesde
transaccionshdo/
Pero realmente las variantes de transacción son difíciles de configurar y poco flexibles para luego hacer cambios.
Por tanto, si ademas de eso tenéis pensado incluir una lógica inteligente en esta asignación inicial de valores por
defecto, yo os recomiendo utilizar la adaptación del sistema que Sap nos habilita para este caso, en concreto:
BADI: VENDOR_ADD_DATA
Metodos:
PRESET_VALUES_CCODE: para inicializar valores en la información de sociedad (tabla LFB1).
PRESET_VALUES_PORG: para inicializar valores en los datos de organización de compras (tabla LFM1).
PRESET_VALUES_PORG_ALTERNATIVE: para inicializar valores en los datos de organización de
compras, para los datos divergentes por centro/surtido de proveedor (tabla LFM2).
Podéis consultar las definiciones de la BADI con la transacción SE18, así como la documentación asociada a cada
método.
El procedimiento para implementar la BADI en nuestro sistema sería el siguiente:
1. Creación de la implementación propia de la BADI con la transacción SE19.
2. Programación del código necesario en el Método.
3. Validación y pruebas.
Creación de la implementación propia de la BADI con la transacción SE19.
Desde la transacción SE19 creamos la implementación de la BADI VENDOR_ADD_DATA, con el nombre
oportuno siguiendo las recomendaciones de Sap en cuanto a nomenclatura.
A continuación indicaremos el nombre de la implementación de la Badi, asi como la clase asociada, enlazándola
con la definición de Badi VENDOR_ADD_DATA.
El sistema nos pedirá el paquete donde queremos incluir los objetos creados, asi como la correspondiente orden
de transporte para luego poder pasar las especificaciones a nuestro sistema de productivo.
Programación del código necesario en el Método.
A continuación desde la misma SE19 accederemos a la implementación para acceder al código Abap del método
PRESET_VALUES_CCODE, tal y como observamos en la imagen.
En mi ejemplo voy a inicializar valores incluidos en los datos de Sociedad del proveedor. Si quisierais
actualizar los datos de compras usaríamos el método PRESET_VALUES_PORG en lugar del indicado.
En el código incluimos la lógica de proceso de la inicialización, teniendo en cuenta que:
La variable I_ACTIVITY la actividad que estamos realizando: si estamos en la creación de un
proveedor (valor H) o en la modificación (valor V).
La estructura I_LFA1 incluye toda la información de los datos generales del proveedor (no modificable).
La estructura E_LFB1 incluye los datos de sociedad del proveedor (modificable).
Nota: el método se ejecuta en el evento PBO (Process Before Output) en todas las pantallas donde se encuentran
los datos de sociedad.
Validación y pruebas.
A continuación accedemos a las transacciones de creación de proveedores para verificar el correcto
funcionamiento del código abap incluido (en este caso, al estar inicializando los datos de sociedad, podriamos
utilizar la XK01 o FK01).
En nuestro ejemplo, procedemos a crear un proveedor de un grupo de cuentas 0001. Al llegar a los datos de
sociedad, podemos observar como los valores deseados son inicializados según la lógica descrita en el método de
la Badi.
De esta manera, nos aseguramos que determinados campos relevantes se inicialicen con determinados valores al
crear los proveedores, siguiendo si es necesario una lógica relevante según los valores de las unidades
organizativas o los valores de otros campos de referencia.
NOTA: si tuviéramos el mismo requerimiento, pero para el maestro de clientes, podríamos utilizar,
con la misma lógica para su configuración:
BADI: FM_CUSTOMER_ADD_DATA
Método: PRESET_VALUES_AREA
Espero que os sea de interés.
Compartir:
 Me gusta
Publicado en Abap, SAP MM, Sap SD | Etiquetado fd01, fk01, KNB1, KNVV, LFB1, LFM1, Maestro Clientes, Maestro Proveedores, mk01, xd01, xk01 | 1 Comentario
Truco 66. Retención de documentos de material (transacción MIGO).
4 Votes
Hoy volvemos al módulo de MM – Gestión de Materiales para hablar de una funcionalidad muy sencilla que
tenemos disponible en la transacción central MIGO, que ha sido diseñada por Sap para poder realizar la mayoría
de operaciones relacionadas con los documentos de material y los movimientos de mercancía.
Cuando estamos realizando cualquier movimiento con la MIGO (entradas de mercancía, traspasos, salida, etc), en
ocasiones se nos presentan errores que nos impiden continuar con el movimiento. O simplemente hemos de dejar
aparcado un movimiento que tenemos a medias, para el cual no queremos perder el trabajo realizado.
Para estos casos, Sap nos ofrece la función Retener, que nos permite guardarnos un borrador de ese
movimiento, al cual podremos acceder posteriormente.
Después de seleccionar la opción, se nos presentará un cuadro de dialogo para indicar un identificador para
ese movimiento borrador. Aquí podremos introducir la etiqueta que nos permitirá identificar posteriormente
el movimiento a la hora de recuperarlo.
Podremos acceder a la lista de movimientos retenidos desde el Resumen de Documentos, en la sección Datos
Retenidos. El resumen de documentos se abre con la opción “Activar Resumen”. En este resumen
aparece, además de los documentos retenidos, información de los ultimos 10 documentos tratados (Pedidos,
Ordenes, Reservas y Documentos de Material), lo que es una muy buena opción para recuperar el identificador de
algunos de los movimientos realizados mas recientemente por el usuario en el sistema.
Recuperar documentos retenidos.
Para continuar trabajando con un documento que retuvimos previamente, accederemos al Resumen
de documento desde un nuevo documento, y en la sección Datos retenidos haremos un doble click sobre el
documento que queramos procesar.
En ese momento toda la información del documento será transferida a la MIGO y la entrada
desaparecerá de los datos retenidos. De esta manera podremos concluir el documento de material o volverlo
a retener posteriormente si fuera necesario.
Usar documentos retenidos como modelo.
Ademas de permitirnos guardarnos los borradores de los documentos, la función de retención también nos
permite crearnos MODELOS de documentos de material. Esta es quizás unas de las funciones más
interesantes de la retención de documentos.
La forma para crear modelos será la misma que la utilizada para retener documentos. Únicamente habrá que
introducir en el campo Modelo el valor ‘X’ cuando estemos realizando la identificación del
documento retenido, tal y como vemos en la imagen siguiente.
Este valor producirá que el documento quede clasificado como modelo (en el resumen de Datos retenidos se
identifican los documentos Modelo con el Icono del *).
NOTA: los documentos retenidos como modelo no son borrados del resumen de documentos
cuando son utilizados, como si ocurre con el resto de documentos retenidos. Podremos eliminarlos
manualmente con el icono Borrar existente en el resumen de documentos.
Gestión de Datos Retenidos.
La función de retención aplica a nivel de usuario. Es decir, cada usuario solo puede ver sus propios datos
retenidos, pero nunca los datos de otros usuarios.
Si existe una utilidad para realizar el borrado de datos retenidos, que podrá utilizar el administrador del
sistema. A esta utilidad se accede desde la transacción MBPM.
Espero que os sea de interés.
Compartir:
 Me gusta
Publicado en Formacion, SAP MM | Etiquetado Formacion SAPMM, MIGO, SAPMM | 9 comentarios
Truco 65. Formas de encontrar la transacción que se usa en la parametrización de SAP.
4 Votes
Hoy nos vamos a un truco un poco más técnico que podemos utilizar para averiguar cual es la transacción
asociada a una parametrización dentro de la SPRO. A todos nos pica la curiosidad de saber cual es la
transacción que usa para un determinado paso del customizing (muchas veces para tenerla localizada y acceder de
forma mucho más rapida a ella, sin la tediosa navegacion en el arbol del custo, en la que no siempre recordamos la
opción para llegar a un punto concreto).
Esta tarea de averiguar la transacción no es siempre sencilla ni inmediata. Los siguientes pasos nos pueden
ayudar:
1) Visualizar la transacción en la barra de estado del sapgui: en la mayoría de ocasiones nos mostrará la
transacción SPRO (nuestro gozo en un pozo).
2) Utilizando la opción de menu Sistema –> Status: nos devuelve información similar al punto 1. Tambien
podemos ver el programa que se utiliza para este punto de parametrización, que nos podrá servir para encontrar
la transacción como explicaremos a continuación.
3) Dentro del árbol de parametrización de la SPRO, seleccionando la opción de menú Información
adicional –> Info adicional –> Visualizar clave –> Actividad IMG.
A nivel de cada uno de los pasos de parametrización nos aparecerá un texto con información adicional. En algunas
ocasiones, los 4 últimos dígitos de ese valor nos indicarán la transacción con la que se accede a
dicha parametrización (por desgracia, no siempre, y no hay una regla clara).
4) Localizando la transacción a través del programa asociado: nos iremos a la transacción SE16N, indicando
la tabla TSTC, que es donde se registran los datos de las transacciones en el sistema SAP.
En el campo Programa indicaremos el nombre del programa que habremos localizado siguiendo las instrucciones
del punto 1 o 2. Si tenemos suerte en los resultados de la búsqueda nos aparecerá el código de la transacción.
Pero, por desgracia, esto no siempre funciona.
5) Otra alternativa sería, desde el arbol de parametrización, seleccionar la opción que queremos investigar
y pulsando el botón derecho del ratón, elegir la opción “Visualizar información técnica”:
Nos aparecerá una ventana con información adicional. En la pestaña “Obj.actualiz” podremos ver la transacción
asociada (muchas veces la transacción es la SM30, que utiliza una vista de actualización sobre una tabla).
En mi ejemplo, la creación de las estrategias de liberación de pedidos, la podemos llamar desde la transacción
SM30, con la vista VV_T16FS_2. En otras ocasiones nos aparecerá directamente la transacción que llama a la
parametrización.
6) Si no hemos sido capaces de localizar todavía la transacción, nos queda una última alternativa que casi
siempre dará resultado. Con el ID del objeto de parametrización que podemos obtener siguiendo las
instrucciones del punto 5.
A continuación, con la transacción SE16N y la tabla CUS_IMGACH, buscaremos con el código de Actividad
IMG que hemos localizado.
Si todo esta bien, obtendremos como resultado un registro que nos indicará cual es la transacción que utiliza Sap
para llamar a ese punto de parametrización.
Nos costo, pero al final lo conseguimos. Espero os parezca interesante.
Referencias: http://scn.sap.com/docs/DOC44645
Compartir:
 Correo electrónico Compartir 1 Tweet 0  Imprimir Share 66 0
 Me gusta
Publicado en Formacion, Sap Basis | Etiquetado SAPBC, TCODE, Transaccion | 4 comentarios
Entradas antiguas
Notas y trucos SAP (Bitacora)
El tema Twenty Ten. Funciona con WordPress.

Notas y Trucos SAP Bitacora Trucos y Anotaciones para El Dia A Dia Con Sap PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Notas y Trucos SAP Bitacora Trucos y Anotaciones para El Dia A Dia Con Sap PDF

Cargado por

Copyright:

Formatos disponibles

14/9/2015 Notas y trucos SAP (Bitacora) | Trucos y anotaciones para el día a día con Sap

Igualmente, podríamos visualizar

 Correo electrónico Compartir 0 Tweet 3  Imprimir Share 1

 Correo electrónico Compartir 0 Tweet 2  Imprimir Share 0

 Correo electrónico Compartir 0 Tweet 2  Imprimir Share 0

 Correo electrónico Compartir 0 Tweet 2  Imprimir Share 0

 Correo electrónico Compartir 1 Tweet 0  Imprimir Share 0

 Correo electrónico Compartir 1 Tweet 0  Imprimir Share 0

En muchas ocasiones, cuando realizamos compras se negocia un pago a plazos con el proveedor. De esta

 Correo electrónico Compartir 1 Tweet 0  Imprimir Share 1

 Correo electrónico Compartir 0 Tweet 0  Imprimir Share 0

 Correo electrónico Compartir 0 Tweet 0  Imprimir Share 0

 Correo electrónico Compartir 1 Tweet 0  Imprimir Share 66 0

También podría gustarte