Guía 03 - Integración

Objetivo del documento

 

El presente documento tiene por objeto definir las especificaciones técnicas básicas que se deberán observar para garantizar la interoperabilidad entre los aplicativos.

Así como definir la información que la Instancia Gubernamental deberá proporcionar para proponer un componente genérico como clases, componentes de código, catálogos, servicios comunes, procesos, servicios web (SOAP/REST) o cualquier otro medio de interoperabilidad.

 

  1. Descripción del componente genérico

Describir la información general del componente genérico que se propone al “Consejo Técnico de Interoperabilidad”, la tabla deberá tener las columnas de:

 

  • Componente: Indicar el nombre del componente.
  • Tipo de Componente: Clases, componentes de código, catálogos, servicios comunes, procesos, servicios web (SOAP/REST) o cualquier otro medio de interoperabilidad.
  • Entidad Responsable: Entidad propietaria de dicho componente 
  • Especificación Técnica: Detallar la justificación de porqué se considera un componente reutilizable o común
  • Forma de desarrollo: seleccionar uno de los casos siguientes:
    • Componente Reutilizables: Son los que se encontraran en el repositorio arquitectónico, de los cuales la Institución se beneficiaría con su reutilización al interoperar su trámite.
    • Componentes a Comprar: Indicar los componentes de terceros que por los requerimientos y arquitectura definida, son componentes adquiridos.
    • Componentes Genéricos a Desarrollar: Indicar los componentes a desarrollar que por los requerimientos y arquitectura definida, son componentes genéricos requeridos a desarrollar.
    • Componente Adicional: Cuando este componente es necesario como Requisito del Trámite y se hace necesario su desarrollo, siendo parte ajena del propio Tramite.

 

 

 

ejemplo:

 

Componente

Tipo de componente

Institución responsable

Especificación técnica

Forma de desarrollo

API 1 - Búsqueda del Trámite

Servicio web

IG

Presenta la estructura que tendrá la Petición - Respuesta de la API 1 - Búsqueda del Trámite

Desarrollo Propio

Motor de pagos

Servicio web

SATQ

Servicio web que permite agrupar la administración de todo el proceso de pagos en un solo punto centralizado (Hub), junto con los parámetros y controles de acceso de cada solicitud.

Reutilizable

 

 

2. Firmas de elaboración, revisión y aprobación

En este apartado se deberán asentar los nombres y cargos de los servidores públicos responsables de la elaboración, revisión y aprobación del documento, incluir las firmas autógrafas de los mismos

 

 

G03-F02 Contratos de Interfaz 

 

Objetivo del Documento

 

En este apartado se describen, mediante escenarios, las operaciones con las que se construye el flujo de Mensajes con la cual se conforma el esquema de operación de la Interoperabilidad, así como el detalle de la construcción de dichos Servicios Web.

 

En la siguiente sección deberá indicar y replicar cada Operación que contenga la Contrato de Interfaz de Interoperabilidad, con la finalidad de detallar completamente todas y cada una de las Operaciones o métodos que serán publicados.

 

Las aplicaciones Restful utilizan métodos para comunicarse con el servidor, por convenio los más utilizados son:

  • GET : Obtener uno o más elementos
  • POST: Crear un nuevo elemento
  • PUT: Actualizar
  • DELETE: Borrar

 

Cuando los servicios web utilizan la arquitectura REST, se denomina API RESTful (Interfaces de Programación de Aplicaciones) o API REST

 

REST utiliza un formato de mensajes más pequeña, esto significa que REST proporciona un mejor rendimiento, así como reduce los costos con el tiempo. Además, no se requiere un procesamiento intensivo, por lo que es mucho más rápido que el SOAP tradicional.

 

REST está diseñado para su uso a través de internet. Esta es una mejor opción para aplicaciones de escala web, y ciertamente para plataformas basadas en nube.

 

Swagger es un framework para generar documentación de APIs RESTful, el cual utiliza la especificación Open API, la cual define una interfaz estándar independiente del lenguaje para las API RESTful que permite comprender las capacidades del servicio sin acceso al código fuente, la documentación o la inspección del tráfico de la red.

La documentación se encuentra disponible en:

https://swagger.io/specification/

 

SwaggerHub es una plataforma colaborativa donde se puede definir APIs utilizando la especificación Open API y administrar las  API a lo largo de su ciclo de vida.

 

Swagger Hub permite:

  • Definir APIs en formato Open Api.
  • Alojar todas las definiciones de Open Api en un sólo lugar.
  • Compartir APIs de forma Pública o Privada.
  • Administrar múltiples versiones de API.

 

YAML es un formato para guardar objetos de datos con estructura de árbol.

Para mayor detalle observar la “Guía REST Api con Swagger”.

 

Por cada escenario identificado se documentará en la siguiente tabla:

 

  1. Entrada (Esquema de Petición - Request) 

 

HTTP funciona como un protocolo de Petición - Respuesta entre un cliente y un servidor, ejemplo:

Un cliente envía una Petición al servidor, entonces el servidor devuelve una Respuesta al cliente. 

La respuesta contiene información de estado sobre la Petición y también puede contener el contenido solicitado.

 

En la siguiente URL se encuentra el documento que contiene la estructura de Petición - Respuesta de la API 1 - Búsqueda del Trámite, la cual será incorporada a la “Plataforma para la Transacción del Trámite”:

https://docs.google.com/document/d/1i5c3TovcsXkjHIzcqB5cik1-vwALzOpTI14bIYuTsEw/edit

 

Como ejemplo:

https://docs.google.com/document/d/1-Rlm5dqxjAb6Bi0qJraTXgvI7Qa0lMrb4ZkZkbqsdIo/edit

 

A continuacion se documenta por medio de la tabla la Entrada (Esquema de Petición - Request) a realizar en la Interoperabilidad descrita.

 

Item

Descripción

Nombre del Escenario

Indicar el nombre del Escenario al cual pertenece el Servicio Web

Método U Operación

Indicar el nombre del componente, método u operación del Servicio Web que será publicado, ejemplo: API1_BusquedaTramite

Descripción

Indicar la funcional que tendrá el método u operación

Nombre y Correo del Responsable 

Nombre completo y correo electrónico del responsable del Servicio Web.

Versión

indicar la versión del servicio web de interoperabilidad

Token de autenticación 

En su caso, especificar el tiempo de vida útil del token y el mecanismo de generación del token.

Indicar SI o NO hacen uso de usuario y contraseña.

Esta información es confidencial y se compartirá por procedimiento interno

URL Acceso

Indicar el punto final de acceso al Servicio, Ruta o EndPoint

PDF del HTML2

Adjuntar la URL de la exportación del PDF del HTML2 del Servicio Web diseñado en el Swagger Hub.

Archivo editable “yaml”

Exportar documentación en formato YAML en Swagger Hub y adjuntar la URL, el procedimiento es:

Ir a la opción Export -> Download Api -> YAML Unresolved

Se descargara el archivo, ejemplo Solicitantes-api-1.0.0-swagger.yaml

Esquema de petición

Describir la forma o el formato que se realizará la petición, ejemplo:

POST

Estructura de la Petición

Poner la estructura de Petición con todos los parámetros a utilizar.

 

Para la definición del nombre de los parámetros, hay que observar las recomendaciones en campos del Estándar de Web Service que se encuentra en el documento “Criterios de Seguridad y de Estandarización para la Creación de Servicios Web para Instancias Gubernamentales”.

 

Para lo anterior se definió la siguiente estructura base:

 

{

ews_token:"eyJ0eXAiOiJKV1QiLCJhbGciOiJsImp0aSI6..."

ews_no_solicitud: "2020-0000000001",

ews_llave=”deklfeoe3342xcbfkjrb...”

ews_id_tramite: "1",

ews_fecha_solicitud : "2020-02-23",

ews_hora_solicitud : "14:00:00",

ews_datoadicional1 : "",

ews_datoadicionalN : "",

}

 

Definición de parámetros de petición

 

Es necesario definir el detalle de cada uno de los parámetros.

 

Parámetros

Descripción

Tipo de Dato

Es requerido

Observaciones

Ejemplo

Nombre del parámetro

Descripción del parámetro

Tipo de dato

Indicar si el parámetro es requerido o qué valor por default puede tener.

Observaciones adicionales

Ejemplo de uso

 

ejemplos:

 

Parámetros

Descripción

Tipo de Dato

Es requerido

Observaciones

Ejemplo

ews_token

Token de validación para acceso al Web Service

Longtext 1500

SI

 

eyJ0eXAiOiJKV1QiLCJhbGciOiJsImp0aSI6...

ews_no_solicitud

No de solicitud generado por la plataforma

Cadena 15

SI

 

2020-0000000001

ews_llave

cadena generado por la plataforma

Cadena 100

SI

Dará mayor certeza a una solicitud válida

deklfeoe3342xcbfkjrb...

ews_id_tramite

Identificador del trámite en la plataforma

Numérico

SI

 

1

ews_fecha_solicitud

Fecha de la solicitud generado por la plataforma

Fecha

SI

 

2020-02-23

ews_hora_solicitud

Hora de la Solicitud generado por la plataforma

Hora

SI

 

14:00:00

ews_datoadicional1

Demás datos que se necesitan enviar al API

   

señalar el nombre de la etiqueta

 

ews_datoadicionalN

Demás datos que se necesitan enviar al API

   

señalar el nombre de la etiqueta

 

 

 

  1. Salida (Esquema de Respuesta - Response)

 

La Salida (Esquema de Respuesta - Response) contiene información de estado sobre la Petición y también puede contener el contenido solicitado.

 

Se documentará por medio de la tabla la Respuesta (Request) a realizar en la Interoperabilidad descrita.

 

Item

Descripción

Nombre del Escenario

Indicar el nombre del Escenario al cual pertenece el Servicio Web

Método U Operación

Indicar el nombre del componente, método u operación del Servicio Web que será publicado, ejemplo: API1_BusquedaTramite

Esquema de respuesta

Describir la forma o el formato que se realizará la respuesta, ejemplo:

JSON

Estructura de la Respuesta

Poner un ejemplo de respuesta con todos los parámetros a utilizar.

 

Para la definición del nombre de los parámetros, hay que observar las recomendaciones en campos del Estándar de Web Service que se encuentra en el documento “Criterios de Seguridad y de Estandarización para la Creación de Servicios Web para Instancias Gubernamentales”.

 

Con la finalidad de poder imprimir la vista previa de la respuesta, se define el siguiente estándar de parámetros de respuesta:

 

ejemplo:

 

{

"wsp_folio":"2019-0001",

"wsp_idTramite":"234",

"wsp_lineaCaptura":"2001925657810121111",

"wsp_fechaVencimiento":"31/12/2019",

"wsp_codigo":"0",

"wsp_mensaje":"Formato generado exitosamente"

}

 

 

 

Definición de parámetros de respuesta:

 

Es necesario definir el detalle de cada uno de los parámetros.

 

Parámetros

Descripción

Tipo de Dato

Es requerido

Observaciones

Ejemplo

Nombre del parámetro

Descripción del parámetro

Tipo de dato

Indicar si el parámetro es requerido o qué valor por default puede tener.

Observaciones adicionales

Ejemplo de uso

 

ejemplos:

 

Parámetros

Descripción

Tipo de Dato

Es requerido

Observaciones

Ejemplo

wsp_folio

Folio de referencia con el que un ciudadano puede hacer referencia a su trámite

Cadena (10)

SI

 

2019-0001

wsp_lineaCaptura

Línea de captura generada

Cadena(30)

SI

   

wsp_mensaje

mensaje resultante del requerimiento

Cadena(50)

SI

 

Formato generado exitosamente

 

  1. Firmas de elaboración, revisión y aprobación

En este apartado se deberán asentar los nombres y cargos de los servidores públicos responsables de la elaboración, revisión y aprobación del documento, incluir las firmas autógrafas de los mismos

 

 

Anexo G03-A01 Aseguramiento de la trazabilidad del proceso.

 

Objetivo del documento

 

Proporcionar el procedimiento que permite implementar la trazabilidad del trámite en un entorno de interoperabilidad, que permiten al interesado ubicar el punto de integración del documento con respecto al ciclo de vida del trámite.

 

Se refiere a procedimientos que permiten seguir el proceso de evolución de los servicios que se realicen en el sistema. Proporciona a la institución la trazabilidad, el cual indica que los datos dados son correctos y que su sistema actualizará de forma correcta.

 

¿Qué es una cadena de interoperabilidad?

Es una secuencia de trámites interrelacionados entre sí con un objetivo o un resultado común, dichas relaciones están dadas por las necesidades de información tanto de datos como de documentos que requieren los trámites para ser efectuados.

 

 

La interrelación de la cadena esta dada por el resultado que genera el grupo de trámites y los requisitos de información que solicitan los mismos para llevarse a cabo.

 

Diferencia entre un trámite y una cadena

 

Las cadenas se encuentran en un nivel más alto y separado de los procesos que conforman los trámites o servicios. Sin embargo, se debe tener en cuenta que al innovar el proceso del trámite es posible optimizar los requisitos del mismo eliminando o sustituyendo algunos, dicha acción tendrá impacto en la cadena.

 

Las cadenas de interoperabilidad agrupan diferentes procesos de trámites de acuerdo al objetivo general que persigue el conjunto de trámites, sin importar que por su lado el trámite tenga un objetivo individualizado.

 

Objetivos de las cadenas de interoperabilidad

 

Los diferentes niveles de la cadena, se establecen para ampliar sus objetivos, hasta abarcar la totalidad de objetivos que se pretenden cubrir con los trámites. Por ejemplo, un mapa de cadena cuyo objetivo es proporcionar atención médica en el IMSS a un trabajador, incluirá lo siguiente:

 

Imagen que ejemplifica los objetivos de las cadenas de interoperabilidad

 

Los objetivos de las cadenas pueden ampliarse en función de las necesidades del ciudadano o la empresa, razón por la cual será posible encontrar, en el mapa que se construya, que cada camino da pie al cumplimiento de un objetivo específico.

 

 

¿Qué se requiere para generar una cadena?

Los datos proporcionados por las dependencias y entidades permitirán construir las cadenas. Entre estos datos se encuentran:

 

  • Objetivo asociado (e.g. Proporcionar atención médica en el IMSS a un trabajador)
  • Trámites de la dependencia o entidad que conforman la cadena (e.g. “IMSS-TYS-0010 / Atención médica en unidades de medicina familiar”)
  • Cadenas iniciadoras relacionadas (e.g. “Dar de alta una empresa con trabajadores”)
  • Trámites de otras dependencias o entidades relacionados (e.g. “IMSS-02-066-M / Solicitud de registro y actualización de derechohabientes”)

 

¿Cómo se construye el mapa general de cadenas?

El mapa general mostrará una visión completa de todas las cadenas en diferentes niveles. Las cadenas en el mapa contarán con identificador (ID) y un trámite padre que es el primero en la cadena, justo después de los iniciadores.

 

¿Para qué nos servirá el mapa de cadenas?

 

La información obtenida con el mapa de cadenas de trámites, permitirá determinar a nivel general la complejidad y la relevancia de las cadenas con miras a su priorización y digitalización.

 

Las cadenas contarán con trámites que se encuentran en distintos niveles de complejidad, relevancia y madurez. Sin embargo, para que sea posible interoperar, será necesario que todos los trámites de la cadena cuenten con un nivel homogéneo de digitalización.

 

 

  1. Descripción de Trazabilidad

 

Los metadatos, propiedades y estatus están definidos en función de las peticiones y acciones que realicen los usuarios finales de cada proceso y/o trámite. 

 

Se deberá proporcionar la información establecida para garantizar la trazabilidad, de acuerdo a lo siguiente:

 

Proceso / Trámite / Servicio de la Instancia Gubernamental

Proceso / Trámite / Servicio de otras dependencias o entidades relacionados

Escenarios Identificados

Nombre del trámite de la IG que se requiere interoperar

Nombre del proceso y/o trámite con la que Interopera

nombre de los escenarios de interoperabilidad identificados

 

 

 

  1. Modelo lógico del trámite 

 

       

 

 

Descripción de las tablas

 

Nombre de la tabla

Descripción de la tabla

Nombre del campo

Descripción del campo

Tipo de dato del campo

Ejemplo

GOBC_SECTOR

Catálogo de sectores de gobierno

ID_SECTOR

Identificador único del sector de gobierno. 

CHAR(3)

DEP ENT ODE

NOM_SECTOR

Nombre del sector de gobierno. 

VARCHAR(50)

Dependencia

Entidad

Órgano Desconcentrado

FEC_BAJA

Fecha de baja del registro

DATETIME

 

GOBC_INSTITUCION

Catálogo de Instituciones

ID_INSTITUCION

Identificador único de la Institución. (Siglas) 

CHAR(10)

SEGOB

NOM_INSTITUCION

Nombre de la Institución 

VARCHAR(50)

Secretaría de Gobierno

ID_SECTOR

Identificador único del sector de gobierno al cual pertenece la Institución

CHAR(3)

DEP

FEC_BAJA

Fecha de baja del registro

DATETIME

 

GOBC_TRAMITE

Catalogo de tramites

ID_HOMOCLAVE

Identificador del Homoclave del trámite

correspondiente al RETyS

CHAR(30)

 

ID_INTEROPERA

Identificador del trámite

correspondiente a InteroperaQR

CHAR(15)

 

DES_TRAMITE

Descripción del trámite

correspondiente al RETyS

VARCHAR(50)

 

ID_TIPO_TRAMITE

Identificador del tipo de trámite

NUMBER

 

NUM_DURACION

Número de horas que tomará realizar el trámite con la interoperabilidad. El tiempo es fijado por la Institución.

NUMBER

 

FEC_BAJA

Fecha de baja del registro

DATETIME

 

GOBC_TIPO_TRAMITE

Catálogo de tipos trámites

ID_TIPO_TRAMTE

Identificador del tipo de trámite

NUMBER

 

DES_TIPO_TRAMITE

Descripción del tipo de trámite

VARCHAR(20)

 

GOBC_CADENA_INTEROPER

Catálogo de las cadenas de interoperabilidad

ID_CADENA_INTEROPER

Identificador de la cadena de interoperabilidad

NUMBER

 

DES_CADENA_INTEROPER

Descripción de la cadena de interoperabilidad

VARCHAR (20) 

 

ID_INSTITUCION

Identificador único de la

Institución. Ejemplo: SENER

CHAR(10)

 

GOBT_CADENA_INTEROPER

Tabla transaccional para la relación

de la cadena de

interoperabilidad con los trámites

ID_CADENA_INTEROPER

Identificador de la cadena de interoperabilidad

NUMBER

 

ID_HOMOCLAVE

Identificador del trámite

correspondiente al CNTS

CHAR(10)

 

ID_INSTITUCION

Identificador único de la Institución a la cual pertenece el trámite.

CHAR(10)

 

NUM_ORDEN_EJECUCION

Orden de ejecución del

trámite asociado a la

cadena de

interoperabilidad

NUMBER

 

 

 

Con la finalidad de tener el catalogo de tramites y conocer su cadena de interoperabilidad, se hace necesario llenar las siguientes tablas:

 

GOBC_SECTOR

ID_SECTOR

NOM_SECTOR

FEC_BAJA

     

 

GOBC_INSTITUCION

ID_INSTITUCION

NOM_INSTITUCION

REF_TELEFONO

REF_DIRECCION

ID_SECTOR(FK)

FEC_BAJA

           

 

GOBT_CADENA_INTEROPER

ID_CADENA_INTEROPER(FK)

ID_HOMOCLAVE(FK)

ID_INSTITUCION(Fk)

NUM_ORDEN_EJECUCION

       

 

GOB_TRAMITE

ID_HOMOCLAVE

ID_INSTITUCION(FK)

DES_TRAMITE

ID_TIPO_TRAMITE(FK)

NUM_DURACION

FEC_BAJA

           

 

GOBC_TIPO_TRAMITE

ID_TIPO_TRAMITE

DES_TIPO_TRAMITE

FEC_BAJA

     

 

GOBC_CADENA_INTEROPER

ID_CADENA_INTEROPER

ID_INSTITUCION(FK)

DES_CADENA_INTEROPER

FEC_BAJA

       

 

 

  1. Modelo lógico de la trazabilidad 

Se implementa el siguiente modelo lógico para la trazabilidad de los trámites implementados. 

 

 

 

 

Descripción de las tablas

 

Nombre de la tabla

Descripción de la tabla

Nombre del campo

Descripción del campo

Tipo de dato del campo

Ejemplo

GOBC_TIPO_SOLICITUD

Catálogo de tipo de solicitudes 

ID_TIPO_SOLICITUD

Identificador único del tipo de solicitud

NUMBER

 

DES_TIPO_SOLICITUD 

Descripción del tipo de solicitud. 

VARCHAR(50)

Petición

Respuesta

FEC_BAJA

Fecha que indica el momento que será dado de baja lógica del registro

DATETIME

 

GOBC_ESTATUS_TRANSACCIO NAL 

DES_ESTATUS_TRANS 

DES_ESTATUS_TRANS 

Identificador único del estatus de la transacción.

NUMBER

 

DES_ESTATUS_TRANS 

Descripción del estatus de la transacción 

VARCHAR(50)

Recibido

En ejecución

Cancelado

Terminado

FEC_BAJA

Fecha que indica el momento que será dado de baja lógica el registro.

DATETIME

 

GOBC_ESTATUS_TRAMITE

Catálogo de estatus del trámite.

ID_ESTATUS_TRMITE

Identificador único del estatus del trámite

NUMBER

 

DES_ESTATUS_TRAMI TE

Descripción del estatus del trámite. 

VARCHAR (50)

Registrado

Procesado

Pagado

Cancelado Exitoso 

FEC_BAJA

Fecha de baja del registro 

DATETIME

 

GOBC_COMPONENT

Catálogo de componentes 

ID_COMPONENTE 

Identificador único del escenario / componente

NUMBER

 

DES_COMPONENTE

Nombre del componente

VARCHAR(50)

 

ID_INSTITUCION

Identificador único de la Institución dueña o administradora del componente.

CHAR(10)

 

FEC_BAJA

Fecha de baja del registro 

DATETIME 

 

GOBT_TRAZABILIDAD

Tabla transaccional

para el registro de trazabilidad de

ID_TRAZABILIDAD

Identificador único del evento de trazabilidad, es una secuencia numérica por la tabla

NUMBER

 

ID_UNICO_TRAMITE

Concatenación de caracteres para la identificación única del trámite. De acuerdo a lo

siguiente:

Sector+Institución+Homoc

lave+Consecutivo(

6 dígitos)

VARCHAR

 

ID_CADENA_INTEROPER

Identificador de la cadena

de interoperabilidad

NUMBER

 

ID_HOMOCLAVE

Identificador del trámite

correspondiente al CNTS

CHAR(10)

 

ID_INSTITUCION

Identificador único de la

Institución a la cual pertenece el trámite.

CHAR(10)

 

ID_TIPO_SOLICITUD

Identificador único del tipo

de solicitud

NUMBER

 

ID_ESTATUS_TRANS

Identificador único del estatus de la transacción

NUMBER

 

ID_ESTATUS_TRAMITE

Identificador único del

estatus del trámite

NUMBER

 

ID_COMPONENTE

Identificador único del

componente

NUMBER

 

ID_SOLICITANTE

Identificador único del

solicitante del trámite

NUMBER

 

STP_TRANSACCION

Fecha en que se realiza la

transacción

TIMESTAM

PS(yyyyM

MddT2hh:

mm:ss.999

24hrs)

 

REF_TOKEN_SESION

Referencia del token de la

sesión

STRING

 
 

REF_FOLIO_PETICION

Referencia del folio de la

petición

VARCHAR( 25)

 

 

 

 

Con la finalidad de conocer el modelo lógico para la trazabilidad de los trámites implementados, se hace necesario llenar las siguientes tablas:

 

GOBT_CADENA_INTEROPER

ID_CADENA_INTEROPER (FK)

ID_HOMOCLAVE (FK)

ID_INSTITUCION (FK)

NUM_ORDEN_EJECUCION

       

 

GOBT_TRAZABILIDAD

ID_TRAZABILIDAD

ID_UNICO_TRAMITE

ID_CADENA_INTEROPER (FK)

ID_HOMOCLAVE (FK)

ID_INSTITUCION (FK)

ID_TIPO_SOLICITUD (FK)

           

 

ID_COMPONENTE (FK)

ID_STATUS_TRAMITE (FK)

ID_STATUS_TRANS (FK)

ID_SOLICITANTE

STP_TRANSACCION

REF_TOKEN_SESION

REF_FOLIO_PETICION

             

 

GOBC_COMPONENTE

ID_COMPONENTE

DES_COMPONENTE

FEC_BAJA

ID_INSTITUCION (FK)

       

 

GOBC_TIPO_SOLICITUD

ID_TIPO_SOLICITUD

DES_TIPO_SOLICITUD

FEC_BAJA

     

 

GOBC_STATUS_TRANSACCIONAL

ID_ESTATUS_TRANS

DEF_ESTATUS

FEC_BAJA

     

 

GOBC_STATUS_TRAMITE

ID_ESTATUS_TRAMITE

DES_STATUS_TRAMITE

FEC_BAJA

     

 

 

Catálogo de Estatus

 

Se define el catálogo de estatus que será utilizado para lograr la trazabilidad de los trámites, esto permitirá conocer en todo momento el estatus actual del trámite.

 

GOBC_ESTATUS_TRAMITE

Clave de estatus

Estatus

Comentarios

1

Registrado 

Registro de la solicitud del trámite

2

Iniciado 

Trámite iniciado

3

En proceso

Trámite en proceso

4

Detenido 

Trámite detenido por falta de requerimientos

5

Reactivado

Trámite reactivado

6

Pagado

Pago realizado para el trámite

7

Cancelado

Trámite cancelado

8

Terminado

Trámite finalizado con éxito

9

Rechazado

Trámite rechazado

 

  1. Firmas de elaboración, revisión y aprobación

En este apartado se deberán asentar los nombres y cargos de los servidores públicos responsables de la elaboración, revisión y aprobación del documento, incluir las firmas autógrafas de los mismos

 

 

G03-F03 Propuesta Procesos Tipo

Objetivo del documento

El presente documento tiene como propósito presentar la propuesta de una plantilla de proceso tipo con el fin de promover la reutilización de componentes entre las Instancias involucradas en los proyectos de Interoperabilidad.

 

Los Procesos Tipo son los procesos reutilizables en el procedimiento de negocio del Trámite o Servicio que se desea implementar en un entorno de interoperabilidad.

 

Para que un proceso de la Institución se pueda considerar como: “proceso tipo”, deberá cumplir con las siguientes condiciones:

  • El proceso es común en el sector de la Institución o incluso algún sector externo.
  • El proceso tiene las mismas interacciones entre roles para más de un trámite o cadena de interoperabilidad
  • El proceso resuelve parte del negocio de más de un trámite registrado

 

  1. Diagrama del proceso

Se diseña el “Diagrama de Flujo del Proceso Tipo” actual.

Para el diseño del diagrama de flujo se utilizará la herramienta “Creately”, https://creately.com/ es un software en línea para la creación de diagramas de flujo entre otros tipos de diagramas, se tiene a disposición características de la herramienta de  “Creately Diagramador en Línea

 

 

 

 

  1. Justificación

Proporcionar la justificación del uso del Proceso Tipo seleccionado. 

 

  1. Relación e integración de procesos

Se describe en una tabla la información relevante del proceso que se propone como plantilla de proceso tipo, teniendo las columnas de:

  • Proceso: Corresponde a cada uno de los procesos identificados en el “Diagrama de Flujo del Proceso”
  • Propósito: Descripción de forma detallada del proceso 
  • Entradas/Salidas (insumos y productos): De acuerdo a la relación de productos del proceso y a los diagramas de flujo de información del proceso y los relacionados con éste. Se consideran los datos que son utilizados en dicho proceso.
  • Responsable: Se define el responsable del proceso, debe ser coherente al “Diagrama de Flujo del Proceso”

 

#

Proceso

Propósito

Entradas / Salidas

Responsable

 

[proceso 1]

     
 

[proceso 2]

     
 

[proceso 3]

     
 

...

     
 

...

     
 

[proceso N]

     

 

  1. Firmas de elaboración, revisión y aprobación: En este apartado se deberán asentar los nombres y cargos de los servidores públicos responsables de la elaboración, revisión y aprobación del documento, incluir las firmas autógrafas de los mismos.

 

 

G03-F04 Propuesta Procesos to-be 

 

Objetivo del documento

 

Los “Procesos to-be” son la propuesta de mejora de los “Procesos Tipo” identificados anteriormente, tiene el objetivo de crear o diseñar nuevos y mejores desarrollos, más eficaces y eficientes.

 

  1. Diagrama del proceso to-be

 

Diseño del Proceso To Be: Se diseña el “Diagrama de Flujo” de la propuesta del Proceso to-be, en base al documentado en la “Formato G02-F02 Propuesta Procesos Tipo”, con el objetivo de mejorar y agilizar el proceso en base a la interoperabilidad. 

 

  1. Justificación

Proporcionar la justificación de la propuesta del proceso to-be. 

 

  1. Relación e integración de procesos to-be

Definición de las actividades del proceso: ser tan simple como sea posible, idealizando actividades fáciles de entender y de explicar. 

 

La “Relación e integración de procesos to-be” muestra información relevante de las mejoras del proceso propuesto, teniendo las columnas de:

  • Proceso: Corresponde a cada uno de los procesos identificados en el “Diagrama de Flujo”
  • Propósito: Descripción de forma detallada del proceso 
  • Entradas/Salidas(insumos y productos): De acuerdo a la relación de productos del proceso y a los diagramas de flujo de información del proceso y los relacionados con éste
  • Responsable: Se define el responsable del proceso, debe ser coherente al “Diagrama de Flujo del Proceso”

 

#

Proceso

Propósito

Entradas / Salidas

Responsable

 

[proceso 1]

     
 

[proceso 2]

     
 

[proceso 3]

     
 

...

     
 

...

     
 

[proceso N]

     

 

  1. Firmas de elaboración, revisión y aprobación:

En este apartado se deberán asentar los nombres y cargos de los servidores públicos responsables de la elaboración, revisión y aprobación del Reporte, así como las firmas autógrafas de los mismos