Estimado
Endoso lo que dijo Alvaro, Gxflow calculará los "candidatos" (aquellos a los que aparece la tarea en su bandeja de entrada) combinando (CON AND) las condiciones de rol y unidad organizacional.
La unidad se la asignas a la tarea de dos maneras.
1. Si la unidad es heredable, se copiaran al ProcessInstance las unidades que tenga el usuario que crea la tarea.
2. A través de la API, le asignas la unidad organizacional al ProcessInstance.
En general, esto es suficiente para un proceso de aprobación.
Atte, cwompner.
El 19 de octubre de 2012 09:49, Fernando Larrea <f.larrea@datalogic.com.uy> escribió:
Hola Rubén para solucionar el problema de la empresa podes utilizar las
restricciones asociadas a la instancia y luego asociar las mismas a los
usuarios en cuestión.
Para la autorización múltiple podrías definirte tareas del tipo vector en el
GXPM.
Esto lo he utilizado sin problemas en GXFLow 9.0
Saludos,
Fernando
-----Mensaje original-----
De: Ruben Eduardo [mailto:ruben.bugueno@gmail.com]
Enviado el: viernes, 19 de octubre de 2012 10:33
Para: gxflow-l@gxtech.com.uy
Asunto: [gxflow-l]
Estimados, estoy adentrándome en el mundo de GXFlow y me surge un problema.
Estoy modelando el flujo de compras del holding de empresas en el cual
trabajo, identificando las siguientes tareas:
- Ingreso de Solicitud Orden de Compra (SOC).
- Aprobación de SOC.
- Generación de Orden de Compra (OC) en ERP.
- Envío de OC a Proveedor.
- …
Al analizar el proceso me encontré con que existen usuarios que pueden
ingresar SOC a varias empresas del hoding y que, a su vez, existen un
conjunto de usuarios por empresa que deben aprobar la SOC para que luego se
genere la OC. Cada uno de los usuarios aprobadores deben aprobar
individualmente la SOC y si todos la aprueban se desencadena la tarea de
Generación de OC en ERP. Organizacionalmente hablando, los usuarios que
solicitan NO NECESARIAMENTE pertenecen a las empresas en las que pueden
ingresar SOC.
No comprendo cómo puedo modelar este comportamiento de ingreso, para que la
SOC se dirija sólo a los buzones de los usuarios aprobadores de la empresa a
la que pertenece la SOC. Además, tampoco sé como modelar el subproceso de
aprobación, considerando que la cantidad de usuarios aprobadores por empresa
es variable y se basa en una matriz de aprobación que se encuentra modelada.
Qué llevo realizado:
- He creado el primer flujo del proceso (Un flujo básico para
comenzar a modelarlo…)
- Para solucionar el problema que las SOC que pertenecen a una
empresa no sean vistos por otras empresas del holding, creé una "Definición
de Unidad Organizacional" denominada HOLDING y cree una "Unidad
Organizacional" por cada empresa que pertenece al holding.
Así, podré identificar cada usuario con su empresa (similar al ejemplo de
las sucursales que aparece en los videos tutoriales de GXFlow 9.0)
Les pido su ayuda para resolver estos dilemas, pues como les comenté al
principio estoy recién entrando al Modelamiento de procesos con GXFlow
(Anteriormente sólo he desarrollado sistemas transaccionales con GeneXus 9.0
y GeneXus X Evolution 1).
Estoy trabajando con GeneXus X Evolution 1, Generador .NET y Motor de BBDD
SQL Server 2005
Atento a sus comentarios, se despide,
Rubén Bugueño Quintero.
---------------------------------------
Para Suscribirse/Desuscribirse:
http://www.gxtechnical.com/cgi-bin/hforum.exe?2,3,30,7
Por consultas owner-gxflow-l@gxtech.com.uy
---------------------------------------
Para Suscribirse/Desuscribirse:
http://www.gxtechnical.com/cgi-bin/hforum.exe?2,3,30,7
Por consultas owner-gxflow-l@gxtech.com.uy
Atte, cwompner@gmail.com.
0 Response to "Re: [gxflow-l]"
Publicar un comentario