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 , , , , , | 16 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 , , , , , , , , , , | 1 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 , , | 9 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 , , | 6 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 , , , , | 16 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