Creación de flujos de aprobación de documentos de Ariba centrados en las solicitudes de compra: lo que se debe y lo que no se debe hacer y las mejores prácticas corporativas a partir de la propia experiencia CONTINUACIÓN: Ediciones, cambios, reglas de filtro y reglas de edición aprobables

Esta publicación pretende complementar la anterior Reglas de aprobación, centrándose ahora en la configuración fuera del flujo de aprobación principal que se explica allí. Para comprender mejor la problemática y la documentación de Ariba, es muy útil comprender la distinción entre «editar» y «cambiar» un documento aprobable de la forma en que lo hace Ariba. Para Ariba, “editar” describe los cambios realizados en el documento mientras ya se encontraba en el proceso de aprobación con el estado Enviado. «Cambio», por otro lado, describe una situación en la que se creó y aprobó el PR, se generó la orden de compra, pero para realizar algunos cambios adicionales, se debe «cambiar» la solicitud original y se debe generar una nueva versión del PR. Los cambios aplican para los documentos en estado Pedido.

REGLAS DE EDICIÓN APROBABLES

Muy a menudo, los administradores de Ariba se confunden acerca de cuál es la diferencia entre «Reglas de filtro» y «Reglas de edición aprobables», pero en realidad la distinción es bastante simple: las reglas de edición aprobables influyen en cómo se comportarán las aprobaciones cuando se cumplan ciertas condiciones. Determinan si los usuarios pueden modificar (“editar”) un contenido aprobable.por ejemplo, solicitud de pedido, después de haber sido presentado, lo que significa que son aplicables a los documentos con el estado »Enviado». Las condiciones se pueden construir de la misma manera y con la misma lógica que para las Reglas de Aprobación. Una de las posibles subcondiciones podría verificar si alguien en el proceso de aprobación cambió algunos campos predefinidos en el PR. Las condiciones se pueden combinar para que otra subcondición pueda especificar que solo los usuarios autorizados con un grupo de usuarios específico asignado pueden cambiar los campos sin volver a activar la aprobación. Esos podrían ser compradores, administradores de impuestos, administradores de cargos, etc. Luego puede definir la acción correspondiente para que se active si se cumplen las condiciones: si esta edición tiene sin efectos, debe ser el PR reenviado, reaprobado o debería ser la edición prohibido en total.

• Editar con reenviar – el motor de aprobación inicia la aprobación completa de nuevo desde el principio
• Editar requiere reaprobaciones – hará que se necesite una nueva aprobación en el nodo de aprobación que está en el flujo después del nodo donde se realizó el cambio.

Por ejemplo, captura de pantalla a continuación: el aprobador de presupuesto aprueba y el comprador de auditoría aprueba después. El aprobador del presupuesto se da cuenta solo más tarde de que es necesario cambiar algo y edita el PR. Luego, el motor volverá a auditar al comprador para volver a aprobarlo. En otras palabras, esta acción puede invalidar algunas aprobaciones que ya se realizaron.

Si el usuario que realiza la edición no está en absoluto en el flujo de aprobación, la aprobación volverá al primer nodo de aprobación casi como en la edición con reenvío.

• No es posible editar – el botón de edición no está visible.

También puede notar los botones «Mover hacia arriba» y «Mover hacia abajo» (no olvide estar en modo de edición). Esto le permite cambiar el orden de las reglas de edición individuales. De manera similar a las tablas de búsqueda de aprobadores, Ariba prefiere y aplica primero las reglas que son más altas que los otros. En la práctica, cuando descifra el comportamiento de cierto proceso de aprobación aprobable, debe comenzar a mirar las reglas ubicadas más arriba para ver si son aplicables y solo luego pasar a la siguiente regla. Esta jerarquía de Reglas es importante p.ej. en caso de que un aprobador tenga roles/grupos asignados en varias reglas, entonces se aplicará la jerarquía de las reglas.

REGLAS DE FILTRO

Puede usar reglas de filtro para filtrar las solicitudes de aprobación generadas por el proceso de aprobación. Al igual que para las reglas de edición, el orden de las reglas de filtrado es importante. Solo se tendrán en cuenta los primeros válidos. Por ejemplo, puede agregar una regla de filtro a eliminar ocurrencias duplicadas del mismo aprobador o eliminar solicitante él mismo. También puede eliminar aprobadores y aprobar automáticamente la solicitud modificada si la cantidad o el monto de los elementos de línea individuales no ha aumentado y no hubo cambios en los campos adicionales que podría haber especificado en las reglas. En caso de que el usuario o el grupo aparezcan en el flujo varias veces, puede decidir mantener solo la primera o la última aparición. Vea el ejemplo a continuación: El usuario del presupuesto es el doble del flujo sin regla de filtro adicional:

Si decides Conservar primer aprobador – esto mantendrá al usuario o grupo solo en el primer nodo donde aparecen:

Si decides Conservar último aprobador – esto mantendrá al usuario o grupo solo en el último nodo donde aparecen:

CONSEJO: ¿Qué sucede si desea omitir la aprobación de la solicitud por completo, por ejemplo, cuando cambió PR, se generó la versión 2 de la solicitud como consecuencia de esto, pero le gustaría mantener la aprobación vigente solo para las solicitudes modificadas por encima de cierto umbral? Técnicamente hablando, la pregunta sería cómo omitir ciertos nodos de aprobación. Las empresas a menudo solicitan esto en relación con los cambios de precios. Además de crear condiciones de nodo de aprobación como de costumbre, puede agregar la condición que indica que las condiciones originales son válidas solo para la primera versión de la solicitud. Hay un campo predefinido disponible para hacer eso. A continuación, puede crear otro conjunto de condiciones para este nodo de aprobación que será relevante para la V2 y las siguientes versiones de las solicitudes agregando el campo correspondiente a las condiciones que definen que el valor de la versión debe ser 2 y superior. Después de eso, puede agregar a esas nuevas versiones condiciones una condición que exige que el cambio de costo total en porcentaje debe ser mayor que, digamos, 10 % para que se active el nodo de aprobación. De manera similar, puede crear una condición, trabajando en conjunto con el porcentaje, especificando que la diferencia entre la cantidad de la versión actual y la anterior en valores absolutos debe estar por encima de cierto umbral. Desafortunadamente, los campos similares que comparan dos versiones de la solicitud de compra que se usarán en Condiciones para configurar esto deben ser creados, al menos en este momento, por el soporte de Ariba, por lo que tendrá que comunicarse con ellos.

Espero que esto lo ayude a comprender mejor la configuración de aprobaciones y la complejidad detrás.

¡Salud!

Adán