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 , , , , , | 4 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 , , | 3 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

Truco 63. Autorizacion de funciones en compras con el parametro EFB (OMET).


En una entrada antigua del blog hicimos referencia a algunos trucos que podíamos utilizar en el módulo MM para personalizar, mediante parámetros de usuario, el comportamiento del sistema.

Hoy vamos a ampliar esa información y nos vamos a centrar en el parametro EFB, el cual se configura a través de la transacción OMET y nos permite determinar autorizaciones por usuario para la realización o no de determinadas funciones en los procesos de compra.

La configuración es bien sencilla. En primer lugar, se define con la transacción OMET una etiqueta con sus correspondientes funciones autorizadas (que veremos en detalle a continuación).

omet2En segundo lugar, para los usuarios que queremos que se apliquen dichas autorizaciones, accederemos a la transacción SU3 e indicaremos en sus parámetros el valor EFB con la etiqueta definida en la configuración. A partir de ese momento, la configuración de autorizaciones será relevante para el usuario y el sistema solo le permitirá realizar las funciones a las que haya sido autorizado.

omet01Nota: si el parametro EFB no ha sido asignado, no habrá ninguna restricción para el usuario. La asignación también se podrá realizar con la SU01 o de forma masiva con la SU10.

Las acciones a las que podemos autorizar o no al usuario mediante esta configuración son las siguientes:

omet3

  • Opción “Visualizar condiciones”: permite que el usuario tenga visible la pestaña Condiciones. Si la opción esta desmarcada, dicha pestaña desaparecerá (nos permite permitir a determinados usuarios consultar documentos de compras sin ver el detalle de los datos de condiciones de precio).
  • Opción “Indicar condiciones”: permite que el usuario pueda introducir condición de precio en los documentos, así como introducir clase de condiciones adicional (por ejemplo, gastos de transporte, descuentos, etc) en los documentos de compra. Si la opción esta desmarcada, el usuario no tendrá acceso a realizar estas funciones (la pestaña de condiciones aparecerá a nivel de posición, pero no podrá indicar ni modificar ningún valor).
  • Opción “Sin Material”: nos permite crear posiciones en los documentos de compra sin indicar un material (solo el texto de la descripción). Si la opción no esta marcada, el usuario recibirá un mensaje de error como el que vemos en la imagen siguiente.

omet4

  • Opción “Transfer.precio pedido”: al crear una solicitud de pedido, en la pestaña Valoración a nivel de posición tenemos disponible la opción para configurar como queremos que se traspase el valor que indicamos en la solped al pedido (sin traspaso, como precio bruto o como precio neto). Esta opción aparecerá disponible si tenemos marcado el parámetro “Transfer precio pedido”. Si se desmarca, la opción no será visible en la ME51N/ME52N.

omet5

  • Opciones “SelecCpo” y “CtrlSelCampLib”: podemos indicar formatos de imagen para los documentos de compra o para las solicitudes de pedido. En estos formatos de imagen personalizaremos la configuración de los campos para el usuario (por ejemplo, determinados campos obligatorios, opcionales, solo visibles u ocultos). Con esta opción podremos personalizar, solo para determinados usuarios, el comportamiento de las transacciones en lo referente a los campos en las transacciones. Esta opción nos puede dar mucha potencia.

En la sección “Objetos de referencia posibles” indicamos los objetos de referencia que se pueden utilizar cuando estemos creando un pedido de compra. Por ejemplo, sino queremos que se pueda crear un pedido sin referencia a otro documento (Solped, Pedido Abierto, etc), desmarcaremos este flag para no permitir la función.

Las opciones de referencia disponibles, ademas de sin referencia, son: Pedido Abierto (incluyendo según el tipo de este, por Cantidad o Valor), Solicitud de Pedido, Pedido, Petición de Oferta sin Oferta, Oferta, Registro Info sin Oferta (que no se haya generado desde una oferta).

En la sección “Asignación manual fuentes de aprovisionamiento” podemos indicar que fuentes de aprovisionamiento se pueden indicar de forma manual cuando estemos creando una solicitud de pedido.

Con todas estas opciones podemos modificar de forma relevante la forma de trabajar del usuario con los documentos de compra, y seguramente poder cubrir algunos requerimientos que pueden surgir en un proyecto de implantación o mantenimiento del modulo MM de Sap.

Para terminar, os dejo el vídeo con los pasos de la configuración, con el que estrenamos una nueva forma de compartir conocimiento en el blog. Espero que os sea de utilidad.

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

SAP HR: adios a los cluster de nómina.


Gracias a Antonio de Ancos, he conocido que los “famosos” clusters del módulo de HR van a pasar a mejor vida. Ya era hora, direís muchos de vosotros. En mi opinión, Sap lo podía haber hecho hace mucho tiempo (sobre todo cuando me tocaba a mi lidiar con ese modulo).

Como la información es de gran interés, os reproduzco integro el articulo de Antonio (os recomiendo que lo sigáis en Twitter, en su cuenta @aancos) o en su blog http://aancos.com/, donde habla especialmente de temas relacionados con Sap HCM).

SAP HCM: adiós a los clusters

22/01/2014 por

Para los que empezamos en este mundo peleándonos con “bonitas” macros del tipo RP-IMP-C2-RE, (mucho antes de que existieran cosas como HR_GET_PAYROLL_RESULTS, GET PAYROLL o los infotipos de resultados de nómina), para leer resultados de nómina esta noticia nos suena un poco a ciencia ficción:

How do SAP HCM customers benefit from declustering Payroll and Time Management on SAP HANA?

Se acabó eso de que cuando alguien pedía un listado de nómina y le decías que ibas a tardar 2 semanas, para justificarlo decías “porque como los datos están en un cluster“… que ni tu sabías lo que era un cluster, pero evidentemente tu jefe menos… y mientras, al lado, el programador de SD te decía: “tío, pero haz un SELECT”… y tu le decías, “no puedo, los datos están en un cluster“… bueno, pues con esto se acabó el “cuento chino” del cluster ;-)

Se suponía que los datos de nómina/tiempos se almacenaban en clusters, por temas de seguridad, para que la información no estuviera accesible fácilmente, etc… pero ahora ya no parece ser tan importante y con la “declusterización” todos los datos pasan a estar disponibles en “tablas transparentes de las de toda la vida”.

¿Por qué SAP da este paso ahora? A mí me da que “algo” tiene que ver que HANA no se debe llevar muy bien con los clusters y así vamos preparando el terreno… para lo que está por venir en un futuro cada vez más inmediato: SAP Business Suite powered by SAP HANA – Human Resources Fact Book

Por cierto, si queréis probar esto, lo tenéis disponible a partir del EhP4 SP13: HCM Declustering Tools

Y si queréis seguir leyendo del cluster, os recomiendo este artículo de los amigos de Oreka IT¿Cómo leer el clúster de nómina SAP? Eso sí, con tanta ayuda, a los “abaperos” se os ha acabado la excusa de “como lo está leyendo del cluster…” ;-)

Publicado en Abap, Sap HR | Etiquetado , | 3 comentarios

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 , , , | 4 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 Truco 61. Añadir campos adicionales en los informes de pedidos de Compras.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.

Espero que os sea de utilidad.

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