Evaluación de modificaciones de condiciones 

Utilización

Esta función permite que el sistema reconozca modificaciones de condiciones y ponga a disposición las aplicaciones relacionadas con la información relevante.

Integración

Hay dos procedimientos para evaluar las modificaciones de condiciones:

·        El procedimiento ofrecido en la versión estándar.

·        Un procedimiento alternativo (a partir de R/3 4.6A).

Las ventajas del procedimiento alternativo para el proceso de salida a TPV son:

·        En vez de leer los punteros de modificación de condiciones, el sistema lee únicamente un pool de trabajo que requiere menos recursos del sistema.

·        El sistema evalúa únicamente modificaciones de condiciones relevantes para TPV.

·        El programa de análisis lee los punteros de modificación de condiciones para todas las aplicaciones que se relacionan una vez. Esto no tiene que realizarse para cada aplicación por separado. A partir del release 4.7, ya no se leen los punteros de modificación de condiciones; el sistema actualiza únicamente el pool de trabajo tan pronto como se crean las modificaciones de condiciones.

Características

El procedimiento suministrado en la versión estándar funciona de la manera siguiente:

·        En la capa ALE, se activa la función para crear punteros de modificación de condiciones para salida a TPV (transacción BD52 para la clase de mensaje WP_PLU, entradas para el objeto de documento de modificación COND_A). No puede limitar el procesamiento a determinadas clases de condición relevantes para TPV. El sistema crea un puntero de modificación para cada modificación de condiciones. El análisis de punteros de modificación de condiciones en la salida a TPV filtra el puntero de modificación relevante para TPV. Este procedimiento reduce el rendimiento efectivo del sistema.

El procedimiento alternativo utilizaba la nueva función de índice de documento de condición R/3:

·        En este procedimiento, el sistema crea también un puntero de modificación para cada modificación de condiciones. El programa de análisis evalúa sus modificaciones una vez para todas las aplicaciones que utilizan este procedimiento. El programa de análisis crea un pool de trabajo para cada aplicación; el pool de trabajo debe contener modificaciones de condición relevantes. En el Customizing, puede realizar parametrizaciones muy precisas para cada aplicación (hasta el nombre de la tabla de condiciones, por ejemplo, A071) cuyas modificaciones de condiciones son relevantes. A partir del release 4.7, el programa de análisis se sustituye por una actualización automática del pool de trabajo cuando se hacen modificaciones en una condición.

Actividades

Si quiere evaluar modificaciones de condiciones utilizando el procedimiento alternativo, utilice el procedimiento siguiente:

Procedimiento para R/3 4.6A a R/3 4.6C

...

       1.      Si ha definido sus propias clases y tablas de condiciones relevantes para TPV, tiene que alterar consecuentemente las parametrizaciones del Customizing para su índice de documento de condición. Utilice la transacción OWS2 para esto. Se han introducido ya las entradas para clases de condición y las tablas relevantes para TPV suministradas en la versión estándar. Además, necesita introducir la clase de condición relevante para TPV y los números de las tablas de condiciones afectadas desde la secuencia de acceso que se refiere a las clases de condición. Haga esto para todas las clases de condición que ha definido y todas las clases de condición utilizadas en los grupos de clases de condiciones de TPV. No hay ninguna secuencia fija para estas entradas.

       2.      Reorganice la salida a TPV. Inicie el programa RWDPOSRS para la salida a TPV.

       3.      Asegúrese de que la clase de mensaje CONDBI en la capa ALE está activada.

       4.      Asegúrese de que el programa RMEBEIN4 está terminado antes de iniciar el mensaje de modificación. Crea el pool de trabajo para la salida a TPV. Se debe terminar este programa antes de que una de las aplicaciones enlazadas comience. Por lo tanto, planifique el programa para ser ejecutado en el proceso fondo como un mensaje de modificación a intervalos regulares.
En la pantalla de selección, seleccione todas las clases de documento y el identificador Marcar punteros de modificación procesados para la reorganización. Planifique el job de fondo que inicia el mensaje de modificación para que no comience hasta después de que el programa RMEBEIN4 haya comenzado por primera vez (independiente del status). Así no encontrará ninguna dificultad con la planificación de intervalos periódicos para ejecutar este job.

       5.      Para evitar perder cualquier modificación de condiciones cuando modifica el procedimiento de análisis, espere hasta que el mensaje de modificación siguiente de todas las tiendas que lo requieren esté concluido y haya recibido el status OK.

       6.      Finalmente, asegúrese de que se lee ninguno de los punteros de modificación de condiciones normales mientras se ejecuta el mensaje de modificación. Ya no se requieren, ya que se sustituyen por el pool de trabajo. Para esto utilice la transacción BD52 para clase de mensaje WP_PLU y borre las entradas siguientes:

¡        Objeto COND_A, nombre de tabla KONDAT, campo DATAB

¡        Objeto COND_A, nombre de tabla KONDAT, campo DATBI

¡        Objeto COND_A, nombre de tabla KONDAT, campo KEY

Procedimiento a partir de R/3 4.7

Se describe también el procedimiento siguiente en la nota SAP 519685.

...

       1.      El mismo que el punto 1 de la sección anterior.

       2.      El mismo que el punto 2 de la sección anterior.

       3.      El mismo que el punto 3 de la sección anterior.

       4.      Actualice los punteros de modificación obsoletos (véase Migración de punteros de modificación)

       5.      Verifique las parametrizaciones del Customizing del índice de documento de condición. Inicie la vista de actualización (transacción SM30) para la tabla V_T6I2A. Se deberían haber hecho ya las entradas siguientes:

¡        Tipo de documento 55, tabla de condiciones KONDAT, nombre de campo DATAB

¡        Tipo de documento 55, tabla de condiciones KONDAT, nombre de campo DATBI

¡        Tipo de documento 55, tabla de condiciones KONDAT, nombre de campo KEY

¡        Tipo de documento 55, tabla de condiciones KONP, nombre de campo KEY

¡        Tipo de documento 55, tabla de condiciones KONP, nombre de campo KBETR

¡        Tipo de documento 55, tabla de condiciones KONM, nombre de campo KEY

¡        Tipo de documento 55, tabla de condiciones KONM, nombre de campo KBETR

¡        Tipo de documento 55, tabla de condiciones KONW, nombre de campo KEY

¡        Tipo de documento 55, tabla de condiciones KONW, nombre de campo KBETR

 Si estas entradas ya no están en las parametrizaciones del Customizing, introdúzcalas otra vez.

       6.      Inicie el programa RMEBEIN4 una vez únicamente. La parametrización es la misma que en el punto 4 de la sección anterior. Se debería ejecutar este programa cuando no se realicen más cambios en el sistema (preferentemente por la noche).

       7.      Tan pronto como el programa haya acabado y antes de que se hayan hecho los cambios en el sistema, navegue otra vez al índice de documento de condición en el Customizing. Inicie la vista de actualización otra vez (transacción SM30) para la tabla V_T6I2 y defina el identificador de entrada directa para el tipo de documento 55 de manera que se haga la entrada siguiente:

¡        Tipo de documento 55, DirectEntryID  <seleccionado>, ID de migración <seleccionado>

       8.      Finalmente, concluya las instrucciones en el punto 6 de la sección anterior.

Resultado

El sistema evalúa únicamente el pool de trabajo del mensaje de modificación siguiente en vez de los punteros de modificación de condiciones. En vez de realizar una conversión, puede ejecutar una inicialización inmediatamente. En este caso, solo tiene que realizar las instrucciones en los puntos 1, 3, 4 y 6 (R/3 4.6A a R/3 4.6C) o los puntos 1, 5 y 7 (a partir de R/3 4.7).