Actuación simple
Este tipo de actuación supone realizar una actuación sobre la solicitud (v2.0). Este tipo es equivalente a seleccionar la opción de “continuar actuando” sobre el formulario en la NWT.
Requisitos funcionales
La solicitud debe existir y el usuario debe tener permisos para trabajar con ella.
Debe ser posible realizar la actuación. La solicitud debe haber estado asignada a un usuario de la misma organización en algún momento y sólo se podrá actuar durante un plazo de 15 días tras la resolución de la solicitud.
Sólo se podrá realizar la operación con solicitudes padres.
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 registro de la plataforma, al ser opcional en NWT, se abordará como un método independiente; puede consultar las especificaciones en el apartado correspondiente.
- Enviar el tipo de actuacion "No aplica" (401113)
Escalado
Este tipo de actuación supone realizar una actuación sobre la solicitud seguida de un escalado de la misma. Este tipo es equivalente a seleccionar la opción de “escalar” sobre el formulario en la NWT y la solicitud termina 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), 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.
El usuario podría no tener permisos para realizar estas operaciones individualmente o, en caso de tenerlo, el resultado de la operación no será el esperado.
Requisitos funcionales
Mismos requisitos que para una actuación simple, salvo por el envío del tipo de actuación, que no puede ser "No aplica" y debe pertenecer a la lista de tipos de actuación compatibles.
La solicitud debe encontrarse en estado “Abierta” y estar asignada actualmente al proveedor.
El comentario enviado en cambio de asignado debe coincidir con el comentario de actuación.
- El registro de la plataforma, al ser opcional en NWT, se abordará como un método independiente; puede consultar las especificaciones en el apartado correspondiente.
El usuario al que se va a escalar la solicitud debe estar permitido. Para consultar los usuarios a los que se puede escalar la solicitud, se debe hacer uso del siguiente recurso pasando el parámetro idSolicitud en la URL:
Resolución simple
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 cuatro operaciones, la primera para crear la actuación propiamente dicha (v2.0), la segunda para modificar la solicitud registrando la complejidad (v6.0), la tercera para modificar la solicitud registrando la plataforma (v1.3), la cuarta para cambiar el estado de la solicitud a “Pdte. Conf. Cierre” (v2.0) y terminar con el cambio de causa raíz (v3.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.
El usuario podría no tener permisos para realizar estas operaciones individualmente o, en caso de tenerlo, el resultado de la operación no será el esperado.
Requisitos funcionales
- Mismos requisitos que para una actuación simple.
La solicitud debe encontrarse en estado “Abierta” y estar asignada actualmente al proveedor.
- La complejidad sólo quedará registrada para solicitudes de tipo "Petición", para el resto de casos enviarla a vacío.
- En caso de no enviar la complejidad para una solicitud de tipo "Petición", se adoptará la complejidad por defecto configurada para la tipificación.
Para el registro de la plataforma (obligatorio), seguir las indicaciones del apartado correspondiente.
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”:
- El comentario enviado en el cambio de estado debe coincidir con el comentario de actuación. Del mismo modo, el comentario de causa raíz debe ser diferente, ya que debe reflejar la justificación de elección de dicha causa.
- Es obligatorio justificar el cambio de causa imputable si ésta no es la causa imputable definida por defecto para la causa raíz indicada. La causa imputable por defecto se obtiene en la consulta de causas raíces.
- No se pueden resolver por este método las solicitudes generadas mediante agenda con el usuario. (motivoPlanificacion.id=400015)
Resolución con envío a JIRA
Este tipo de actuación supone realizar una actuación sobre la solicitud seguida de un envío de la solicitud a JIRA y la modificación de la causa raíz de la solicitud. La solicitud termina asociada con JIRA como entidad de tipo "PL datos" y en el estado “Pdte. Implantar”. Esta operación equivale a realizar cuatro operaciones, la primera para crear la actuación propiamente dicha (v2.0), la segunda para modificar la solicitud registrando la plataforma (v1.3), la tercera para lanzar la integración con JIRA y generar la solicitud en esta herramienta y finalizando con un cambio en la causa raíz de la solicitud (v3.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.
El usuario podría no tener permisos para realizar estas operaciones individualmente o, en caso de tenerlo, el resultado de la operación no será el esperado.
Requisitos funcionales
- El versionado indicado debe ser "No incrementa versión (sólo requiere petición de lanzamiento de datos)". En JIRA se creará el registro como "PL datos".
- Para el registro de la plataforma (obligatorio), seguir las indicaciones del apartado correspondiente.
- La complejidad sólo quedará registrada para solicitudes de tipo "Petición", para el resto de casos enviarla a vacío.
- En caso de no enviar la complejidad para una solicitud de tipo "Petición", se adoptará la complejidad por defecto configurada para la tipificación.
- 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”:
- Es obligatorio justificar el cambio de causa imputable si ésta no es la causa imputable definida por defecto para la causa raíz indicada. La causa imputable por defecto se obtiene en la consulta de causas raíces.
- No se pueden resolver por este método las solicitudes generadas mediante agenda con el usuario. (motivoPlanificacion.id=400015)
- En caso de seleccionar el versionado "No incrementa versión (sólo requiere petición de lanzamiento de datos)", se pueden obtener las PLs de Datos a asociar en el parámetro plJira del siguiente método: