...
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:
| Info |
|---|
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. |
...
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):
| Info |
|---|
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. |
...
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:
| Info |
|---|
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. |
...
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”:
...