procedimientos externos e internos

La funcionalidad necesaria para la tramitación electrónica, en general es distinta si se trataba de procedimientos internos y externos.

Actualmente gestionamos los procedimientos Externos:

• Procedimientos que afectan a cualquier colectivo (ciudadanos, empresas, administraciones, funcionarios) en los que esas personas (físicas o jurídicas) van a actuar como interesados, o bien a través de los mecanismos de representación habilitados.
• Para estos procedimientos externos, las aplicaciones informáticas gestionan de la misma forma la información de identificación del interesado, la firma, los datos de notificación, los datos de tasas, los pagos, etc. Es independiente de que el interesado sea un ciudadano, una empresa, una administración o un funcionario.
• En general estos procedimientos estarán publicados en la SEDE y aunque el procedimiento se inicie de oficio, y por tanto no haya “solicitud”, podrán existir otros tramites posteriores del mismo procedimiento que puedan ser realizados por los interesados. Estos serán los tramites DI que haya seleccionado el responsable del procedimiento en DEXEL (DI006 Aportación de documentación, DI002 solicitud de medidas provisionales, DI003 Solicitud de acumulación procedimientos,…).
• Estas solicitudes y trámites que llegan telemáticamente al Departamento Tramitador, se categorizan para que las aplicaciones puedan automatizar las acciones posteriores (solicitud SEDE específica, solicitud SEDE genérica, solicitud presencial, tramite SEDE, tramite presencial….)
• A partir de esas categorías, la aplicaciones (o los gestores) crean los expedientes (si las entradas son solicitudes) o las incorporan a expedientes ya existentes (si las entradas son otros trámites). La automatización se consigue en función del tipo de solicitud, pues se tiene más información cuando el trámite es telemático (frente al presencial) o si la solicitud es especifica o genérica.

Esta pendiente el tratamiento de los procedimientos internos.

• Procedimientos en los que no intervienen interesados. Los solicitantes son los propios departamentos de la administración en el ejercicio de sus competencias. Estos hacen solicitudes “internas” a otros departamentos de la CARM que tramitan estos procedimientos internos. Aquí evidentemente no tienen sentido aplicar los mecanismos de representación. (pueden ser casos típicos las solicitudes de modificación de crédito, solicitudes de informe jurídico, etc…)
• Como no hay interesados, no es necesario pedir la información normalizada que se recoge en la presentación de trámites externos (datos de interesados, formas de Notificación, Direcciones, tasa, pagos…)
• En cuanto a la identificación y la firma tampoco se trata como en los procedimientos externos. En estos casos, es muy habitual que el funcionario que hace la solicitud no sea el firmante, sino que esta la firme el Jefe de servicio o el Director General del departamento solicitante.
• A diferencia de las solicitudes de tramites externos que llegan directamente al departamento tramitador, las solicitudes internas se realizan mediante comunicación interior, dejado evidencias con los “acuses de envío” en el departamento emisor y el “acuse de recepción” del departamento receptor. Estas evidencias son importantes en la tramitación interna y se generan automáticamente en estas solicitudes internas.
• Estos procedimientos, también estarían definidos en DEXEL, pero no se publicarían en la SEDE puesto que no afectan directamente al ciudadano, ni les interesa la información sobre su tramitación, plazos, etc. La información de estos procedimientos estaría publicada en la INTRANET (en una guía interna similar a la externa) donde todos los departamentos que las van a utilizar podrían conocer los plazos, solicitudes, formularios específicos si existen, etc. Esta guía interna solo proporcionaría información para la tramitación interna.

Con este criterio, los procedimientos de RRHH en los que los “funcionarios” fueran interesados, se definirían en DEXEL como externos. Tampoco la forma de inicio (de oficio o a instancias del interesado) determinaría que el procedimiento fuese interno, pues no nos limitamos a gestionar las solicitudes.

Como alternativa, podemos hacer que para esos procedimientos de RRHH definidos en DEXEL como “internos”, las aplicaciones se comporten como hemos descrito en los “externos”. Para ello, deberíamos añadir en DEXEL un nuevo destinatario “funcionario”.

De esta forma cuando el procedimiento fuera “interno” y el destinatario fuera “funcionario”, las aplicaciones los gestionarían de la misma forma que los “externos” (autenticación, firma, notificaciones, tasas-si tienen-, publicación en SEDE, etc...).

Mientras que el los formularios externos utilizan el presentador los formularios de procedimientos internos utilizan un presentador interno especial:

Formulario específico

Autenticación: Con PASE (login corporativo + certificado) con QAA
Autorización: Se realiza en el primer formulario mediante consulta a DEXEL con: UBICACION

Datos que se recogen:

• Fecha de la grabación - solicitud (Obligatorio)
• Solicitante: (Opcional)
• Login
• NIF
• Origen: UBICACION (Opcional)
  • Destino: (Obligatorio)
  • Procedimiento (la del formulario específico)
• Departamento tramitador (puede ser un desplegable)
• Clase de documento (Obligatorio) [Metadato del formulario]
• Firmantes (Opcional)
• Referencia ENI del documento (Obligatorio)
• Referencia de la solicitud (Obligatorio)

XML de control: Se forma con Datos que se recogen. Se contempla el uso de una sección abierta clave-valor (elemento dinámico) Parámetros que se pasan:

• Referencia ENI del XML de control.

Se generan:

• Documento PDF (a firmar en el presentador)

Presentador para trámites internos

Parámetros que se reciben:

• La referencia ENI del XML de Control.

Operaciones:

• Leer XML de control
• Autenticación (opcionalmente)
• Autorización (se hace contra DEXEL)
• Obtener documento
• Pedir los datos opcionales que no se hayan recibido en el XML de Control:
  • Origen: UBICACION
  • Firmantes (pantalla con tantos pasos como firmantes se añaden estilo DELFOS)
  • -Nombre del paso de firma
  • -Email
  • -Botón “Comprobar firmante” (servicio portafirmas)
• Anexar página al PDF con los datos añadidos.
• Generar solicitud (llamada a firmaDocumentos@SANDRA).
• Guardar en BBDD (los valores del XML de Control + Id. de Portafirmas).

Requisitos:

Debería ser compatible con los formularios JDAD (hacerlo como Presentador). Si el XML de control no contiene los datos del solicitante, debe autenticar al usuario.