Este apartado recoge la operativa para escalar y resolver solicitudes en el caso de Proveedores Genéricos.
Enmarcadas en la fase de creación tenemos las siguientes acciones:
Este tipo de actuación supone realizar un escalado de la solicitud, terminando ésta asignada a otro resolutor, dentro de la misma organización o no. Esta operación equivale a realizar dos operaciones, la primera para crear la actuación propiamente dicha (v2.0) y la segunda para escalar la solicitud a un nuevo resolutor, modificando el asignado:
Para garantizar la integridad de la operación, estas modificaciones deberán realizarse a través de una operación de batch en el orden correcto. |
Requisitos funcionales
La solicitud debe existir y el usuario debe tener permisos para trabajar con ella.
La solicitud debe encontrarse en estado “Abierta” y estar asignada actualmente al proveedor.
El delegado que realiza la operación debe estar dado de alta en CGES y pertenecer a la misma organización que el usuario de integración que hace uso de la API.
Este tipo de actuación supone realizar una actuación sobre la solicitud seguida de un cambio de estado de esta a “Pte. Conf. Cierre” y finalizando con un cambio en la causa raíz de la solicitud. Este tipo es equivalente a seleccionar la opción de “resolver” sobre el formulario en la NWT y no marcar “Requiere RFC” en las opciones. Esta operación equivale a realizar tres operaciones, la primera para crear la actuación propiamente dicha (v2.0), la segunda para informar la causa raíz en la solicitud (v2.0) y la tercera para cambiar el estado de la solicitud a “Pdte. Conf. Cierre” (v2.0):
Para garantizar la integridad de la operación, estas modificaciones deberán realizarse a través de una operación de batch en el orden correcto. |
Requisitos funcionales
La solicitud debe existir y el usuario debe tener permisos para trabajar con ella.
La solicitud debe encontrarse en estado “Abierta” y estar asignada actualmente al proveedor.
El delegado que realiza la operación debe estar dado de alta en CGES y pertenecer a la misma organización que el usuario de integración que hace uso de la API.
El único cambio de estado permitido es a “Pdte. Conf. Cierre”.
Las causas raíces compatibles se obtienen con el siguiente método (filtrando por idSolicitud) y deben ir acompañadas de un texto de justificación en caso de que la causa raíz indicada sea diferente de “No Aplica”:
Este tipo de actuación supone la modificación de la causa raíz de la solicitud seguida de un envío de la solicitud a FARO. La solicitud termina asociada con FARO y en el estado “Pdte. Implantar”. Esta operación equivale a realizar tres operaciones, la primera para crear la actuación propiamente dicha (v2.0), la segunda para cambiar la causa raíz de la solicitud (v2.0) y la tercera para lanzar la integración con FARO y generar la solicitud en esta herramienta. El cambio de estado no es necesario, ya que es la integración con FARO la encargada de actualizar la solicitud:
Para garantizar la integridad de la operación, estas modificaciones deberán realizarse a través de una operación de batch en el orden correcto. |
Requisitos funcionales
La solicitud debe existir y el usuario debe tener permisos para trabajar con ella.
El delegado que realiza la operación debe estar dado de alta en CGES y pertenecer a la misma organización que el usuario de integración que hace uso de la API.
La RFC indicada debe ser válida y encontrarse entre las que se obtienen en el siguiente recurso suministrando el código PROVEEDOR y el tipo RFC_CMS:
La solicitud debe encontrarse en estado “Abierta”, no estar tipificada como “Consulta” y estar asignada actualmente al proveedor.
Las causas raíces compatibles se obtienen con el siguiente método (filtrando por idSolicitud) y deben ir acompañadas de un texto de justificación en caso de que la causa raíz indicada sea diferente de “No Aplica”:
El comentario de causa raíz debe reflejar la justificación de elección de dicha causa.
Este tipo de actuación supone realizar una actuación sobre la solicitud seguida de un envío de la solicitud como incidencia a JIRA y finalizando con la modificación de la causa raíz de la solicitud.
Este tipo es equivalente a seleccionar la opción de “resolver” sobre el formulario en la NWT y escoger “Modifica LB” en las opciones de versionado.
La solicitud termina asociada con JIRA y en el estado “Pdte. Implantar”.
Esta operación equivale a realizar tres operaciones, la primera para crear la actuación propiamente dicha (v2.0), la segunda para lanzar la integración con JIRA y generar la solicitud en esta herramienta y finalizar con un cambio en la causa raíz de la solicitud (v2.0):
Para garantizar la integridad de la operación, estas modificaciones deberán realizarse a través de una operación de batch en el orden correcto. |
Requisitos funcionales