Projeto de Implantação do SEI

Hipátia é um modelo de preservação digital que visa implantar os Repositórios Arquivísticos Digitais Confiáveis, garantindo toda a cadeia de custódia dos objetos digitais arquivísticos. Ele integra os sistemas barramento Hipátia, Archivematica e AtoM.

Para a implantação do Hipátia é necessária a configuração de módulos relacionados ao sistema pré-configurado que deverá recuperar informações necessárias para a preservação digital, sendo nesse caso o do SEI.

1 curtida

IMPLANTAÇÃO DO RDC-ARQ (GUARDA E PRESERVAÇÃO) AO SISTEMA ELETRÔNICO DE INFORMAÇÕES SEI

Para a implantação de um RDC-Arq é necessário que algumas pontas se encaixem, tais como o Sistema Informatizado de Gestão Arquivística de Documentos - SIGAD, local que são produzidas as documentações em suporte digital, o sistema que cuida da preservação digital e do acesso, que inclusive pode ser segregado em mais de um sistema como é o caso do Archivematica (preservação) e AtoM (acesso) e além desses alguma ferramenta que realize a interoperabilidade entre ambos a qual no projeto IBICT é o caso do Hipátia.

Em relação ao SIGAD estudado para o projeto é o Sistema Eletrônico de Informações – SEI. Em 08 de fevereiro de 2023, o sistema encontrava-se na versão 4.0.9 e ainda não possuía ferramentas ou módulos necessários à gestão do documental de seus processos e documento, pelo menos não homologados pela desenvolvedora líder, Tribunal Regional Federal da 4ª Região - TRF4.

Com isso, a dificultava estava em identificar no SEI os processos e documentos cuja destinação seja permanente e que estejam aptos ao recolhimento para um repositório digital, além da adversidade de ter que localizar os metadados obrigatórios a serem integrados ao pacote de preservação final indicados pelo e-Arq Brasil, a Resolução nº 43 do CONARQ e outros mais.

Sendo assim, o projeto de pesquisa, além do barramento tecnológico Hipátia, ainda encontrou esses problema e visava buscar soluções tanto para o SEI quanto para o barramento de forma que pudessem ser validados ao modelo OAIS, salvo ainda a necessidade de garantir a cadeia de custódia entre as soluções.

Em suma, a implantação do RDC-Arq de Guarda e Preservação no SEI, é necessário o cumprimento de algumas etapas, tais como a definição de regras de gestão documental ao SIGAD, necessidade de recolhimento de metadados mínimos definidos pelas normas e-Arq Brasil e outras, a fase de encapsulamento dos documentos e dos metadados em formatos nos pacotes e, por fim, a transferência desse pacote ao Archivematica.

FASE 1: IDENTIFICAÇÃO DOS PROCESSOS APTOS À GUARDA E PRESERVAÇÃO

No primeiro momento, o projeto visou estudos das bases de dados do SEI, além das informações dos retornos de seus Webservices, a fim de localizar todos os metadados necessários à preservação, compatíveis aos metadados das principais normas arquivísticas, como o e-Arq Brasil e outros.

A partir dos estudos de metadados, identificou-se a necessidade de complementação de metadados, tais como os de gestão, com isso foi identificado a possibilidade de se desenvolver formulários eletrônicos (e-Forms) no SEI, cujos dados são tabulados em tabelas da base de dados, ou seja, dados segregados em campos de tabela que permitam a fácil recuperação por meio de comandos SQL, juntamente com os outros dados recuperados.

A proposição do e-Form “Termo de Arquivamento de Processo – TAP” deve fazer parte como documento fundamental para o marco inicial de um processo arquivado. Nesse formulário eletrônico existem informações como a Classificação do Processo, a Destinação Final do Processo, a Data de início e fim do arquivamento, dentre outras informações fundamentais que compõem os metadados arquivísticos e de gestão.

Outro formulário eletrônico proposto foi o Termo de Desarquivamento de Processo – TDP, caso haja necessidade do desarquivamento do processo, sendo assim a inclusão desse documento no processo, então é interrompido o prazo e a contagem recomeça quando há a inserção de um novo TAP ao processo e o seu devido encaminhamento à unidade responsável pelo arquivamento do processo.

Nessa fase ainda de determinação dos processos que se encontram aptos à preservação digital, também há a necessidade de que todos os processos:

  • sejam encaminhados a uma única unidade em que poderá ter a sua classificação analisada e revisada;

  • recebam o TAP com as devidas informações de preservação;

  • no caso do Arquivo Nacional – AN, sejam incluídos em um bloco interno cujo ID é o número 43;

  • sejam sobrestados para evitar que o processo possa ser reaberto por outra unidade e receba a inclusão de algum documento ou tenha algum andamento, sem que esteja devidamente desarquivado.

Logo, a execução do Hipátia, nesse caso, foi implementado para realizar a busca, por meio de query, nas bases de dados do SEI os processos que estejam situados, conforme todas as características dos passos listados anteriormente. Essa execução é realizada de tempos em tempos por meio de funcionalidade denominada por “cron”, ou seja, software de agendamento de tarefas programadas.

A query a seguir é um exemplo dos procedimentos configurados para recuperação dos processos que serão recolhidos, conforme regra mapeada. O retorno dela permite listar o id_protocolo e o protocolo_formatado de todos os processos aptos ao recolhimento.

SELECT p2.id_protocolo, p2.protocolo_formatado
FROM documento d
inner join protocolo p on d.id_documento = p.id_protocolo
inner join rel_protocolo_protocolo rpp on rpp.id_protocolo_2 = p.id_protocolo
inner join protocolo p2 on p2.id_protocolo = rpp.id_protocolo_1
–inner join atividade atv on p2.id_protocolo = atv.id_protocolo
WHERE d.ID_SERIE = 9 and p.sta_estado != ‘2’ and p2.sta_estado = ‘1’
– documentos assinados
and exists (
select * from assinatura ass where ass.id_documento = d.id_documento
)
– verifica se está aberto na unidade DIPAR
and exists (
select *
from atividade atv2
where atv2.id_protocolo = p2.id_protocolo and atv2.id_unidade = 110000018 and atv2.dth_conclusao is null
)
– encontra-se no bloco interno 43
and exists (
select * from bloco bl inner join rel_bloco_protocolo rbp on bl.id_bloco = rbp.id_bloco where p2.id_protocolo = rbp.id_protocolo and bl.id_bloco = 43
)
– verifica se não tem TDP após um TAP
and NOT exists (
select *
from documento d2
inner join protocolo p3 on d2.id_documento = p3.id_protocolo
inner join rel_protocolo_protocolo rpp2 on rpp2.id_protocolo_2 = p3.id_protocolo
inner join protocolo p4 on p4.id_protocolo = rpp2.id_protocolo_1
where p4.id_protocolo = p2.id_protocolo and d2.id_serie = 18 and p3.sta_estado != ‘2’ and rpp2.sequencia > rpp.sequencia
and exists (
select * from assinatura ass2 where ass2.id_documento = d2.id_documento
)
)
– destinação guarda permante
and exists (
select *
from protocolo p5
inner join rel_protocolo_protocolo rpp5 on p5.id_protocolo = rpp5.id_protocolo_2
inner join protocolo p6 on rpp5.id_protocolo_1 = p6.id_protocolo
inner join rel_protocolo_atributo rpa5 on p5.id_protocolo = rpa5.id_protocolo
inner join atributo a5 on a5.id_atributo = rpa5.id_atributo
inner join tipo_formulario tf5 on tf5.id_tipo_formulario = a5.id_tipo_formulario
where p6.id_protocolo = p2.id_protocolo and tf5.id_tipo_formulario in (2) and a5.nome = ‘destinacao’
and rpa5.valor = ‘1’
)
– data atual maior que a data de destinação final
and exists (
select *
from protocolo p5
inner join rel_protocolo_protocolo rpp5 on p5.id_protocolo = rpp5.id_protocolo_2
inner join protocolo p6 on rpp5.id_protocolo_1 = p6.id_protocolo
inner join rel_protocolo_atributo rpa5 on p5.id_protocolo = rpa5.id_protocolo
inner join atributo a5 on a5.id_atributo = rpa5.id_atributo
inner join tipo_formulario tf5 on tf5.id_tipo_formulario = a5.id_tipo_formulario
where p6.id_protocolo = p2.id_protocolo and tf5.id_tipo_formulario in (2) and a5.nome = ‘data_destinacao’
and CURDATE() > STR_TO_DATE(rpa5.valor, ‘%d/%m/%Y’)
);

Obs.: d.ID_SERIE = 9 e d2.id_serie = 18 devem ser substituídos em produção pelos códigos TAP e TDP de produção.

Resultado:

  • id_protocolo: código identificador do processo no SEI.
  • protocolo_formatado: equivale ao número do processo.
  • prazo: soma dos prazos intermediários e correntes das classificações do processo (assunto), somente da maior classificação.
    Data_arquivamento: data que o processo foi sobrestado e considerada para arquivamento do processo.
  • Data_final: data final para arquivamento e envio para o Archivematica, ou seja, soma a data do arquivamento e do prazo.
  • Data_atual: data do dia da execução da query.

Todos esses procedimentos foram adotados, em virtude da ausência de uma módulo de gestão documental ou arquivístico, sendo precedido inclusive de atividades anteriores tal como o mapeamento de metadados existentes e de metadados necessários para serem incluídos no arquivamento.

3 curtidas

Sensacional o trabalho realizado. Gostaria de saber se o desenvolvimento do barramento do Hipátia deu origem ao Módulo de Gestão Documental do Super.GOV.BR.

Olá Willian, obrigado pelo contato. Esse trabalho tem sido um grande desafio mesmo. Não tivemos contato com o desenvolvimento do módulo no SuperBR.

Obrigado,

Marcos Sigismundo

1 curtida

Prezados, em relação ao transferência/recolhimento dos documentos via barramento, como isso foi realizado tendo em vista os PDFs com marca e sem marca? Digo, os PDFs com QR Code, Assinaturas, Marca d’água… Esses também foram adicionados aos pacotes ou apenas o PDFs sem marcas?

1 curtida

Bom dia! Você se refere aos documentos gerados pelo próprio SEI? Se sim, pela API é possível coletar o documento completo com o cabeçalho e o rodapé com as assinaturas e QRcode.