Truco 62. Textos de cabecera predefinidos en el registro de facturas de MM (Miro).


Cuando estamos trabajando con la transacción MIRO, en el registro de facturas desde MM, es habitual incluir, en la contabilización de estas, textos informativos referentes al concepto de la factura, incluyendo información del periodo, tipo de gasto, departamento, etc.

textos_miro1Al contabilizar la factura, el texto introducido se registra en el documento de Finanzas, en la posición del asiento de FI correspondiente a la cuenta del acreedor/proveedor, en el campo Texto.

textos_miro2Luego este texto lo tenemos disponible en el informe de partidas abiertas de proveedores, utilizando por ejemplo la transacción FBL1N. Teniendo ahí esta información, podemos realizar búsquedas o totalizaciones usando esa información del “concepto” al que se asocia la factura registrada.

textos_miro3Para facilitar el trabajo del usuario, así como para “normalizar” los valores que podemos introducir en este campo al registrar las facturas, tenemos la posibilidad de parametrizar una lista de valores que podremos usar en este campo (además de la lista de valores, siempre tendremos la opción de introducir texto libre).

La parametrización asociada se encuentra en la ruta de customizing Gestión financiera –> Contabilidad de deudores y acreedores –>  Operac. Contables –>  Recepción de facturas /Entrada de Abonos –> Realizar y verificar parametrizaciones para documento –> Almacenar textos para posiciones documento. Aquí definiremos los valores, asignándoles una clave identificadora y un texto asociado.

textos_miro4Con la opción de parametrización “Visual.control” sin marcar,el texto aparecerá en el campo con el formato =Z001 al seleccionarlo, apareciendo posteriormente el texto propuesto.

En la definición de los textos podemos incluir variables que se sustituirán en el momento de la contabilización. Las opciones disponibles son las siguientes:

  • &BLD   Fecha del documento.
  • &BUD   Fecha de contabilización.
  • &ZFB   Fecha base para plazo de pago.
  • $BUP   Periodo contable.
  • $XBL   Nº documento de referencia.

Esto nos permite añadir automáticamente información del documento generado sin necesidad de escribirla manualmente.

Al entrar un documento, podremos indicar la variable de texto precedida del signo ‘=’ (=XXXX) o bien utilizar el matchcode para seleccionar el texto deseado.

textos_miro5Nota: los textos también estarán disponibles para su uso en las transacciones de registro de facturas desde FI, tanto en la parte de Deudores (FB70 Facturas, FB75 Abonos), como para Acreedores (FB60 Facturas, FB65 Abonos).

Este truco forma parte del contenido del Curso MM Gestión de Materiales que estamos impartiendo en la actualidad, en la lección correspondiente al registro de Facturas. Espero que os sea de utilidad.

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

Truco 61. Añadir campos adicionales en los informes de pedidos de Compras.


Aunque no suele ser un requerimiento muy habitual, pues los informes estandar de pedidos ya ofrecen bastante información (por ejemplo, en las transacciones ME2L, ME2M, etc), en ocasiones podemos tener la necesidad de incluir otros campos en estas transacciones para visualizar contenido adicional o campos de cliente.

Si teneis este requerimiento y estáis en la versión de SAP ECC (EHP4 FOR SAP ERP 6.0 / NW7.01), podreís utilizar la Badi ME_CHANGE_OUTTAB_CUS donde podremos incluir este requerimiento.

Para poder hacer efectivo este cambio, tendremos que trabajar en los informes de pedidos con el alcance de lista en modo “ALV”. Los pasos a seguir utilizando esta alternativa serían los siguientes:

1. Incluir los campos adicionales en las estructuras correspondientes.

La estructura a modificar para incluir los campos adicionales será la MEREP_OUTTAB_PURCHDOC. Esta estructura corresponde a la vista “Lista básica” de los documentos de compras.

Tendremos otras estructuras similares para incluir campos adicionales en las otras vistas disponibles en estos informes:

  • MEREP_OUTTAB_SCHEDLINES: vista Repartos.
  • MEREP_OUTTAB_ACCOUNTING: vista Imputación.

En nuestro ejemplo, trabajaremos  con la “Lista básica” y por tanto modificaremos la estructura MEREP_OUTTAB_PURCHDOC utilizando la transacción SE11.

me2l_1Para incluir los campos, añadiremos una estructura Append siguiendo las instrucciones que vemos en la imagen. A continuación incluiremos los campos de la estructura append (recomendable que empiezen por ZZ) . En nuestro ejemplo, hemos incluidos tres campos donde mostraremos el usuario que ha creado un pedido, la fecha y hora de creación (podíamos haber incluido otras muchas cosas como información de liberación, información adicional de la cabecera o posiciones relacionada con el proveedor, material, etc).

me2l_2Finalmente, desde la opción de menú Detalles –> Categoría de ampliación realizaremos la clasficación de la ampliación, indicadando “Ampliable de cualquier manera”. A continuación activaremos el objeto, que ya quedará listo para su posterior “llenado” utilizando la Badi.

Desde este momento, los campos ya aparecen disponibles en los informes de pedidos (ME2L, ME2M), aunque sin valor alguno.

2. Implementar la Badi con el código que llenará los valores de los campos incluidos.

Con las transaccion habitual (SE19), crearemos una implementación de la Badi ME_CHANGE_OUTTAB_CUS e incluiremos el código Abap para realizar el llenado de los campos añadidos en la estructura MEREP_OUTTAB_PURCHDOC (usaremos para ello el parametro CH_OUTTAB, que es la tabla accesible en la Badi donde estarán disponibles todos los campos mostrados en el informe).

En el caso de estar en una versión anterior de Sap, os recomiendo la lectura detallada del Blog de nuestros amigos de Saptechnical.com donde explican la forma de hacerlo utilizando Enhancement points. Podéis acceder al contenido en este enlace:

http://saptechnical.com/Tutorials/ExitsBADIs/ME2N/Index.htm

En esta segunda alternativa crearemos un enhacement point en el método BUILD_BASE_LIST que se encuentra en el include LMEREPD02 del programa SAPLMEREP (el que se llama desde los informes de pedidos).

En esa ampliación incluiremos el código que llenará con valor los campos incluidos en la estructura (que tendremos accesibles en la tabla RE_OUTTAB_PURCHDOC) y que se visualizaran con el valor correspondiente en los informes de pedidos.

En esta entrada del SCN teneís información adicional sobre este método:

http://scn.sap.com/community/erp/logistics-mm/blog/2014/12/12/add-the-field-user-name-in-various-purchasing-reports-output-alv-list

Espero que os sea de utilidad.

Publicado en Abap, Formacion, SAP MM | Etiquetado , , | 7 comentarios

Un poco de humor Sap para empezar 2014.


Todos conocemos la complejidad de un proyecto de implantación de Sap y los diferentes elementos que intervienen en él, donde incluso muchos componentes de las organizaciones son reacios a los cambios que puede implicar un proyecto de este tipo. Sap es realmente al principio un monstruo caro de implementar y costoso de digerir, donde también podemos encontrar proyectos fracasados después de inversiones muy grandes.

Siguiendo el tono humorístico que dejo nuestro amigo Oscar Arranz (@oarranzli) en su blog, con el genial artículo titulado “Chuck Norris facts vs SAP“, os dejo un vídeo realmente ingenioso donde habla del motivo real por el cual Hitler no gano la Segunda Guerra Mundial. No se le  ocurrió otra cosa que implantar Sap en el ejercito alemán, con el fatídico resultado que todos conocemos.

Y aquí la versión en Español, gracias a SIdV:

Espero que empecéis el año 2014 con buen pie y tengáis muchas cosas buenas, y sobre todo, mucho, mucho Sap. Y que vuestro proyecto de implantación o mantenimiento salga bastante mejor que el del video (incluyendo un Project Manager un poco más amigable).

Un saludo a todos.

Publicado en Humor | Etiquetado , | 2 comentarios

Los números de 2013


Los duendes de las estadísticas de WordPress.com prepararon un informe sobre el año 2013 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 410.000 veces en 2013. Si fuese una exposición en el Museo del Louvre, se precisarían alrededor de 18 días para que toda esa gente la visitase.

Haz click para ver el reporte completo.

Publicado en Opinion. | Deja un comentario

Truco 60. Protección de campos en el Maestro de Materiales (Fijación).


En un truco anterior hablamos de la posibilidad de proteger la modificación de determinados campos en el maestros de proveedores y clientes (ver entrada aquí). Si nos encontramos con la misma necesidad cuando hablamos del maestro de materiales (MM02) tenemos disponible la funcionalidad de “Fijación”.

Fijacion1

Básicamente, la funcionalidad consiste en definir un conjunto de campos del maestro de materiales susceptibles de fijación. Cuando el usuario autorizado realiza la fijación en un código de material concreto, los campos incluidos en la parametrización quedan bloqueados (grisados) y ningún usuario podrá realizar modificaciones sobre ellos (aunque si en el resto de campos del maestro de materiales).

Para la definición de los campos relevantes para fijación, accederemos a la transacción OMSFIX o bien a través de la ruta de parametrización Logística en general –> Maestro de Materiales –> Selección de Campos –> Especificar campos relevantes para fijación.

Fijacion2Los campos los habremos previamente localizado en la transacción MM02, con la opción habitual (F1 situados encima del campo, botón Información Técnica). Los campos que queramos incluir como “fijables” los marcaremos en la parametrización.

A continuación, accederemos a la modificación de un material cualquiera que queramos proteger, utilizando la transacción MM02. Al pulsar el botón de “Fijar material”, como podéis ver en la imagen siguiente, nos aparecerá un popup con la lista de campos que se fijaran y protegerán en el material.

fijacion3Aceptaremos y grabaremos las modificaciones en el material, que quedará fijado. El sistema nos avisa de las repercusiones de fijar un material (y aunque avisa que el cambio es irreversible, no es cierto, si podremos eliminar a posteriori la fijación).

Si volvemos a entrar a modificar el mismo material, podremos ver que los campos indicados en la parametrización aparecen en gris y no son modificables, lo que nos permitirá proteger determinados campos críticos o cuyo mantenimiento solo deba quedar en manos de usuarios muy concretos. Ademas, al lado de la descripción del material aparece el icono del Candado que nos indica que un material se encuentra Fijado.

fijacion4

IMPORTANTE: para poder crear o eliminar la fijación de un material, deberemos de disponer del objeto de autorización M_MATE_MAF. En este objeto tenemos la posibilidad de indicar dos códigos de actividad para los que pueden estar autorizados los usuarios:

fijacion5

  • 16 Ejecutar: nos permite realizar la fijación de campos en un material.
  • 51 Inicializar: nos permite eliminar la fijación de campos en un material.

Teniendo en cuenta estas dos actividades, podríamos montar un escenario en el que la mayoría de usuarios no tendrían en su perfil de autorizaciones este objeto, de forma que ellos nunca podría fijar/desfijar un material para modificaciones.

Por otro lado, los “administradores” o “key-users” del maestro de materiales si tendrían la autorización. Ellos indicarían en los campos críticos los valores correctos y a continuación fijarían los materiales para que nadie pudiera modificar esos valores. Esos valores quedarían protegidos hasta que ellos mismos eliminasen la fijación para indicar otros valores según las necesidades concretas y volver a fijar el material posteriormente para volver a protegerlo.

Una funcionalidad sencilla de implementar, y que nos puede dar juego para determinados requerimientos en un cliente o proyecto. Espero que os sea de utilidad.

Publicado en Autorizaciones, Formacion, SAP MM | Etiquetado , , , | 6 comentarios

Truco 59. Analizando la clasificación en nuestras estrategias de liberación en Compras.


En el blog hemos hablado en muchas ocasiones de temas relacionados con las estrategias de liberación en los documentos de compras:

Hoy os voy a comentar una transacciones muy utiles del sistema de clases que he conocido gracias a mis alumnas Karen y Vanessa del Curso SAP MM Gestión de Materiales que estoy impartiendo y que acabamos en unas semanas.

Recordando la configuración de las estrategias de liberación, uno de los elementos clave en ellas es la definición de los valores de características en la clase utilizada en la parametrización de la liberación.

estrategias liberacionLos valores de clasificación son el elemento fundamental que se revisa cuando se crean/modifican los pedidos o el resto de documentos de compras (Pedidos Abiertos, Ofertas, Solpeds) y que produce que una estrategia se “dispare” o active para un documento si cumplen las condiciones indicadas.

Podemos acceder a la parametrización en la ruta Gestión de materiales –> Compras –> Pedido –> Procedimiento de liberación para pedidos –> Especificar procedimiento  liberacion p. pedidos.

La gestión de la parametrización se complica cuando tenemos un sistema con muchas estrategias y se hace difícil controlar los valores definidos y entender como el sistema asigna las diferentes estrategias según los valores existentes o realizar la modificación de una forma sencilla y rápida.

Para hacer esto, tanto el análisis de los valores de clasificación definidos en el sistema como para su modificación, disponemos de varias transacciones que nos permiten:

- CL30N/CL31: nos permite buscar las estrategias de liberación utilizando los valores de la clasificación indicados en ellas dentro de las características. En los resultados de la búsqueda se puede ver de forma masiva todos los valores de característica de las estrategias de liberación que cumplan las condiciones, lo que nos permite disponer de una herramienta donde visualizar lo que realmente tenemos definido en nuestro sistema de una forma global.
CL30N- CL20N: nos permite realizar la modificación individual de los valores de clasificación sin necesidad de pasar por todos los puntos de parametrización. Desde esta transacción podemos ver y modificar los valores de clasificación de una estrategia de liberación individual.
CL20N- CL24N: nos permite mostrar todas las estrategias de liberación asignada a una clase e ir viendo los valores de clasificación para cada una de ellas de una forma bastante ágil, pudiendo realizar la modificación también de estos.
CL24N- CT10: nos permite mostrar un índice de las características creadas en nuestra sistema, así como sus datos de configuración o la lista de valores permitidos en el caso de que dispongamos de ellos.
CT10- CT12: referencia de utilización de una característica.

Son transacciones que nos permiten facilitar la tarea de creación y mantenimiento de nuestras estrategias y sus valores de clasificación.

NOTA: como recordatorio, mencionar que la definición de las características se realiza desde la transacción CT04 y la de las clases asociadas a la liberación se realiza desde la transacción CL02 (siempre con categoría de clase 032). Recordar igualmente que solo podemos tener una clase definida por tipo de liberación (1= Solicitud de Pedido, 2= Documentos de compras (Pedido, Ofertas, Pedidos Abiertos, Planes de Entregas y 3=Hojas de Entrada de Servicios), lo que es una restricción y nos obliga a pensar muy bien las características a definir dentro de cada clase para poder tratar todos los posibles casos que se den en nuestra organización en lo referente a la liberación de documentos de compras.

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

Truco 58. Información de liberación en Pedidos de Compra.


Cuando trabajamos con estrategias de liberación en Compras (por ejemplo, en los Pedidos), no tenemos una herramienta estándar que nos permita obtener de forma masiva la información de las diferentes operaciones de liberación realizadas sobre un documento.

Liberacion01En la pestaña Estrategia Liberación del documento podemos ver la situación actual (Grupo de liberación, Estrategia de liberación aplicada, Indicador de liberación, Aprobadores y si han aprobado o no).

Igualmente, desde el historial de modificaciones del documento podemos ver las diferentes modificaciones que se han realizado en el documento.

Liberacion02Pero siempre de un documento en concreto, y no de una forma masiva.

Lo ideal sería disponer de una herramienta que nos mostrará la información completa de varios documentos a la vez. Nos puede ser útil para tareas de revisión, auditorias, etc. Para esta tarea, os dejo el código fuente a un desarrollo Abap que nos permite realizar esta tarea.

Liberacion03En este desarrollo leemos de las tablas de pedidos (EKKO para la cabecera y EKPO para las posiciones). Además, leemos del historial de modificaciones de los documentos, utilizando la información registrada en las tablas CDHDR y CDPOS, tomando los valores que son relevantes para la liberación.

En principio, solo se lee información relacionada con la liberación, aunque os podría servir de modelo para sacar cualquier otra información que este presente en el documento o para la que haya podido haber modificaciones (también nos puede servir como modelo para un desarrollo de análisis de modificaciones en los pedidos de compra).

Informe Liberacion PedidoPodemos observar los resultados del informe con un pedido concreto. En Rojo podemos ver los diferentes indicadores de liberación por los que ha pasado el pedido, el azul como se ha ido modificando el status de tratamiento del pedido y en amarillo que usuario y en que momento (fecha y hora) fue el que realizo la liberación para llegar a ese nuevo status.

Podéis descargar el desarrollo en este link. Espero que os sea de utilidad.

Nota: es requisito crear la estructura ZMMY_PURCHASEMODIF, como se detalla dentro del código del programa (allí están los detalles de los campos a incluir). Igualmente, en el código fuente se detallan los valores de los elementos de texto (Textos de selección y Símbolos de texto) necesarios también para ejecutar el programa correctamente.

TIP: como truco relacionado, y gracias a Oscar Arranz, hemos conocido la transacción RSSCD100 o la RSSCD150 que nos permiten acceder masivamente al historial de modificaciones de los diferentes objetos de Sap. Para la parte de compras, con el objeto EINKBELEG podemos ver el historial de documentos de compra (Pedidos, Ofertas, Pedidos abiertos, etc). Con el objeto BANF a las solicitudes de pedido. Nos puede valer como una opción para sacar las modificaciones de los documentos sin necesidad de montar nuestro propio desarrollo. Igualmente lo podemos utilizar para acceder al log de modificaciones de otros objetos (clave MATERIAL para listar modificaciones en el maestro de materiales; clave KRED maestro de proveedores, etc).

Publicado en Abap, SAP MM | Etiquetado , , , , , , , | 5 comentarios

Truco 57. Reducción manual en factura de Compras (MIRO).


Hoy vamos a ver un sencillo truco para el registro de facturas, que realizaremos utilizando la transacción MIRO. En determinadas ocasiones, cuando recibimos la factura de un proveedor, los importes de la factura no cuadran con el pedido debido a cualquier tipo de incidencia, normalmente en el precio de facturación aplicado.

En condiciones normales, registraríamos la factura con esos importes incorrectos y posteriormente, cuando se recibiera la correspondiente factura rectificativa, la registraríamos en el sistema utilizando la actividad Cargo/Descargo posterior (o Abono si hubiera alguna variación en las cantidades).

Esquema reduccion manual

Sap nos ofrece una alternativa para estos casos. Si estamos seguros que las diferencias son atribuibles al proveedor (o incluso ya nos ha mandado la correspondiente corrección), podemos utilizar un procedimiento de registro de factura especial, llamado Reducción de factura manual, que nos permite registrar en un único movimiento de la MIRO la factura original y el correspondiente Cargo/Descargo de corrección en el momento de contabilizar la factura. De esta forma se contabilizarán en la cuenta del proveedor dos partidas individuales en el mismo proceso.

Vamos a ver un ejemplo con esta casuística:

  • Factura esperada:  1210 Euros (210 Euros IVA), partiendo de un neto de 1000.
  • Factura recibida: 1694 Euros (294 Euros IVA), partiendo de un neto de 1400.

El procedimiento para registrar la factura utilizando la Reducción de factura manual sería el siguiente:

1. Procedemos al registro de la factura utilizando la transacción MIRO. Tendremos que seleccionar la variante de visualización “Reducción de la factura” (tal y como veis en la imagen en rojo).

Reduccion_factura1

A continuación introduciremos en la cabecera de factura el importe proporcionado por el proveedor en su documento (Factura recibida, en naranja en la imagen). A nivel de posición, una vez indicado el pedido que estamos facturando, no modificaremos nada de los importes propuestos por el sistema (en azul).

2. A nivel de posición buscaremos el campo “Ind.Corr”, indicador de corrección, seleccionando el valor “2 Error proveedor: Reducir factura”.

Reduccion_factura2

3. Al seleccionar el valor anterior, nos aparecerán abiertos a nivel de posición dos campos nuevos: “Imp. factura según proveedor” e “Ctd.factura según proveedor”. En estos campos indicaremos los valores netos de la posición indicados por el proveedor en su factura.

Reduccion_factura3

Ya solo nos quedará contabilizar. Podemos realizar una simulación de la factura antes para comprobar que todo se ha generado según lo esperado.

Reduccion_factura4

Efectivamente, se genera el movimiento de la factura con los importes indicados por el proveedor (en verde) y además la información del abono que le estamos endosando (en rojo). Al contabilizar, apareceran asociadas con esta factura dos partidas individuales para el proveedor, que podremos consultar con la transacción FLB1N.

NOTA: este tip corresponde a la materia de estudio del curso Sap MM Gestión de materiales que actualmente estamos impartiendo. Espero que os sea de utilidad el truco.

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

Manuales de LSMW.


Comparto con vosotros algunos enlaces interesantes sobre la herramienta LSMW. Como ya sabeís, Sap nos proporciona esta herramienta para los procesos de cargas iniciales de datos en un proyecto de implantación de Sap, aunque se puede utilizar también para migración de datos, interfases con otros sistemas, etc.

La herramienta nos permite utilizar varías técnicas para la carga de datos, como la tradicional del Batch Input, Direct Input, Bapis o Idocs, utilizando un procedimiento guiado donde Sap nos va marcando todos los pasos necesarios en cada metodo para realizar los procesos de carga de datos.

En su día, vimos un ejemplo práctico de utilización de la herramienta LSMW para realizar la carga del maestro del proveedores a partir de un fichero de texto:

https://saptricks.wordpress.com/2011/02/27/utilizando-lsmw-legacy-para-carga-el-maestro-de-proveedores/

En la siguiente entrada en scribd teneis un tutorial de la herramienta:

El documento de la presentación es accesible en este link 55577068-Step-by-Step-Lsmw-Tutorial[1]

Páginas de la SCN de Sap donde se habla sobre la herramienta LSMW:

http://wiki.sdn.sap.com/wiki/display/ABAP/LSMW

http://scn.sap.com/docs/DOC-26159

Otros Tutoriales con ejemplos sobre LSMW:

http://blogdefloren.files.wordpress.com/2009/03/manual-lsmw-blogdefloren.pdf

http://www.sap-topjobs.com/LSMW.pdf

http://de.slideshare.net/arun_bala1/sap-sd-lsmw-legacy-system-migrationworkbench

http://www.slashdocs.com/ntpsru/lsmw-steps.html

Vídeos sobre la herramienta:

Espero que os sea de utilidad todo este material. Nos vemos a la vuelta de mi vacaciones a mitad de septiembre.

Publicado en Formacion, Sap Basis | Etiquetado | 1 comentario

Truco 56.Costes indirectos planificados en compras que no afectan a la cuenta de existencias.


Este es un tema sobre el que he recibido múltiples consultas en el blog. En la configuración estándar de las clases de condición para los costes indirectos planificados de adquisición en los procesos de compra del Modulo MM (por ejemplo, las condiciones para gastos de transporte como FRA1, FRA2, FRB1, FRB1, FRC1, FRC2; gastos de aduana, etc), estos costes se añaden como más valor en la cuenta de existencias de los materiales.

Costes_transporte1

Esto esta bien, pues nos permite incluir en la valoración de los materiales aquellos elementos que no son solamente el precio de la compra, y podemos incluir otros importes provenientes de gastos de transporte, tasas, aduanas, gastos de seguros, etc.

Pero en algunos tipos de negocio, todos estos costes no se han de considerar como valor de las existencias (debido a que los gastos serán reembolsables, por temas legales específicos de algún país o por criterios contables). En este caso, estos gastos tendrán que ser contabilizados en una cuenta contable diferente para poder realizar otro tipo de tratamiento.

Para solucionar este problema, hemos de crear nuevas clases de condición, modificando los parámetros de control de ellas para obtener el comportamiento deseado del sistema. Los pasos son los siguientes:

1. Crear una nueva clase de condición, como copia de las estándar (por ejemplo FRA1, FRB1, FRC1, etc), desde la transacción M/06 o ruta de customizing Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar clases de condición –> Definir clase de condición.

Costes_transporte2

Importante: indicar en tipo de condición el valor blanco y y en el signo el valor X Negativo.

2. Creación de una nueva operación para la determinación de cuentas: desde la vista V_T687, aplicación “M” Compras (transacción SM31) o bien desde la ruta Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar clave de operación –> Clave de operación (también accesible desde la transacción OLME).

Costes_transporte3

3. Asignar la nueva clase de condición al esquema de cálculo: con la transacción M/08 o la ruta de customizing Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar esquema de cálculo. La incluiremos en la misma sección del esquema de cálculo que utilicemos donde están el resto de condiciones de costes indirectos planificados (fletes).

Costes_transporte4

Importante: en la clave de operación de la clase de condición (columna Delim), asignar la nueva operación creada en el paso anterior (en este caso, la ZR1).

4. Configuración de la determinación de cuentas para la nueva operación: con la transacción OBYC, realizaremos la asignación de cuentas para la nueva clave de operación. Aquí indicaremos la cuenta contable diferente donde queremos llevar los gastos de transporte.

Cuentas

Importante: antes de indicar las cuentas, configurar las normas (según los criterios que queramos utilizar para la determinación de la cuenta: agrupador de áreas de valoración, categorias de valoracion, D/H, etc). Igualmente, definir las claves de contabilización que se utilizarán para los asientos (40/50).

En principio, con esta configuración todo esta preparado para que el sistema se comporte de la forma deseada por nosotros. Vamos a ver un ejemplo de un pedido de compras utilizando esta clase de condición para verificar que la parametrización ha sido correcta.

Costes_transporte6

En el nuevo pedido utilizamos la clase de condición creada (ZFR1) y la clase de condición original (FRA1). Con la combinación de las dos vamos a conseguir realizar el juego contable deseado.

NOTA: SE HAN DE INTRODUCIR LAS DOS CONDICIONES (HACER EL JUEGO CON LAS DOS) PARA CONSEGUIR EL RESULTADO DESEADO. NO BASTA CON UTILIZAR SOLO LA CLASE DE CONDICION CREADA. ESTO ES TANTO VALIDO PARA COMPRAS A STOCK COMO PARA COMPRAS IMPUTADAS. EN ESTE ULTIMO CASO, EL FLETE SE LLEVARA A OTRA CUENTA DIFERENTE DE LA DEL GASTO DE MATERIAL.

A continuación, realizamos la entrada de mercancía del pedido. Podemos observar el apunte contable que se ha generado en el sistema al realizar la EM con la transacción MIGO:

Costes_transporte7

Podemos observar que en la cuenta de existencias (cuenta 301000) no hay ningún reflejo del gasto de transporte. Por otro lado, en la cuenta que hemos parametrizado para la clave de operación ZR1, nos aparece el importe del gasto (en rojo). En la parte marcada en naranja en el asiento, podemos ver las cuentas de la clave de operación FRE (generadas por el juego de las clases de condición FRA1 y ZFR1) se compensan entre si. Por otro lado, la cuenta de facturas pendientes de recibir para los portes refleja el importe de estos.

Cuando recibamos la factura, el asiento generado será el siguiente (en este caso hemos supuesto que el proveedor del transporte es el mismo que el de la mercancía). En caso contrario, haremos la contabilización en dos movimientos pero con el mismo resultado contable. Su aspecto es:

Costes_transporte8

Se compensan las cuentas de EM/RM de la mercancía y del transporte, y se lleva la deuda a la cuenta del proveedor.

Conclusión.

Con este método hemos conseguido nuestro propósito de separar los costes indirectos planificados de adquisición de la valoración del material, contabilizándolos en una cuenta contable diferente, separándolo del importe de las cuentas de existencias del material.

La alternativa no es un método directo y nos obliga a indicar las dos clases de condición en el pedido (siempre habrá que hacer ese juego). Pero el resultado contable es el deseado y nos puede valer para aquellas excepciones donde tenga que realizarse esta separación.

Bibliografía: entrada original publicada por Raja Ramasamy en el SCN de Sap http://wiki.sdn.sap.com/wiki/display/ERPLO/Posting+planned+delivery+cost+to+Non-inventory+account

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