Pool de trabajo de varios niveles
Utilización
El pool de trabajo del Schedule Manager es un pool de trabajo de varios niveles. Este pool de trabajo es particularmente útil para las actividades de cierre del período.
¿Porqué el pool de trabajo es de varios niveles?
En releases anteriores, el proceso de cierre del período en el Sistema R/3 consistía en una serie de jobs de fondo. La secuencia de los pasos de procesamiento se ha establecido siguiendo el orden en el que se han llamado los jobs. Los objetos se han seleccionado por separado para cada job. A través de los criterios de selección introducidos, era posible especificar un alcance de selección unificado. Se ha tenido que volver a especificar el alcance de selección para cada paso de procesamiento (es decir, para cada función individual del cierre del período).
Al procesar un objeto no se han tenido en cuenta los errores aparecidos en pasos de procesamiento anteriores. Por esta razón, ha sido necesario verificar los objetos con errores después del cierre de un job. Si se producía algún error, se debía corregir y reinicializar el job para todo el alcance de selección. En algunas áreas (tales como el cierre del período en Controlling periódico del producto), ya era posible crear un pool de trabajo de un nivel para pasos de procesamiento individuales. Con este pool de trabajo de un nivel, se podían visualizar los objetos con errores en cada paso de procesamiento y se podían determinar sus causas. El paso de procesamiento se podía volver a realizar para el objeto tras la corrección del error. Este pool de trabajo no impedía el procesamiento de objetos con errores en el paso del procesamiento posterior (es decir, en el job posterior).
Ventajas del pool de trabajo de varios niveles
El pool de trabajo del Schedule Manager es un pool de trabajo de varios niveles. Esto significa que el pool de trabajo se genera para una secuencia de pasos de procesamiento, en vez de sólo para un paso de procesamiento. El pool de trabajo permite por lo tanto la ejecución eficaz de secuencias de pasos de procesamiento. Se pueden realizar procesos como el cierre del período con mucha más eficacia con un pool de trabajo de varios niveles.
El pool de trabajo de varios niveles tiene las ventajas siguientes:
Las secuencias de pasos de procesamiento (tales como el cierre del período) se pueden realizar más rápidamente que antes.
El procesamiento manual después de finalizar todos los jobs ya no es necesario. El procesamiento manual es únicamente necesario después de la ejecución de una secuencia de pasos de procesamiento que conste de varios jobs (por ejemplo, un cierre completo de un componente de aplicación).
Además, si aparecían errores de objetos en el pool de trabajo de un nivel, a menudo se debían repetir los pasos de procesamiento para todo el alcance de selección (y no solo para los objetos con errores). Con el pool de trabajo de varios niveles, los pasos de procesamiento se repiten únicamente para los objetos que tienen errores.
Disminuye el tiempo CPU porque los objetos se seleccionan únicamente una vez para cada secuencia de pasos de procesamiento, en vez de para cada paso de procesamiento. Se seleccionan los objetos antes de que se ejecute el primer paso de procesamiento. El pool de trabajo de varios niveles ofrece ventajas de rendimiento, sobre todo con estructuras complejas en las cuales se deben tener en cuenta las dependencias entre objetos (p. ej., las estructuras de proyecto complejas).
En general, los jobs los programan y controlan los miembros del equipo de proceso electrónico de datos. En muchos casos, estos empleados no son responsables de la corrección de errores visualizados en los logs de errores. El pool de trabajo de varios niveles permite informar directamente a los responsables de la corrección de errores. Esta notificación se efectúa con un mensaje de mail que se envía automáticamente mediante el
workflow.Integración
El pool de trabajo de varios niveles forma parte del Schedule Manager y se utiliza siempre con las otras funciones del Schedule Manager (véase Condiciones previas).
En la actualidad el pool de trabajo de varios niveles soporta las aplicaciones, funciones y objetos siguientes:
Contabilidad de objetos de coste: Órdenes de producción y colectores de costes del producto
Proceso |
Cierre del período para órdenes de producción y colectores de costes del producto |
Alcance de selección para objetos de procesamiento |
El cierre del período incluye órdenes de fabricación, órdenes de fabricación CO (órdenes de fabricación sin estructura cuantitativa), órdenes de procesamiento, colectores de costes del producto y órdenes QM. Con los co-productos, una parte del trabajo de cierre del período se lleva a cabo en las posiciones de las órdenes de producción. Es una condición previa que se cumplan los requisitos siguientes para estos objetos: No se asignan los objetos a una jerarquía de objetos de coste o bien se especifica en la clase de objeto de coste que las órdenes individuales de un material se procesan fuera de la jerarquía de objetos de coste (véase Controlling periódico del producto). La imputación se puede realizar directamente en los objetos. Esto significa que, con respecto a la selección de órdenes de producción, la imputación tiene lugar en las órdenes de producción y no en un colector de costes del producto. Los objetos no tienen el status DLFL (petición de borrado). Los colectores de costes del producto son objetos del subcomponente Controlling periódico del producto. Las órdenes de producción (incluidas las órdenes de producción sin estructura cuantitativa) son objetos del subcomponente Controlling periódico del producto. |
Paso de procesamiento |
Objetos |
Imputación modelo |
Cabecera de la orden (incluidos los colectores de costes del producto) |
Revaluación con tarifas reales |
Cabecera de la orden (incluidos los colectores de costes del producto) |
Gastos generales reales |
Cabecera de la orden (incluidos los colectores de costes del producto) |
Liquidación preliminar para co-productos, trabajo de repaso |
Liquidación preliminar para co-productos: Cabecera de la orden de órdenes de producción como objetos de procesamiento; posiciones de orden como receptores Liquidación preliminar de trabajo de repaso: Liquidación preliminar de órdenes colectivas (método de procesamiento antiguo sin movimiento de mercancías automático) |
Determinación WIP |
Órdenes de procesamiento y de producción o, en fabricación de subproductos, sus posiciones, así como órdenes de fabricación CO y colectores de costes del producto |
Determinación de desviaciones |
Órdenes de procesamiento y de producción o, en proceso de fabricación de co-productos, sus posiciones, así como órdenes de fabricación CO y colectores de costes del producto |
Liquidación |
Órdenes de procesamiento y de producción o, en proceso de fabricación de co-productos, sus posiciones, así como órdenes de fabricación CO y colectores de costes del producto |
Contabilidad de objetos de coste: Número ID de objeto de coste (nodos de objetos de coste en una jerarquía de objetos de coste y objetos de coste general)
Proceso |
Cierre del período para el número ID del objeto de coste |
Alcance de selección para objetos de procesamiento |
El cierre del período incluye: Nodos de objetos de coste de jerarquías de objetos de coste y objetos individuales asignados a la jerarquía de objetos de coste. Pueden ser los siguientes: Colectores de costes del producto, órdenes de producción, órdenes de fabricación sin estructura cuantitativa y (en caso necesario) posiciones de la orden de órdenes de producción (con proceso de fabricación de co-productos) para los que rigen las condiciones siguientes: La imputación se puede realizar directamente en los objetos. Esto significa que la imputación para órdenes de producción tiene lugar en la orden de producción y no en un colector de costes del producto. Los objetos no tienen el status DLFL (petición de borrado). Las jerarquías de objetos de coste forman parte del componente Controlling periódico del producto. Objetos de coste general Los objetos de coste general son objetos del componente Controlling para bienes inmateriales y prestaciones de servicios. |
Paso de procesamiento |
Objetos |
Imputación modelo |
Nodos de objetos de coste de jerarquías de objetos de coste o los objetos individuales asignados a la jerarquía de objetos de coste (colectores de costes del producto, órdenes de producción u órdenes de fabricación sin estructura cuantitativa); objetos de coste general |
Revaluación con tarifas reales |
Nodos de objetos de coste de jerarquías de objetos de coste o los objetos individuales asignados a la jerarquía de objetos de coste; |
Distribución de costes reales |
Nodos de objetos de coste de jerarquías de objetos de coste; los objetos individuales asignados a los nodos más bajos de objetos de coste son los receptores finales |
Gastos generales reales |
Dependiendo de las parametrizaciones del Customizing, los nodos de objetos de coste de jerarquías de objetos de coste o los objetos individuales asignados a la jerarquía de objetos de coste; objetos de coste general |
Liquidación preliminar para co-productos, trabajo de repaso |
Únicamente para órdenes asignadas a la jerarquía de objetos de coste: Liquidación preliminar para co-productos: Cabecera de órdenes de producción como objetos de procesamiento, posiciones de orden como receptores Liquidación preliminar de trabajo de repaso: |
Determinación WIP |
Los objetos individuales asignados a una jerarquía de objetos de coste; pero no: Posiciones de la orden en el proceso de fabricación de co-productos, órdenes de fabricación CO |
Determinación de desviaciones |
Dependiendo de las parametrizaciones del Customizing, los nodos de objetos de coste de jerarquías de objetos de coste o los objetos individuales asignados a la jerarquía de objetos de coste |
Liquidación |
Dependiendo de las parametrizaciones del Customizing, los nodos principales de una jerarquía de objetos de coste o todos los nodos de la jerarquía de objetos de coste; si es aplicable, todas las órdenes asignadas a la jerarquía de objetos de coste, y en el proceso de fabricación de co-productos las posiciones de las órdenes de producción; Todos los objetos de coste general |
Sistema de proyecto
Proceso |
Cierre del período para sistema de proyectos |
Alcance de selección para objetos de procesamiento |
Elementos PEP, grafos y órdenes |
Paso de procesamiento |
Objetos |
Generación de norma de liquidación |
Elementos PEP |
Imputación modelo |
Elementos PEP, grafos y órdenes |
Gastos generales reales |
Elementos PEP, grafos y órdenes |
Revaluación con tarifas reales |
Elementos PEP, grafos y órdenes |
Pronóstico de costes |
Grafos |
Cálculo de intereses |
Elementos PEP, grafos y órdenes |
Progreso del proyecto |
Elementos PEP, grafos y órdenes |
Determinación de resultados |
Elementos PEP y órdenes |
Órdenes recibidas |
Elementos PEP |
Liquidación |
Elementos PEP, grafos y órdenes |
Reporting |
Elementos PEP, grafos y órdenes |
Órdenes CO
Paso de procesamiento |
Cierre del período para órdenes CO |
Alcance de selección para objetos de procesamiento |
Órdenes CO, órdenes de mantenimiento |
Paso de procesamiento |
Objetos |
Imputación modelo |
Órdenes CO, órdenes de mantenimiento |
Revaluación con tarifas reales |
Órdenes CO, órdenes de mantenimiento |
Gastos generales reales |
Órdenes CO, órdenes de mantenimiento |
Cálculo de intereses |
Órdenes CO, órdenes de mantenimiento |
Determinación de resultados |
Órdenes CO, órdenes de mantenimiento |
Liquidación |
Órdenes CO, órdenes de mantenimiento |
Pedidos de cliente
Paso de procesamiento |
Cierre del período para pedidos de cliente |
Alcance de selección para objetos de procesamiento |
Posiciones de pedido de cliente que generan costes e ingresos |
Paso de procesamiento |
Objetos |
Imputación modelo |
Posiciones de pedido de cliente que generan costes e ingresos |
Revaluación con tarifas reales |
Posiciones de pedido de cliente que generan costes e ingresos |
Gastos generales reales |
Posiciones de pedido de cliente que generan costes e ingresos |
Determinación de resultados |
Posiciones de pedido de cliente que generan costes e ingresos |
Liquidación |
Posiciones de pedido de cliente que generan costes e ingresos |
Condiciones previas
Está trabajando con el Schedule Manager y está utilizando todas sus funciones.
Una condición previa para el uso de un pool de trabajo de varios niveles es que se procese un número constante de objetos (o, en ejecuciones posteriores, su subset) en una secuencia de pasos de procesamiento predefinida.
El set de selección de los objetos se determina mediante la aplicación seleccionada por el usuario (por ejemplo, Contabilidad de objetos de coste: Órdenes de producción y colectores de costes del producto) (véase más arriba), así como mediante cualquier entrada adicional que puede realizar durante la creación de variantes de informe (véase más abajo).
La secuencia de pasos de procesamiento se especifica en la definición de proceso.
Esto significa que se debe proceder como se indica a continuación:
Pase al
planificador del Schedule Manager.Desde el planificador, cree una
definición de proceso. En la definición de proceso especifique la secuencia de pasos de procesamiento (por ejemplo, una secuencia de cada una de las funciones del cierre del período para colectores de costes del producto). La creación de la definición de proceso se realiza a través del Workflow Builder.Seleccione las opciones de menú Detalles ® Tratar definición de proceso para acceder a la definición de proceso. Cuando crea la definición de proceso, debe:
Especificar la aplicación para la que se destina la definición de proceso (como por ejemplo, Contabilidad de objetos de coste: Órdenes de producción y colectores de costes del producto).
Asegurarse de que crea una definición de proceso con un pool de trabajo.
Aparecerá el Workflow Builder. Dependiendo de la aplicación seleccionada, el usuario recibirá un modelo SAP que podrá modificar para satisfacer sus necesidades.
Cree una tarea para cada paso de procesamiento en la definición de proceso. Tales tareas pueden ser, por ejemplo, informes para las funciones individuales del cierre del período o decisiones de usuario.
Para facilitar la actualización de la definición de proceso, el sistema le ofrece un modelo por defecto. Éste consta de una reserva-espacio de tarea al principio del proceso, así como de una reserva-espacio de tarea en el ciclo de control. Defina la reserva-espacio al principio del proceso antes del ciclo de control como una tarea de informe para seleccionar el pool de trabajo. Defina las funciones individuales del cierre del período como tareas en el ciclo control.
Para definir la marca de selección o una función individual (tal como el cálculo de recargos) como una tarea, fije el indicador Programa durante la creación de la tarea. A continuación, seleccione el informe de una lista de propuestas que desea incluir en la secuencia de procesamiento (por ejemplo, Recargo de gastos generales: Pool de trabajo de órdenes de producción).
Entonces cree una variante del informe para la ejecución del informe. Actualice los parámetros para la variante. En este caso se pueden especificar varios parámetros, por ejemplo, si se edita una lista detallada y si el procesamiento tiene lugar simultáneamente en varios servidores.
También se puede filtrar el alcance de selección del objeto a procesar mediante un perfil de selección.
Además, introduzca el período y el ejercicio.
Se puede utilizar siempre la misma definición de proceso si se utilizan variables de selección en vez de valores fijos para el período y el ejercicio cuando se actualizan las variantes del informe. En este caso, el sistema calcula el período y el ejercicio de las funciones individuales dinámicamente desde los valores actuales para estas variables cuando ejecuta la definición de proceso. Esto es únicamente posible cuando se utilizan variables de selección (llamadas variables TVARV) para los parámetros del período y del ejercicio. Cuando se crea la variante del informe se especifica que se está trabajando con variables de selección. Las variables de selección se actualizan introduciendo la transacción STVARV o iniciando la transacción mediante Detalles ® Opciones ® Variables selección en el menú del Schedule Manager y modificando las variables en el período y el ejercicio que deben procesarse. Esto permite utilizar la misma variante de job cada mes. Necesita únicamente actualizar la variable TVARV antes de ejecutar la variante de job.
Especifique una decisión de usuario si desea que se verifiquen los resultados del proceso anterior después de uno o de varios pasos de procesamiento. Después de la ejecución de los pasos de procesamiento anteriores, el sistema envía un mail automático al responsable de verificar los resultados (normalmente el controlador). Cuando cree la definición de proceso, especifique qué usuario recibe este mail.
Cuando se trabaja con el pool de trabajo de varios niveles, el sistema especifica siempre una decisión de usuario y un ciclo de control para la reintroducción en el procesamiento posterior como el último paso de la definición de proceso.
También se pueden insertar interacciones de usuario en otros nodos de la definición de proceso si se desean verificar los objetos procesados hasta un paso determinado antes de que continúe el procesamiento.
Si se autoriza (libera) la verificación de los objetos con errores, los objetos con errores se podrán procesar automáticamente más tarde.
Introduzca la definición de proceso como una tarea en el plan de tareas del Planificador.
Inicie la tarea (la definición de proceso) en el Planificador.
Controle los procesos y los jobs durante y después del procesamiento en el
monitor del Schedule Manager.Características
Funciones básicas del pool de trabajo de varios niveles
El pool de trabajo de varios niveles se crea para una secuencia de pasos de procesamiento completa.
Se determina el alcance de selección una vez y es válido para todos los pasos de procesamiento. El pool de trabajo abarca los objetos del alcance de selección para el cual el procesamiento en la secuencia de pasos de procesamiento actual es a la vez posible y necesario. Así, el alcance de selección iguala el alcance máximo del pool de trabajo. Se pueden especificar ciertas restricciones para pasos de procesamiento individuales en el alcance de selección. Estas restricciones suelen estar determinadas mediante perfiles de selección que se especifican cuando se crean variantes del informe.
Los pasos de procesamiento se realizan en un orden estrictamente definido en el control de procesos del planificador. Se actualiza un status de procesamiento para cada objeto y cada paso de procesamiento. El status de procesamiento indica si se permite continuar con el procesamiento del objeto.
Cada paso de procesamiento comprende únicamente los objetos para los cuales (basándose en el status de procesamiento del paso de procesamiento anterior) está permitido el procesamiento en este paso.
En cada paso de procesamiento se interpretan las dependencias entre objetos según la aplicación. Por esta razón, puede ser necesario incluir otros objetos cuando procesa un objeto en un paso. El sistema explica tales dependencias de objetos automáticamente. No es necesario que efectúe ninguna parametrización adicional.
Quiere realizar la determinación de resultados para un elemento PEP (stock para proyecto no valorado). Las órdenes de fabricación cuyos costes reales se deban incluir en la determinación de resultados están asignadas al elemento PEP.
Existen pools de trabajo individuales para cada secuencia de pasos de procesamiento (es decir, cada definición de proceso). Las secuencias de pasos de procesamiento típicas son las secuencias de cierre del período para los componentes de aplicación individuales. Se crean los pools de trabajo individuales para cada aplicación (por ejemplo, para órdenes CO y proyectos).
El pool de trabajo de varios niveles satisface las necesidades básicas siguientes:
Se procesan los objetos seleccionados en la medida de lo posible.
Los objetos seleccionados se procesan únicamente cuando el procesamiento es posible y necesario.
Las dependencias entre los objetos se tienen en cuenta.
Se pueden encontrar relaciones de objetos, por ejemplo:
En entornos de fabricación por proyecto
Cuando está utilizando jerarquías de objetos de coste
Supongamos que se está realizando una determinación de resultados para elementos PEP en un entorno de fabricación por proyecto. El sistema determina primero los elementos PEP que son relevantes en función de los criterios de selección. Estos elementos PEP se llaman objetos primarios porque son los objetos originales que se deben procesar.
La determinación de resultados incluye también valores que se contabilizan en las órdenes de fabricación asignadas a los elementos PEP. Se seleccionan estas órdenes de fabricación basándose en su dependencia al elemento PEP. Se llaman objetos secundarios.
La determinación de objetos secundarios depende no sólo del tipo de pool de trabajo (por ejemplo, las jerarquías de objetos de coste, los proyectos), sino también de la función empresarial actual y de los objetos procesados.
Supongamos que se está realizando el cierre del período para una jerarquía de objetos de coste.
Calcule los gastos generales reales en el nivel de los nodos de objetos de coste. En este caso, no hay ningún objeto dependiente porque se incluye cada nodo de objetos de coste en el cálculo de recargos. Las relaciones con otros nodos de objetos de coste no desempeñan ningún papel.
Quiere también distribuir los costes reales asignados a los nodos de objetos de coste entre los nodos inferiores de objetos de coste del colector de costes del producto asignado. Durante la distribución surge la siguiente situación:
Siempre que un nodo de objetos de coste de una jerarquía de objetos de coste sea un objeto primario, todos los otros nodos serán objetos secundarios (siempre y cuando no sean a su vez objetos primarios).
Durante la ejecución de la definición de proceso, los pasos de procesamiento individual recibirán una lista de los objetos a procesar. Cada paso de procesamiento devuelve el status de procesamiento de cada objeto y una lista de los mensajes visualizados al pool de trabajo.
El alcance de selección puede comprender todos los objetos que se deben procesar en un proceso determinado. Sin embargo, en algunas situaciones, es posible que se desee realizar el mismo proceso más de una vez en paralelo con alcances de selección diferentes. Este procesamiento manual en paralelo puede servir para reducir el tiempo de ejecución general.
Supongamos que se desea realizar el cierre del período para el componente Controlling del producto por órdenes en Contabilidad de objetos de coste. Puede procesar todas las órdenes de fabricación y de procesamiento en un centro, o bien todos los centros en una sociedad CO.
Se crean diversos alcances de selección en los cuales se selecciona por centro y clase de orden. Esto significa que, por ejemplo, un alcance de selección abarca todas las órdenes de fabricación de un centro y otro alcance de selección abarca todas las órdenes de procesamiento de ese mismo centro.
Se debe concluir completamente el paso de procesamiento anterior de la secuencia antes de iniciar el siguiente paso.
Después de que se haya ejecutado la secuencia de pasos de procesamiento, el usuario fuerza una verificación manual.
El proceso definido por el usuario de pasos de procesamiento individuales (especificados en la definición de proceso), la verificación de los objetos con errores y la liberación de dicha verificación (para un procesamiento posterior de los objetos) se debería repetir hasta que todos los objetos tengan el status OK en todos los pasos de procesamiento. En cuanto se logre esto, el proceso está concluido.
Procesamiento de los objetos en el pool de trabajo
El pool de trabajo se procesa en el monitor. El monitor visualiza una lista de los objetos defectuosos y los mensajes emitidos para los objetos. Se necesita esta información para analizar y corregir los errores.
En el monitor se puede especificar cómo se deben procesar los objetos la próxima vez que se ejecuta la secuencia de pasos de procesamiento. Por ejemplo, puede especificar lo siguiente:
Que los objetos marcados como defectuosos en un paso de procesamiento determinado queden excluidos para la próxima vez que se ejecuta el paso de procesamiento y, en su lugar, se introduzca el paso de procesamiento posterior.
Los objetos procesados sin errores se vuelvan a procesar si presentan errores en un sentido empresarial (por ejemplo, como consecuencia de parametrizaciones del Customizing erróneas).
Si un objeto se ha procesado sin errores en una ejecución de actualización para cálculo de intereses del proyecto, se podrá lanzar únicamente un nuevo cálculo de intereses si se anula primero el cálculo de intereses anterior. Si no se realiza ninguna anulación, el objeto no se incluirá en el recálculo de intereses aunque su status de procesamiento lo permita normalmente.
Esto se controla mediante el status de procesamiento del objeto y el paso de procesamiento.
Debe tener en cuenta lo siguiente:
Si se ha modificado un objeto desde que éste se procesó en la secuencia de pasos de procesamiento definida por la definición de proceso (por ejemplo, se han asignado costes adicionales al objeto), no se tendrá en cuenta esta modificación si el objeto ya se ha procesado sin errores. En este caso, se debería modificar el status de procesamiento para el primer paso de procesamiento de la secuencia de pasos de procesamiento para forzar un procesamiento posterior.
Véase también:
Véanse las secciones siguientes para obtener información adicional sobre el monitor y cómo utilizarlo:
Schedule Manager: Monitor - Trabajar con la lista de objetos
Procesamiento de pools de trabajo Status de procesamientoLanzamiento del procesamiento posterior de objetos
Procesamiento posterior automático
En cuanto se hayan procesado todos los objetos y se hayan corregido los errores o especificado que se debería omitir el paso de procesamiento para el que se emitieron errores, se puede repetir la secuencia de pasos de procesamiento para procesar de nuevo los objetos que habían sido defectuosos en la ejecución anterior. El procesamiento posterior se inicia desde el mail.
El sistema procesa a continuación los objetos en el alcance de selección que se habían procesado con errores en la primera ejecución de la secuencia de procesamiento y aquellos que se ordenó al sistema que procesara de nuevo (procesamiento forzado manualmente). Para cada objeto, el procesamiento se inicia con el paso que tenía errores o para el cual el procesamiento se ha forzado manualmente. Los únicos pasos de procesamiento repetidos para un objeto son aquellos para los cuales han aparecido errores en la ejecución anterior, aquellos que todavía no se han ejecutado o aquellos para los cuales se ha forzado un procesamiento posterior.
Durante la primera ejecución y durante la ejecución repetida, los únicos objetos procesados en cada paso son aquellos que se procesaron con éxito en el paso de procesamiento anterior y todavía no se han procesado con éxito en el paso actual. Esto limita el número de objetos para los que se debe efectuar un procesamiento posterior en cada paso a aquellos para los cuales los errores aparecieron en este paso o en los pasos anteriores de la primera ejecución. También se tienen en cuenta las dependencias entre los objetos. Es decir, dependiendo del objeto a procesar y del paso de procesamiento, podría ser necesario volver a procesar objetos adicionales aunque éstos ya se hayan procesado con éxito.
Reorganización de datos de gestión del pool de trabajo de varios niveles
Los datos de gestión del pool de trabajo de varios niveles abarcan el alcance de selección, la información de paso (paso del proceso), el status de procesamiento para el objeto y los mensajes de error para el objeto.
Se borran estos datos de gestión junto con los datos de workflow del Schedule Manager. No es posible archivar los pools de trabajo.Actividades
Después de la ejecución de todos los pasos de procesamiento, el sistema le informa por mail de que los resultados de dichos pasos están listos para la revisión. Una vez verificados los resultados y corregido cualquier error, el sistema le preguntará si desea repetir el procesamiento posterior.
Para hacer las verificaciones relevantes, acceda al monitor del Schedule Manager.
Se puede acceder al monitor de los modos siguientes:
Desde el mail
Directamente desde el menú del componente
Véase también:
Pool de trabajo de varios niveles: Proceso