Truco 72. Determinación automática del Indicador de Impuesto (Iva) en pedidos de compra (MM).


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.

DetIVA1

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.Compras-Centro. 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.

DetIVA2

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.

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

DetIVA4

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

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

DetIVA6

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.

DetIVA7

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.

DetIVA8

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.

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

DetIVA10

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

DetIVA20

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.

DetIVA21

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.

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

Truco 71. Exclusión de condiciones de precio en MM/SD.


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 excluyentes entre si. Por ejemplo, si tenemos un descuento X y un descuento Y a la vez en el cálculo, uno de ellos no debería de ser aplicado. También podríamos utilizar la funcionalidad para seleccionar las condiciones más favorables o menos favorables dentro de unos grupos determinados.

ExcCond1

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

ExcCond2

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

ExcCond3

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

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

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

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

 

Publicado en SAP MM, Sap SD | Etiquetado , , , , | 2 comentarios

Truco 70. Copia de condiciones de precio en MM o SD.


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.

Copiacond1

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

Copiacond2

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

Copiacond3Realizaremos a continuación la selección de los registros de condición que vayamos a utilizar como modelo en la copia.

Copiacond4

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

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

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

Copiacond7

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.

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

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

Publicado en SAP MM, Sap SD | Etiquetado , , , , , | 2 comentarios

Los números de 2014


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.

Publicado en Formacion | Deja un comentario

Truco 69. Numeración de Facturas Personalizada. Compras (MIRO) y Ventas (VF01/VF04).


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

numeracion_facturas1

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

numeracion_facturas2

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.

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

numeracion_facturas4

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:

numeracion_facturas5

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.

numeracion_facturas6

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.

numeracion_facturas7

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!!!

numeracion_facturas8

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

Truco 68. Pago a plazos en Facturas de Compras.


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.

PagoPlazos1

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.

PagoPlazos2

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.

PagoPlazos3

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.

PagoPlazos4

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

PagoPlazos5

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.

PagoPlazos6

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

PagoPlazos10

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.

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

Truco 67. Valores por defecto al crear Proveedores (o Clientes) en SAP.


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.

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

bapi proveed1

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.

Truco67_2

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.

Truco67_3

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.

Truco67_4

 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.

Truco67_5

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.

Truco67_6

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.

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

Truco 66. Retención de documentos de material (transacción MIGO).


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.

Retencion_Migo_1Despué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.

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

Retencion_Migo_3

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.

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

Retencion_Migo_5

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

Retencion_Migo_6

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.

Retencion_Migo_9Espero que os sea de interés.

 

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

Truco 65. Formas de encontrar la transacción que se usa en la parametrización de SAP.


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

Tcode_SPRO

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.

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

Tcode_SPRO3

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.

Tcode_SPRO4

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.

Tcode_SPRO5Pero, 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”:

Tcode_SPRO6

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

Tcode_SPRO7

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.

Tcode_SPRO8

A continuación, con la transacción SE16N y la tabla CUS_IMGACH, buscaremos con el código de Actividad IMG que hemos localizado.

Tcode_SPRO9

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.

Tcode_SPRO10

Nos costo, pero al final lo conseguimos. Espero os parezca interesante.

Referencias: http://scn.sap.com/docs/DOC-44645

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

Truco 64. Sustituciones de CO (OKC9). Cambio de la cuenta de mayor.


Despues de un tiempo sin poder publicar (no por falta de ganas, pero si por mucha falta de tiempo), volvemos a la carga. Han sido unos meses duros, con cambio de ciudad, de trabajo, terminando los cursos de formación MM en los que estaba enfrascado. Por fin he encontrado un hueco y os voy a seguir contando cosas en las próximas semanas que considero interesantes conocer para la gestión de un sistema Sap.

En una entrada antigua del blog hablamos de las sustituciones en Sap (módulos FI, CO, PS), que son una técnica que nos permite cambiar valores en la lógica de proceso de las transacciones. En la entrada vimos un ejemplo concreto de como cambiar el centro de coste al que se imputa si se cumplen determinadas condiciones utilizando las sustituciones de CO (transacción OKC9). También vimos otro ejemplo de sustitucion en CO utilizando programación (ver entrada aquí).

En el blog he recibido multitud de consultas que preguntan sobre la forma de utilizar esta misma sustitución de CO para poder cambiar la cuenta de mayor. Por defecto, el campo de la cuenta no esta disponible y por tanto, no se puede utilizar en las sustituciones (Sap no lo recomienda).

Sustitucion Cuenta1

Pero tenemos la posibilidad de configurar los campos que aparecen disponibles para hacer sustitucion sobre ellos (los que vemos en la imagen superior) de una forma muy sencilla.

Los campos disponibles se encuentra en la tabla GB01. Los podemos mantener desde la transacción SM30/SM31, utilizando la vista de actualización VWTYGB01.

Sustitucion Cuenta2

Será tan sencillo como añadir la tabla COBL, campo HKONT, desmarcando el flag Excluir. A partir de este momento, el campo ya estará disponible para ser sustituido en el módulo de controlling.

NOTA: Al tratarse de una dato que se genera de forma automática en muchos lugares de la parametrización de la determinación de cuentas, la recomendación es utilizar esta posibilidad con mucha precaución y solo para casos concretos. Y siempre analizando las posibles repercusiones que puedan tener este cambio de cuenta que realicemos en el sistema.

Como ejemplo, he montado una sustitución sencilla para forzar en las compras imputadas a Activo Fijo que siempre se use una determinada cuenta de mayor en las contabilizaciones (seguramente ahí habría que añadir mas condiciones para afinar más su funcionamiento).

Sustitucion Cuenta3

Una funcionalidad muy interesante que se puede utilizar en las sustituciones son los sets. En la definición de condiciones se pueden utilizar valores individuales o bien conjuntos de datos (SETS, que se pueden definir desde la transacción GS02). EL uso de Sets nos puede facilitar la vida, ya que con modificar el set estaremos cambiando el comportamiento de la sustitución sin necesidad de tocarla y transportarla a todos los sistemas (Desarrollo, Calidad, Producción). El SET es un dato maestro y se puede mantener directamente en los sistemas productivos, y puede ser una forma mucho más flexible de definir las condiciones que ha de cumplir la sustitución (también lo podriamos aplicar para las validaciones). Por ejemplo, definir la lista de sociedades donde ha de aplicar la sustitución, la lista de centros de coste, cuentas, etc.

Espero que os sea de utilidad.

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