Trata o presente documento, de análise de sistema elaborada pela Gerência de TI, tendo por escopo a o desenvolvimento do sistema de apoio ao Controle Externo no recebimento das informações de prestação de contas dos jurisdicionados do TCE-GO.

O Sistema de controle externo tem como referência a PORTARIA XXX/2016.

O Controle Externo do TCE-GO apura as atividades dos jurisdicionados do Estado de Goiás, por diversos meios de apresentação das atividades executadas, como processos de admissão de servidores estatutários ou comissionados, processos de licitação e contratação, sejam exigida a licitação ou dispensada, dispensável ou inexigido, movimentação contábil e orçamentária, em processo físico ou carga de dados por meio de processo informatizado.

Atualmente essas apurações prestadas contas não estão centralizadas e não seguem um padrão quanto a forma e nem quanto ao formato das informações, o que impossibilita a utilização de mecanismos computacionais no auxílio do manuseio das informações.

Com a reformulação da CASP (Contabilidade Aplicada ao Setor Público), faz-se necessário criar sistemas de apoio visando controlar e auditar a contabilidade, com base nos novos requisitos apresentados.

Devido a essa nova necessidade de recebimento de informações contábeis, e para que seja possível receber informações de outras matérias como Orçamento, Operacional, Financeiro e Patrimonial, o sistema de Controle Externo deverá possibilitar o recebimento dessas matérias e de outras matérias futuramente necessária para atender a missão do TCE-GO.

O sistema de Controle Externo irá controlar o recebimento das informações por período de prestação de contas e por matéria da informação. Para que o sistema possa recepcionar as informações das matérias e em formado determinado, o sistema deverá possibilitar que o Controle Externo configure o formato das informações que compõe cada matéria configurada, para ser entregue no período de entrega configurado.

A configuração do formato das informações deverá possibilitar que novos layouts de informações sejam criados e disponibilizados para serem prestadas contas no controle de recebimento das informações.

O controle de recebimento das informações deverá determinar o período e movimentação das atividades dos jurisdicionados que deverá ser prestadas contas, durante o prazo de entrega das informações.

A prestação de contas realizadas pelos jurisdicionados, para determinado período de apuração das atividades, pode ocorrer de não ter movimentação. Tendo esse conhecimento, o controle de recebimento das informações deverá recepcionar as informações de prestação de contas, de modo a identificar os períodos sem movimentação declarada.

A prestação de contas para cada controle de prestação de contas, para cada jurisdicionado, será singular. Dessa forma, a correção das informações antes enviadas ao TCE-GO, deverá ser realizada via retificação.

As informações recepcionadas pelo sistema de Controle Externo serão controladas e mantidas pelo TCE-GO, para que sejam integradas e processadas nas atividades de controle e auditoria, com base na Legalidade, Legitimidade e Economicidade.

1. O sistema de Controle Externo deverá disponibilizar Serviço Web (Web Services) que permita que os jurisdicionados possam integrar seus sistemas das matérias Financeira, Operacional, Contábil, Orçamentário e Patrimonial, para que o processo de prestação de contas possa ser realizado automaticamente de forma integrada.
2. Para que o sistema possa ser acessível também para os jurisdicionados com deficiência de infraestrutura de TI, o sistema de Controle Externo deverá disponibilizar um portal Web para que estes jurisdicionados possam prestar as contas nos períodos determinados.

A proposta de solução descrita neste escopo é uma sugestão e poderá sofrer mudanças durante o processo de desenvolvimento, caso se identifique a necessidade.

O controle de prestação de contas, identificado aqui na proposta de solução como Calendário de Obrigações, deverá determinar o período de prestação de contas separada por matéria de informação, identificadas nessa proposta de solução como Dimensão.

O Calendário de Obrigações por Dimensão terá data de início de prestação de contas e data final opcional. A data final quando não informada será considerado sem data de término, podendo a qualquer momento ser fechada a data de término do período de prestação de contas, não podendo ser data menor que a data da ultima prestação de contas realizada para o Calendário de Obrigações, caso isso ocorra, o sistema deverá apresentar uma mensagem ao usuário informando que não é possível salvar o Calendário de Obrigações por que existe prestação de contas de apurações com data superior a data final informa.

Para cada Calendário de Obrigações deverá ser determinada a lista de layouts de informações (apurações) irá compor o calendário, sendo estes layouts do mesmo tipo da Dimensão. Juntamente com cada layout de informação deverão ser informados os períodos de movimentação das atividades que deverão ser apresentadas na prestação de contas. Os períodos de atividade de cada layout não poderão sofrer intersecção. Dessa mesma forma, o Calendário de Obrigações para a mesma Dimensão, o período de prestação de contas não poderá sofrer intersecção.

Abaixo segue um modelo da rotina de controle de Calendários de Obrigações. Nessa rotina serão consultados os calendários cadastrados a partir da dimensão e das datas de início e fim da prestação de contas.

Quando o usuário alterar ou solicitar ao sistema a inclusão de um novo Calendário de Obrigações, o sistema irá apresentar a rotina do modelo abaixo apresentado, que ilustra a alteração da primeira linha da tabela apresentada na Figura 01, acima ilustrada.

Nessa rotina o usuário em criação de novo Calendário de Obrigações irá selecionar a Dimensão, a Data Inicial e a Data Final do período de prestação de contas, sendo este último opcional.

Nessa rotina de Manutenção do Calendário de Obrigações, o usuário poderá excluir ou alterar o layout da informação antes incluído no Calendário de Obrigações, sendo que a exclusão do layout somente será possível caso não tenha apuração de atividades já enviadas ao TCE-GO, na prestação de contas dos jurisdicionados.

A rotina abaixo ilustra a rotina de manutenção de layout de prestação de contas do Calendário de Obrigações. Nessa rotina o usuário informa o layout e versão, vinculado a Dimensão antes informada no cadastro do Calendário de Obrigações.

Nessa rotina o usuário poderá incluir, alterar ou excluir períodos de apuração das atividades realizadas pelos jurisdicionados, para o layout e versão informado. A exclusão do período de apuração de atividade apenas será possível quando o período de apuração não tenha prestação de contas vinculado.

O período de apuração das atividades, representada pela rotina ilustrada abaixo. O usuário irá informada a data de inicio e a data final do período de apuração da atividade para o layout e versão do Calendário de Obrigações selecionado. Para cada layout e versão do Calendário de Obrigações, poderão ser informados uma lista de períodos de apuração, sendo que as datas de cada período informado não podem sofrer intersecção.

A tela de Cadastro de Calendário Especial será acessada apenas pelo portal web. A tela apresentará todos os calendários especiais para o usuário administrador, permitindo a alteração e a inclusão de novos calendários. Existem também campos de filtro, que permitem ao usuário aprimorar a pesquisa.

Para incluir e filtrar um calendário de obrigações é necessário anteriormente selecionar o usuário, só então serão listados todos os calendários que o mesmo tem acesso.

Para inclusão, todos os campos são obrigatórios, para os filtros todos são opcionais. O campo Usuário Especial, é selecionado através de uma lista de usuários, o campo Calendário de obrigações é carregado após a seleção de um usuário. Data limite é um campo do tipo data com a data limite do calendário especial e Observação é um campo texto com as observações do calendário.

É possível excluir e alterar os calendários de obrigações inseridos.

A recepção de prestação de contas no sistema de Controle Externo deverá oferecer duas interfaces, uma via Portal Web e outra via Web Service.

Em ambas interfaces o usuário deverá ser autenticado, para então fazer uso dos serviços disponibilizando no portal e nos serviços do Web Service.

O usuário do jurisdicionado deverá ter permissão de acesso ao módulo de Controle Externo, bem como nas Dimensões de informações para que este possa utilizar os serviços do Portal Web, como a rotina de Importação de Arquivo para Prestação de Contas.

O arquivo importado pelo sistema deverá conter a identificação da Dimensão da informação, bem como o layout e versão de cara informação contida no arquivo, e o período de apuração das atividades a informação faz referência. Em posse dessas informações, o sistema de Controle Externo poderá identificar o Calendário de Obrigações, o Layout e Versão e o período de apuração das atividades, a fim de verificar se a prestação está dentro do prazo determinado e se o usuário tem permissão de prestação de contas para a dimensão do arquivo informado.

O Arquivo deverá conter no máximo a mesma quantidade de registros de informações configurada na tabela CEX_PARAMETROSGERAIS. Caso a quantidade ultrapasse o valor configurado o sistema deverá informar que a quantidade de informações não poderá ser importada e para o processamento.

O arquivo de prestação de contas deverá ser arquivo XML, no formato determinado no layout de prestação de contas, conforme apresentado e descrito na seção 7.3, deste documento.

Após a importação do arquivo, o sistema de Controle Externo irá apresentar um breve resumo do conteúdo do arquivo para o usuário então importar o arquivo, para prestação de contas.

O sistema de Controle Externo irá disponibilizar os seguintes serviços para os jurisdicionado via Web Service:

• Serviço de Comprovantes de Prestação de Contas
  • ConsulteProtocolos: consulta de protocolos de envio de prestação de contas a partir do usuário remetente da informação, o qual será o usuário autenticado.
  • ConsulteRecibosPorProtocolo: consulta de recibos de prestação de contas para o protocolo informado em que o remetente da informação seja o usuário autenticado.
• Serviço de Consulta de Andamentos da Prestação de Contas
  • Consulte: consulta os andamentos do processo de prestação de contas disponível para o usuário autenticado por Recibo de Informação. Em cada andamento terá uma breve descrição do processo executado no andamento, identificando em qual etapa do processo a informação prestada contas se encontra, e caso tenha, as críticas apontadas para as informações da prestação de contas.
• Serviço de Prestação de Contas
  • Enviar: nesse serviço o usuário irá enviar a prestação de contas das atividades para um Calendário de Obrigações, o qual contem uma lista de layouts de informações e para vários períodos de apurações de atividades. Cada informação de apuração de atividade será para um determinado layout e período de atividade. A prestação de contas enviada irá gerar um Protocolo de prestação de contas, e para cada informação de apuração de atividade, será registrado um Recibo de apuração, o qual será vinculado no sistema de Controle Externo ao Protocolo gerado.

A consulta de declarações contempla duas telas de pesquisa, a primeira que é a Consulta de Entrega de Declaração e a segunda que é a Consulta de Recibos da Entrega de Declaração, ambas especificadas em detalhes mais adiante. O objetivo desta tela é concentrar as consultas das declarações enviadas ao Tribunal de Contas do Estado de Goiás.

Esta consulta busca todas as entregas de declaração, isto é, todos os pacotes de informações entregues pelo jurisdicionado. Nessa funcionalidade, por padrão o sistema irá consultar todas as entregas ordenando-as em ordem decrescente de data de entrega. Porem, o usuário também contará com a possibilidade da consulta por número da entrega e pelo período da entrega.

Depois de realizada a pesquisa será exibida uma tela com a relação de todas as entregas realizadas pelo jurisdicionado conforme a pesquisa padrão ou a pesquisa realizada utilizando os filtros. Na relação de entrega apresentada, caso haja alguma entrega, será exibido para o usuário o número da entrega, a situação (se concluído ou não), o jurisdicionado remetente, a data da entrega, a hora da entrega, o hashing do pacote entregue, a quantidade de informações recusadas, a quantidade de informações que foram canceladas pelo jurisdicionado, e por fim, a quantidade de informações aceitas pelo sistema ContEx. Na coluna titulada Ações, serão apresentados dois botões quando a entrega estiver sido concluída, sendo o primeiro a consulta da relação de informações entregues, na qual será listados os Identificadores Único, a crítica identificada no recebimento que impossibilitou a recepção dessa informação, e caso a informação tiver sido aceita na coluna Ações será apresentado um botão para consultar o recibo da informação. E o segundo botão corresponde a consulta de todos os recibos das informações aceitas pelo sistema.

A consulta de recibos da declaração pode ser realizada através da consulta pelo número da entrega, como apresentado na figura 1 da proposta de tela apresentado abaixo. Também será possível consultar os recibos da declaração através do botão Consulta recibos das informações da declaração na coluna Ações, do resultado da consulta de declaração, como apresentado na figura 2 da proposta de tela. E por por último, através do resultado da consulta dos itens da declaração, no qual será possível consultar o recibo relacionado ao item, com apresentado na figura 3 da proposta de tela, apresentado abaixo.

O resultado da consulta de recibos da declaração apresenta todos os recibos gerados para cada informação contida na declaração. Nessa relação é apresentado o número do recibo, identificador único, o hashing da informação, quantidade de arquivos vinculados a informação, situação do arquivo junto ao TCE, identificador se teve movimentação e o período de apuração a informação corresponde, conforme figura 4.

Na relação de recibos apresentada, na coluna Ações o usuário poderá visualizar os andamentos que cada recibo já teve, como apresentada na figura 5. E na consulta de andamentos do recibo, o usuário poderá expandir o conteúdo para consulta as críticas do andamento, caso a situação do recibo no andamento seja Informação Inválida ou Homologado com Críticas.

Na coluna Ações também será possível imprimir o comprovante do recibo, o qual apresenta as principais informações do recibo, como apresentado na figura 6.

Esta funcionalidade será responsável por consultar todas as entregas dos recibos conforme calendário informado, isto é, todos os pacotes de informações entregues pelo jurisdicionado ao TCE. Nessa funcionalidade, o usuário irá informar o calendário de obrigações, e também poderá informar o período entre dadas para melhor filtro das informações.

Depois de realizada a pesquisa será exibida uma tela com a relação de todas as entregas realizadas pelo jurisdicionado conforme filtros informados. Na relação de entrega apresentada, caso haja alguma entrega, será exibido para o usuário o número da entrega, a situação (se concluído ou não), o jurisdicionado remetente, a data da entrega, a hora da entrega, a descrição da declaração, o hashing do pacote entregue, a quantidade de informações recusadas, a quantidade de informações que foram canceladas pelo jurisdicionado, e por fim, a quantidade de informações aceitas pelo sistema ContEx. Caso aja informações de arquivos enviados, o usuário poderá expandir os dados do recibo para visualizar os arquivos enviados para o mesmo, sendo que nessas informações, o usuário terá o nome do arquivo enviado, o hashing, o código do campo, a ordem do campo, o status, e por fim o período de execução do mesmo.

A tela de consulta de obrigações de prestação de contas no sistema de Controle Externo será acessada apenas pelo portal Web. Ao abrir a tela o sistema deverá carregar todos os calendários de obrigações existentes para o usuário cadastrado, ordenando pela data final.

A Grid apresentada deverá conter uma coluna com um indicador visual que identifique a situação do prazo, conforme informado na legenda do protótipo. Na coluna de ação cada linha deverá conter um link para o layout de prestação de contas equivalente, conforme descrito no item 7.3.1.

O Usuário ainda poderá pesquisar pelas datas de inicio e fim nos calendários cadastrados e também recarregar a consulta inicial através do botão “Todos”.

Tanto a alimentação quanto a disposição das notícias serão feitas no Context, serão criadas duas telas para atender a funcionalidade (conforme os protótipos a seguir). O levantamento de requisito com o PO, inviabilizou a componentização da seção de notícias do WebSite, pelo fato dos requisitos de UI serem bem específicos. No entanto será utilizado a mesma estrutura de banco existente para notícias, fazendo-se necessário algumas alterações na tabela e no serviço existente no Compartilhado.

Manual de Integração com mais detalhes de como será disposto o XML

1. As notícias podem ser vinculadas a um calendário de obrigações. Estas serão mostrada apenas para os usuários que possuem acesso aquele calendário, e devem permitir a navegação do usuário para o detalhamento daquela obrigação;
2. O cadastro de notícia do Contex deve ser feito pelo Contex;
3. Ao publicar uma notícia no Context, o usuário pode optar por publicar no context e na intranet (no website) ou no context e na internet (no website);
4. A disposição da notícia na apresentação deve estar conforme o protótipo descrito nesta especificação;
5. As notícias que forem vinculadas a um calendário de obrigações deverão ser RESTRITAS AO CONTEXT.

Será necessário uma tabela WEB_NOTIRELACIONAPLI com ids de aplicação com acesso à notícia, uma nova entidade chamada WEB_NOTICHAVE relacionada à WEB_NOTIRELACIONAPLI que descreverá a relação lógica da tabela de notícias com a tabela de calendário e um tipo “E - Específico” no atributo TIPO_DIVULGA_A.

Viu-se necessário a criação da tabela intermediária que conterá todos os ids de aplicações que poderão visualizar determinada notícia (requisito 3). Ele determinará quais notícias serão mostradas no Context, através do identificador da aplicação, e terá a relação com uma tabela que determinará relacionamento lógico com chaves de outra tabela (no caso do context o calendário de obrigações). Na nova estrutura será criado o tipo de divulgação 'Específico' TIPO_DIVULGA_A = 'E', ele determinará se as tabelas de acesso será específico à aplicação.

A dropdown de calendário deve aparecer somente quando o radio button de “Apenas no Context” for selecionado requisito 5

Este protótipo se trata da tela inicial, a grid deve fazer a transição da notícia de 60 em 60 segundo apresentando a imagem de destaque, caso a pessoa clique na noticia, ela deverá retrair a imagem principal e mostrar o conteúdo da noticia da maneira que está descrito no protótipo. Deverá ser apresentado também o calendário caso a notícia esteja vinculada a um calendário, a grid deve conter paginação e permitir o usuário navegar para o detalhamento de obrigações daquele calendário ao clicar.

A recepção de declarações dos jurisdicionados precisão ser consolidadas no sistema Informa, o qual irá validar as informações se estão em conformidade com o leiaute do formulário configurado no Calendário de Obrigações da declaração.

Partindo da premissa que essa carga de informações de declaração poderá ter volumes expressivos de dados, e que vários jurisdicionados farão declarações durante todo o ano, para diferentes dimensões de informações. Esse processamento de dados será implementado em uma arquitetura de processamento em Microservices.

Veja o tópico RabbitMQ.

Veja o tópico RabbitMQ.

A Secretaria de Controle Externo para que possam verificar se os jurisdicionados estão entregando as declarações da execução de suas atividades sobre as matérias de apreciação do TCE-GO, quanto à legalidade, legitimidade e economicidade, e também para fins de registro, se faz necessário disponibilizar um relatório contendo a relação de jurisdicionados que devem prestar contas por Calendário de Obrigações.

A consulta do relatório será filtrada por Calendário de Obrigações, na relação da pesquisa deverá ser listados os jurisdicionados que tem permissão para determinada Dimensão. Nessa relação será apresentada para cada jurisdicionado a situação de sua declaração. Para calendários com data de prestação de contas já encerrado, será apresentada a situação da entrega da declaração se dentro ou fora do prazo (jurisdicionados que entregaram utilizando a funcionalidade de Calendário de Usuário Especial) e não declarado – para os jurisdicionados que não entregaram a declaração. Já para calendários em que o prazo de entrega da declaração que ainda estiver em curso, a situação de entrega da declaração dentro do prazo e ainda não declarada.

Na consulta do relatório não serão filtrados calendários em que o período de declaração ainda não tenha iniciado, dessa forma, o sistema irá informar o usuário que o calendário informado ainda não está em prazo de declaração.

Para os calendários que não tem data final, isto é, não tem data programada de término da obrigação da declaração, na apresentação do filtro desses calendários na descrição entre parênteses, só será informada a data de início da obrigação.

Na relação deve conter a situação da declaração no tocante à informação apresentada, se a informação está em situação “Recebido” (isso quer dizer que todos os recibos da informação estão em situação recebido), situação “Leiaute Críticado” (isso quer dizer que caso ao menos um recibo da informação estiver em situação Leiaute verificado com críticas), situação “Leiaute Conformidade” (situação de todos os recibos com movimentação estejam em situação Leiaute em conformidade), situação em “Homologação” (recibo de informação está em processo de verificação pelo Controle Externo do TCE-GO), situação “Regular com Ressalvas” (situação em que ao menos um recibo de informação esteja em situação de Regular com ressalvas), situação “Regular sem Ressalvas” (situação em que todos os recibos, com ou sem movimentação, estejam em situação de Regular com ressalvas), situação “Irregular” (situação em que ao menos um recibo de informação esteja em situação de Irregular) e situação “Pendente de Arquivos” (situação em que os Aquivos de Informação não possuir anexo).

Para os jurisdicionados já tenha declarado, será apresentado o último protocolo de declaração, sendo este o protocolo que não tenha sido retificado por nenhum outro protocolo. Através desse protocolo o sistema apresentará uma opção, na coluna ação, para o usuário consultar o protocolo e os recibos de informações da declaração, para que possa analisar de forma detalhada a situação das informações declaradas.

A consulta da relação de jurisdicionados por calendário de obrigações poderá ser exportada em formato PDF, XLS (Excel) ou CSV, utilizando o padrão do componente Dev Express.

Na coluna Declaração o filtro aplicado na grid, será com base nas informações podendo ser selecionado mais de um tipo, entre os quais estão Dentro do prazo, Fora do prazo e Não entregue.

Na coluna Situação da declaração, será aplicado o mesmo padrão de filtro da grid da coluna Declaração, permitindo que o usuário possa filtra com base nos tipos de situação da declaração da relação consultada, permitindo filtrar para mais de uma situação.

O sistema ContEx processa as informações contidas na declaração de cada calendário de obrigações, em duas etapas, que são:

A recepção dos dados via Web Service ou via portal do sistema ContEx, verifica se a declaração enviada pertence a um calendário, cujo período de envio da declaração está dentro do prazo ou se está em regime especial de entrega. Verifica também, o formato da declaração se está em conformidade quanto à especificação do arquivo de XML, quando declarado via portal do ContEx. O sistema verifica se cada informação contida na declaração pertence a uma configuração de layout configurada no calendário bem como o período de apuração das informações corresponde a um período configurado para o layout da informação, o qual é vinculado a um calendário de obrigações.

Nessa etapa as informações são controladas apenas pelo sistema ContEx, não são persistidas as informações em nenhum outro sistema.

Uma vez que as informações são registradas no sistema ContEx, é gerado um recibo para cada informação contida na declaração em situação Recebido, que indica que a etapa de recepção de dados foi concluída.

A etapa de verificação do Layout e registro no Informa, apesar de transparente para o Jurisdicionado o qual visualiza apenas a situação do recibo da informação, consiste na etapa de verificação da informação quanto a configuração do arquivo de layout da informação. Essa configuração do layout de informações está descrito na funcionalidade Consulta de Obrigações na seção 7.5 deste documento.

Os layouts das informações recebidas pelo sistema ContEx, são controladas e mantidas pelo sistema Informa, através das funcionalidade de Matriz de Formulários.

O sistema Informa, cujo escopo trata da recepção e gerenciamento de informações, as quais são recebidas através de formulários dinâmicos, que são modelados e mantidos pelo sistema, através do cadastro de formulários, sendo estes compostos por campos personalizados, e são agrupados por tipos de formulários de determinada categoria de informação. Essa infraestrutura de controle de informações será utilizado, pelo sistema ContEx, como repositório dos dados.

Dessa forma, o sistema Informa trata a complexidade de configuração dinâmica de formulários de informação, bem como do controle das informações enviadas para cada formulário dinâmico.

Baseado nessa funcionalidade, o sistema ContEx propõe a recepção de dados de informações agrupadas por Dimensões de Informação (Categorias de Informações do Sistema Informa) e configuradas por Arquivos de Layout (Formulários do sistema Informa, pertencente à categoria configurada). A tratativa da verificação da composição da informação e gerenciamento da informação de modo a disponibilizar a mesma para o Controle Externo e para outros sistemas será realizada pela informação contida no Informa.

Assim o ContEx irá gerenciar o andamento dessa informação, partindo do ContEx para o Informa, e do Informa para outros sistemas.

Com base no processo verificação da informação quanto ao layout e registro da informação no sistema Informa, o recibo da informação será atualizada para as seguintes situações:

• Informação Inválida – quando ocorrer alguma inconformidade da informação quanto ao layout do arquivo, e quanto a relacionamento de hierarquia de informações (informações pai e filhas). Caso o andamento do processamento do recibo da informação esteja nessa situação, o sistema ContEx, não gerou registro da informação no sistema Informa, e as inconsistências identificadas serão registradas na forma de Críticas no andamento da etapa de Verificação de Layout de Informação; e
• Informação Válida – quando as informações contidas na declaração estão em conformidade com a especificação do layout. Nessa situação, o recibo da informação estará vinculada a uma informação no sistema Informa.

Não obstante a essa sistemática, o controle da informação declarada é de responsabilidade do sistema ContEx. Para isso, o ContEx mantem uma declaração do jurisdicionado por calendário de obrigações. Durante o período de prestação de contas, isto é, dentro do período de recepção de dados de determinado Calendário de Obrigações, o Jurisdicionado poderá adicionar, cancelar ou retificar informações, sendo que para as duas útimas operações deverá estar identificado no atributo ReciboRetificado (via XML) e ReciboRetificadoId (via Web Service), o recibo da informação que queira cancelar ou retificar. Essas duas operações são identificadas a través do atributo TipoEnvio (EnumTipoEnvioInformacao.cs).

As três operações, adição, cancelamento e retificação poderão se realizadas em qualquer pacote de envio de informações (Declaração), respeitando apenas o limite de informações por envio determinada pelo TCE-GO. Dessa forma, o Jurisdicionado pode realizar alguma dessas operações no envio de declaração com apenas uma informação ou com várias informações, e não se restringindo a apenas uma dimensão.

Tomando como base todo o processo de controle das declarações apresentadas anteriormente, o processo retificação da declaração será apresentada abaixo:

Como apresentado nos Fluxogramas acima, o processo de Retificação e de Cancelamento da Informação, poderá ocorrer em dois momentos, dentro do prazo de recepção de declarações normal, e em regime especial de declaração.

Diferentemente do primeiro momento, a recepção de declarações em regime especial, no final do prazo de entrega especial o sistema ContEx irá gerar novo protocolo de entrega das declarações, o qual irá retificar o protocolo gerado anteriormente no encerramento da obrigação do Calendário de Obrigações.

Com base no fluxo do processamento das informações na recepção das declarações nas operações de entrega normal (adição de informações à declaração), retificação e cancelamento, podemos identificar o fluxo das situações do recibo da informação no ciclo de vida da mesma no sistema ContEx. Para melhor entendimento desse fluxo, segue abaixo os fluxos de estado do recibo e o fluxo de atividade mostrando a mudança de estado do recibo durante as atividades da Fase 1 - Recepção de dados e da Fase 2 - Aplicação de Regras de Negócio.

O processo de recepção de dados após gerar o protocolo da declaração, bem como os processos de integração da informação declarada com o sistema informa e o processo de retificação da declaração, ocorrerem de forma assíncrona, se faz necessário registrar Logs de inconsistência, erros ou falhas do sistema durante o processamento dessas etapas.

Uma vez que o sistema gera Logs contendo informações de situações não tratadas durante a execução dos processos das informações, se faz necessário que o sistema disponibilize para a equipe de TI, uma forma de apresentação dos Logs gerados, para que a partir da análise do conteúdo agrupado por processamento ou individualmente, possa ser planejado ações de correção e de contingenciamento para garantir a operação e disponibilidade do serviço de recepção de declarações do sistema ContEx.

Na consulta de Logs do Protocolo, o sistema irá apresentar o número do protocolo, a data da ocorrência do registro de log, a mensagem gerada pelo sistema e o jurisdicionado da declaração.

A consulta poderá ser filtrada por calendário de obrigações e período de recebimento da declaração, e poderá ser filtrada pelo número do protocolo, data contida na relação filtrada consultada, pela mensagem e pelo jurisdicionado.

O resultado da consulta poderá também, ser exportada em formato PDF, XLS e CSV.

Cada registro de log trará a opção para o usuário consultar o protocolo, levando o usuário para a rotina de consulta de protocolos já carregando o protocolo do log antes selecionado.

As declarações enviadas ao TCE possibilitará o envio de arquivos anexados à declaração, conforme configuração de cada layout da informação.

O processo de envio das declarações, como se trata de uma funcionalidade que permite que o jurisdicionado envie grandes volumes de dados, o envio de arquivos juntamente com essa opção de prestação de contas torna inviável, mesmo que tais arquivos sejam enviados em formatação Base 64.

Dessa forma, optou-se por enviar arquivos em anexo das informações declaradas separadamente, em um processo de recepção de arquivos, tanto via Web Service, quanto via Portal Web.

A regra de envio de arquivos da declaração deve respeitar duas etapas. A primeira etapa consiste em informar na declaração para campo do tipo arquivo informar na declaração no elemento XML Valor o nome do arquivo contendo a extensão do mesmo, e no elemento MD5Arquivo informar o hash no padrão MD5 do arquivo que será enviado posteriormente para validar se o arquivo enviado separadamente, de fato corresponde ao arquivo apresentado na declaração. E na segunda etapa, no envio do arquivo de fato, o jurisdicionado irá enviar o arquivo da declaração, via Portal web ou via Web Service.

No envio do arquivo, o jurisdicionado deverá informar para o sistema, o calendário vinculado a declaração antes enviada, o identificador único da informação da declaração, a qual o arquivo pertença, sendo que esse identificador único da informação é informado pelo usuário na declaração, e que o controle desse identificador é de responsabilidade do jurisdicionado, o ID do campo da declaração, e para campo em seção do tipo lista, deve informar o campo Ordem do Campo, o qual irá determinar para campo em seção lista, qual a linha da lista que o arquivo pertence.

Utilizando as informações de calendário, identificador único da informação, o ID do campo e o número da ordem do campo na lista, o sistema poderá identificar qual campo da informação o arquivo pertence.

A recepção de arquivos da declaração irá manter apenas um arquivo com as mesmas chaves, que o compõe, sendo elas o ID do Campo, Ordem do Campo, Número do Protocolo e Identificador único da informação.

A correção de arquivo enviado poderá ser realizada enviando o arquivo novamente. Esse processo de reenvio do arquivo, não altera a regra do hash do arquivo na declaração, nesse sentido, caso o arquivo corrigido altere o hash MD5 do mesmo, a declaração deverá ser retificada, informando o hash MD5 do arquivo corrigido, para depois enviar o arquivo corrigido informando o novo Número do Protocolo. Todo envio de arquivo da declaração, sendo este válido, irá gerar andamento no recibo da informação, em que caso a informação esteja em etapa Informação Válida, Em Homologação, Regular com ressalvas, Regular sem ressalvas ou Irregular, será executado processo de Undo da informação, sendo que a primeira situação Informação Válida, a informação será apenas apagada, já para as demais situações, o processo irá remover o processamento da informação e mandar refazê-lo, gerando sempre andamento do processo que gerou o reprocessamento.

O registro do recibo da informação do ContEx, registra a quantidade de arquivos que a informação tem. Dessa forma, com o envio do último arquivo restante válido, irá inicializar o processo de processamento da informação, publicando a tarefa de processamento da informação no Informa, e posteriormente outras etapas que tiver.

A recepção do arquivo da declaração deverá verificar os parâmetros informados, que são ID do Campo, Ordem do Campo, Calendário e Identificador único da informação, bem como se o MD5 do arquivo enviado corresponde ao arquivo informado na declaração. Todas essas validações serão realizadas antes de gerar o registro do arquivo na base de dados do sistema ContEx. Caso as validações apresentem inconsistências, na chamada do envio do arquivo, tanto via Portal Web quanto via Web Service, o sistema irá retornar as validações para o remetente corrigir antes de enviar. Caso o arquivo enviado esteja correto, o sistema irá registar o arquivo na base de dados e irá gerar um andamento no recibo da informação, informando que o arquivo foi enviado, informando ID do Campo, a Ordem do campo, a data e o usuário remetente do arquivo, e caso o arquivo seja o último arquivo da informação a ser enviado, o sistema deverá inicializar o processamento da informação, sendo que esse início de processamento deverá gerar andamento no recibo da informação.

O serviço de envio de arquivo da declaração via Web Service, o qual estará disponibilizado no serviço ServiceDeclaracao.svc, através do seguinte método:

• EnviaArquivoDaInformacao

Esse método recebe como parâmetro uma instância da classe DtoArquivoInformacao. Essa classe contem as propriedades do ID do Campo, Ordem do Campo, Número do Protocolo da declaração, Identificador Único da informação, o nome do arquivo e o conteúdo do arquivo em formato de array de bytes.

A chamada desse método, assim como apresentado anteriormente, irá validar as informações apresentadas na instâncias da classe DtoArquivoInformacao, com as informações contidas na declaração. Caso ocorra a identificação de inconsistências na declaração, o sistema irá retornar as inconsistências identificadas acionado uma exceção do tipo FaultException.

O objetivo inicial deste aplicativo é realizar a validação da declaração quando a mesma for gerada em xml, validando o layout, os códigos informados e os itens obrigatórios antes do envio do arquivo ao Tribunal de Contas do Estado (TCE) minimizando a quantidade de dados trafegados na rede e garantindo que o arquivo esteja de acordo com os moldes definidos pelo TCE a declaração em questão. Para tanto será necessário acrescentar alguns serviços ao webservice atual do contex para atender a esta demanda.

Ao Abrir o programa, o sistema deverá verificar se tem conectividade com a internet, realizando uma chamada ao webservice do contex. Em caso negativo o sistema deverá alertar o usuário: “O Sistema não conseguiu acessar a internet, verifique as configurações de proxy e/ou a conectividade com a internet.”

Ao clicar no ícone do diretório o sistema deverá abrir um caixa de dialogo, para que o usuário possa localizar o arquivo que deverá ser analisado. O sistema também deverá permitir que o usuário arraste um arquivo XML para a caixa de texto.

Ao clicar no link “Configurar Proxy” o sistema deverá chamar a tela de proxy, passando a executar o fluxo do item 7.16.4. Ao clicar no ícone de nuvem o sistema deverá chamar o fluxo de validação do arquivo xml no item 7.16.3.

Ao clicar no ícone de nuvem, o sistema deverá iniciar a validação do arquivo informado, seguindo os seguintes passos:

1. O arquivo deve ser do tipo XML, caso contrário o sistema deverá informar a seguinte mensagem ao usuário: “O Arquivo não é um arquivo do tipo XML valido.”;
2. O arquivo deverá ser transformado em objeto, caso ocorra um erro o sistema deverá informar a seguinte mensagem: “O Arquivo não está em um formato valido.” e sair do processamento;
3. Depois do objeto convertido, o sistema deverá consultar o webservice do contex e buscar as informações do Calendário indicado:
   1. Caso o código calendário indicado seja zero ou nulo, o sistema deverá informar ao usuário: “O código da dimensão, deve ser informado.” e sair do processamento.
   2. Em seguida o sistema deverá buscar se o calendário em questão existe no Contex e caso o mesmo não seja encontrado o sistema deverá informar ao usuário: “O Id do Calendário (dimensão) não foi encontrado.” e sair do processamento.
4. Verificar o campo PreparacaoArquivo que deve ser uma data real e inferior ao momento da validação;
5. Verificar o campo TipoDeclaracao que deve ser ou do tipo Normal ou Retificadora, caso seja do tipo Retificadora o campo ProtocoloRetificado deve conter um valor. O valor do campo ProtocoloRetificado não deve ser verificado quanto a sua originalidade, apenas se o mesmo foi preenchido;
6. Verificar os seguintes campos da Apuração:
   1. O campo Layout deve estar de acordo com o valor esperado para a declaração em questão.
   2. O campo VersaoLayout deve estar de acordo com o valor esperado para a declaração em questão.
   3. Os campos InicioApuracao e FinalApuracao devem estar de acordo com as opções existentes cadastradas no formulário em questão, caso não esteja na lista de possibilidades o sistema deve listar as opções disponíveis cadastradas.
   4. O campo TemMovimentacao se informado com a opção não, o sistema deverá verificar se a lista de informações está vazia conforme informado neste campo e caso negativo gerar uma mensagem ao usuário.
7. Dentro da lista de informações, o sistema deverá validar:
   1. Se todos os campos obrigatórios foram informados;
   2. Se todos os códigos informados no arquivo existem na lista de campos consultados no webservice.

Todas as validações para as Apurações e para as Informações não são impeditivas e deverão ser listadas na tabela de resultado da validação. Se ao final do processamento o arquivo passar em todas as validações o sistema deverá apresentar a mensagem: “O arquivo está formatado corretamente!”. O tipo do valor dentro do campo da informação apresentada não será validado no momento.

O sistema irá apresentar a tela de configuração de proxy, com todas as informações preenchidas caso existam. Caso o usuário marque a opção “Utiliza um servidor de proxy.”, o sistema deverá habilitar a edição dos campos relacionados, permitindo que o usuário preencha todos os campos.

Ao clicar em “Salvar” todas as informações da tela devem ser salvas, caso a opção “Utiliza um servidor de proxy” esteja desmarcada o sistema deverá então limpar todos os campos e então salvar a opção do usuário.

Ao clicar em “Cancelar” o sistema deverá sair da tela sem salvar as informações da mesma.

Ao clicar em “Testar Conexão”, o sistema deverá com as configurações informadas em tela realizar uma chamada ao webservice do TCE, em caso positivo o sistema informa a seguinte mensagem ao usuário: “Conexão foi realizada com sucesso.” porém em caso negativo a mensagem que deverá ser exibida é: “O Sistema não conseguiu acessar a internet, verifique as configurações de proxy e/ou a conectividade com a internet.”

O objetivo é permitir que o moderador possa solicitar ao sistema que envie um e-mail ao grupo de pessoas relacionadas a determinado calendário em duas funcionalidades, Controle de Calendário e Notícias, assim como configurar o envio de e-mails quando da proximidade de vencimento de um calendário.

E também permitir que o usuário normal possa configurar quais ações ele deseja receber e-mail informativo sobre o calendário ou protocolo, conforme descrito no item 7.17.3..

A primeira parte é a criação do aviso de vencimento, quando o usuário criar um novo calendário ou alterar um calendário será possível ao moderador adicionar uma determinada quantidade de dias para que o sistema envie um e-mail ao usuário associado ao calendário informando que o mesmo está para vencer. Se o valor ficar em branco o sistema não deverá avisar o usuário. Se a data final do calendário menos o valor inserido ficar abaixo ou igual a data inicial, o sistema deverá informar ao usuário: “O prazo máximo é XXX dias para o envio do e-mail.” onde XXX é a quantidade de dias entre a data final e a data inicial.

O sistema deverá criar uma tarefa, nos moldes do item 7.17.5., para que todos os dias as datas sejam verificadas de acordo com a regra: A quantidade de dias do aviso menos a data do vencimento do calendário é igual a data de hoje em caso positivo o sistema deverá enviar um e-mail a todos os usuários que estão relacionados com aquele calendário informando da proximidade do fim do calendário.

A Tabela Calendários de Obrigações terá uma coluna adicionada, onde será visualizada a quantidade de dias para a emissão do aviso.

A segunda parte é a criação de um botão de ação de disparo de e-mail pelo moderador que estiver na funcionalidade Calendários de Obrigações, conforme item 7.17.1.2. Ao clicar neste ícone o sistema deverá apresentar uma janela modal conforme demonstrado no item 7.17.2.2, com a lista de todos os usuários relacionados a este calendário, além de uma opção para que o moderador receba uma copia do e-mail e a solicitação da confirmação do envio do e-mail. Caso o usuário marque a opção de receber uma copia do e-mail o sistema deverá adicionar o usuário atual como copia do e-mail que será enviado. Este envio é imediato.

Configuração de Aviso de Calendário

Calendários de Obrigações

Modal Envio de e-mail

Para o envio de e-mails de noticias, deveremos adicionar esta opção em dois momentos. O primeiro deverá ser adicionado na tela de cadastro de notícias um checkbox para que o moderador possa escolher disparar ou não um e-mail com a notícia e o calendário para os usuários relacionados com o calendário em questão. O sistema só deverá exibir este checkbox se algum calendário for selecionado.

O segundo deverá ser incluido um botão na coluna de ações na grid de relação de notícias, este botão irá abrir uma modal semelhante a modal de envio de e-mails do item 7.17.1.2., onde o usuário poderá confirmar o envio da notícia para os envolvidos.

Deverá ser adicionado ao menu lateral uma opção de configuração de e-mails no qual o usuário comum poderá configurar quais alertas de e-mail ele deseja receber do sistema. Ao abrir esta tela o sistema deverá apresentar três opções de e-mail a serem disparados pelo sistema para o usuário, por padrão todas devem estar marcadas.

• Ao final do processamento de um protocolo, que será executado pelo próprio serviço de fechamento de protocolo;
• Quando faltar anexos em um recibo, depois de 1 dia de espera;
• 15 dias antes do vencimento de um calendário.

Estas informações podem ser alteradas a qualquer momento e não precisam de histórico. Para o caso do envio de e-mail para o final do processamento do protocolo o sistema calculará qual o percentual de recibos pendentes, caso esse valor seja inferior a 10% o sistema irá reagendar esta verificação para os próximos 60 minutos, do contrário a próxima verificação será apenas no outro dia.

Nesta seção estão todos os textos que devem ser utilizados ao gerar os e-mails enviados aos usuários do sistema.

 Prezado {NOME USUÁRIO},
 Ocorreu uma {alteração/criação} no calendário {DESCRIÇÃO DO CALENDÁRIO}, segue abaixo resumo atualizado do mesmo:
 Resumo do Calendário:

 Para mais detalhes vá para {URL DO DESTINO}.
 Gentileza não responder a este e-mail. Para duvidas utilize o e-mail **TODO DEFINIR E-MAIL**
 Att.
 Sistema ContEx.

 Prezado {NOME USUÁRIO},
 O Vencimento do calendário {DESCRIÇÃO DO CALENDÁRIO} está próximo. Faltam {X} dias.
 Para mais detalhes vá para {URL DO DESTINO}.

 Gentileza não responder a este e-mail. Para duvidas utilize o e-mail **TODO DEFINIR E-MAIL**

 Att.
 Sistema ContEx.

 Prezado {NOME USUÁRIO},
 {CONTEÚDO DA NOTÍCIA}
 Resumo do Calendário:

 Gentileza não responder a este e-mail. Para duvidas utilize o e-mail **TODO DEFINIR E-MAIL**
 Att.
 Sistema ContEx.

 Prezado {NOME USUÁRIO},
 O Protocolo {XTZ}, contêm {TOTAL DE ANDAMENTOS} andamentos, sendo {X} andamentos que exigem sua atenção.
 Para mais detalhes vá para {URL DO DESTINO}.
 Gentileza não responder a este e-mail. Para duvidas utilize o e-mail **TODO DEFINIR E-MAIL**
 Att.
 Sistema ContEx.

 Prezado {NOME USUÁRIO},
 O Protocolo {XTZ} está com  {TOTAL DE ANEXOS PENDENTES} anexos pendentes de envio, ele precisa de sua atenção.
 Para mais detalhes vá para {URL DO DESTINO}.
 Gentileza não responder a este e-mail. Para duvidas utilize o e-mail **TODO DEFINIR E-MAIL**
 Att.
 Sistema ContEx.

O sistema de agendamento de tarefas será construído em cima de duas filas no microservice. A execução da tarefa deverá ocorrer todos os dias as 22h00min. As verificações deverão ser divididas entre todos os tipos assim será possível realizar a verificação especifica para determinada regra e não a todos. (informação para lidar com os times outs: https://stackoverflow.com/questions/17014584/how-to-create-a-delayed-queue-in-rabbitmq ) Para utilizar o microservices, é necessária a utilização de duas filas, a primeira fila é a fila de espera, cujo timeout será definido pela tarefa, vencido esse prazo o rabbit-mq irá transferir para a fila de ação que deverá ter um trabalhador esperando para verificar todos os e-mails e dispara-los, ao final desta tarefa o sistema irá calcular o tempo restante para a próxima execução e então criar uma tarefa para a fila de espera com o timeout faltando para a próxima execução.

Para que esta funcionalidade trabalhe normalmente e se retro alimente, é preciso criar as primeiras tarefas, sendo assim o sistema deverá disponibilizar um link para o *adminstrador* que irá verificar se existe tarefas na espera para todas as verificações e caso não exista o sistema irá cria-las de acordo com a necessidade. Ao final da verificação o sistema irá informar um resumo ao adminstrador sobre quais tarefas foram criadas e quais já existiam.

Caso o desenvolvedor encontre problema na criação desta solução. A solução alternativa é a criação de uma aplicação console que será agendada no servidor e executada todos os dias as 22h00min, nesta solução todas as verificações são realizadas uma unica vez durante a execução.

Os envios de e-mails do sistema deverá consultar os calendários que estão em período de entrega, e para cada calendário será consumido o serviço de notificações conforme configuração de e-mails do usuário (quando faltar anexos em um recibo, depois de 1 dia de espera, e 15 dias antes do vencimento de um calendário), bem como executar a notificação de dias restantes do encerramento do calendário, conforme configurado pelo moderador do sistema.

O sistema tem por obrigação a geração de um protocolo de confirmação de recebimento de todas as informações enviadas ao TCE durante um determinado calendário. Este fechamento deverá ser automático e sistemático para garantir que toda a movimentação seja relacionada a um protocolo que de fato represente todas as informações do Jurisdicionado. Para atender esta demanda o sistema irá executar uma tarefa diariamente validando as regras para execução da tarefa, relatado no próximo item e a validação das regras para a criação do protocolo e inclusão dos recibos.

O sistema deverá executar as validações a seguir ao menos 1 vez por dia, o modulo que será criado para atender este fechamento, poderá ser implementado tanto como um “console application” como um “serviço do windows” ou uma mensagem colocada nas filas do microservice. Assim que iniciado o sistema deverá verificar se não existe nenhuma tarefa em execução relacionada a mesma tratativa, caso positivo o sistema deverá abortar o processamento sem gerar erro. Em caso negativo o sistema deverá passar para o próximo passo, que é a verificação se algum calendário normal ou especial venceu no dia anterior, em caso positivo o processamento deverá ser inicializado do contrário não é necessário fazer nada.

Depois de verificado que a tarefa pode continuar, vide item 7.18.1, o sistema inicia as validações do negocio neste sentido diversos itens devem ser verificados visando garantir que nenhuma informação seja ignorada ou duplicada.

O primeiro passo ao executar a tarefa é verificar se existe algum protocolo com o status “Processando” relacionado com os calendários vencidos do dia anterior. Caso não exista o sistema deverá criar um novo protocolo e coloca-lo com o status “Processando” de modo que o sistema possa se recuperar em caso de falha não esperada. Caso já exista um protocolo com o status “Processando”, então pode ter ocorrido uma falha, o sistema deverá carregar todas os recibos já relacionados e todos que não estão relacionados com o protocolo mas estão ligados ao calendário em questão para só então retomar o processamento, passando para a regra a seguir.

O segundo passo é identificar os recibos sem relacionamento com o protocolo e realizar tal relacionamento colocando a data do ultimo recibo aceito pelo sistema para aquele calendário.

O sistema deverá verificar se existem recibos com a situação igual a Recibo em caso positivo o sistema deverá enviar um e-mail ao departamento de TI de acordo com a mensagem do item 7.18.4

O sistema deverá contar a quantidade de recibos que estiverem com a sua situação igual a Informacao_Invalida para a inclusão desta informação no e-mail que será enviado ao final do processamento, veja item 7.18.3.

Para o calendário normal, o sistema vai incluir todos os recibos de informação recebidos no período de entrega do calendário, com os status: INFORMACAO_INVALIDA, INFORMACAO_VALIDA, EM_HOMOLOGACAO, HOMOLOGADO, HOMOLOGADO_CRITICA, RETIFICADO e CANCELADO.

Para o calendário especial, o sistema vai incluir todos os recibos já relacionados no protocolo gerado anteriormente e todos os demais recibos recebidos no calendário especial, exceto os recibos que foram retificados ou cancelados nas entregas durante o período do calendário especial. Os status que devem ser selecionados a este novo protocolo são os mesmos do calendário normal.

Ao final do processamento o sistema deverá enviar um e-mail para todos os usuários que enviaram recibos para aquele protocolo informando que o processamento foi finalizado e um link para que o usuário possa acessar a tela de impressão e verificação do protocolo, descrito no item 7.4.3. Quando o novo sistema de notificações estiver implementado ao invés de enviar um e-mail o sistema deverá entrar ao sistema de notificações este resumo para que ele dê o prosseguimento definido pelo usuário destinatário. O Corpo do e-mail deverá ser o seguinte:

 Prezado **Usuário**.
 
 Foi realizado o fechamento do calendário **Nome** cuja data final foi em **DATAFINAL**. O Código do protocolo criado foi **CÓDIGO DO PROTOCOLO**, o mesmo já se encontra disponível no site através do **link**
    
 Att.
 PS: Gentileza não responder esse e-mail.

Caso o sistema tenha encontrado recibos com status “Recebido” e “Informacao_Invalida”, o sistema deverá incluir a linha abaixo deverá ser adicionada no e-mail.

 Houveram recibos **XX** não processados por inconsistência de admissibilidade. 

Todos os recibos marcados apenas como Recebidos do protocolo que está sendo fechado deverão ser listados em um único e-mail e enviado para o e-mail da ti: informatica@tce.go.gov.br. Com o assunto: “Recibos não processados no Protocolo: CÓDIGO DO PROTOCOLO”.

No corpo do e-mail deverá ser o seguinte:

Prezados,

Foi realizado o fechamento do calendário **Nome** cuja data final foi em **DATAFINAL**. O Código do protocolo criado foi **CÓDIGO DO PROTOCOLO**, infelizmente foram encontrados os seguintes recibos **SEM PROCESSAMENTO**, gentileza verificar com urgência:

Lista dos Protocolos:
* **ID-UNIDO-RECIBO** (id do Recibo na tabela);
* repetir quantas vezes forem necessárias.
Att. 
Sistema Contex

Na funcionalidade de consulta de protocolos será apresentado ao usuário a possibilidade de consultar os protocolos dos calendários já encerrados, e a consulta dos recibos que compõe o protocolo, consultando através do número do protocolo, conforme apresentado na figura 1.

Ao abrir está tela de Consulta de Protocolos de Declaração, o sistema irá buscar todos os protocolos já recebidos, conforme demostrado na figura 2 da seção subsequente. É possível ao usuário filtrar de acordo com a sua necessidade os protocolos já enviados, bastante ao usuário clicar em “Filtros”.

Nas opções de filtros existentes estão à busca por dimensão ou por Jurisdicionado (quando o usuário tiver perfil de Moderador) e ainda é possível utilizar-se do número do protocolo, hash e as datas iniciais e finais. Ao clicar em “consultar” o sistema irá recarrega a tabela com os resultados encontrados. Conforme pode ser visto na figura 3 da seção subsequente.

Na tabela que é carregada abaixo dos filtros os protocolos são apresentados organizados por seu número. É possível ver a data, hora de envio e o hash gerado. Cada uma das linhas possui duas ações, sendo a primeira a geração de um comprovante de entrega de declaração e a segunda a consulta detalhada dos recibos por informação daquele protocolo.

Ao clicar na ação de “geração de comprovante” o sistema irá abrir uma nova janela com o comprovante de entrega de declaração que poderá ser impresso quando necessário, conforme a figura 3. Este comprovante possui os seguintes campos: Remetente da declaração, CPF, Órgão e CNPJ do Órgão do remetente, além de um texto declarando que o protocolo foi entregue dentro ou fora do prazo regular e ainda informando o hash do protocolo. O sistema ainda deve apresentar um link para a validação do protocolo.

Ao clicar na consulta detalhada dos recibos das informações o sistema irá redirecionar o usuário a tela de “Consulta de Recibos do protocolo”.

A funcionalidade permite ao usuário visualizar as declarações não processadas por motivo de erro ou inconsistência do sistema. Sendo possível que as informações não processadas por motivo de indisponibilidade do serviço ou falha do serviço, podem ser reenviadas para reprocessamento. Esta tarefa é executada a partir da identificação dos Protocolos e/ou Recibos que atendem aos requisitos para serem reprocessados.

Em ambas as telas de reprocessamento(recibo/protocolo) permitem a seleção de um ou vários recibos/protocolos. Por meio do botão 'REPROCESSAR' todos que foram selecionados serão enviados para reprocessamento.

Um protocolo esta apto para ser reprocessado se estiver a um dia ou mais em situação de 'Processando'.

Os Recibos aptos para reprocessamento atendem as seguintes regras:

• O recibo deve estar em situação Recebido.
• Quando o arquivo de informação possuir arquivo anexo todos os arquivos anexos devem possuir conteúdo.
• Para todos os casos se a informação tem pai, o pai deve estar em situação diferente de Recebido.

Na tela de Protocolos, por padrão são listados aqueles que estão a mais de 5 dias em situação de 'Processando'.

Na tela de Recibos são listados todos que atendem ao requisito.

Para busca de Protocolos, é possível especificar por meio dos filtros a quantidade de dias assim como o Calendário de Obrigações.

Os Recibos apresentados podem ser filtrados pelo calendário e por um período de tempo definido por duas datas.

Filtro de Protocolos

Filtro de Recibos

Como Jurisdicionado e Moderador do sistema, preciso consultar por Calendário de Obrigações com a possibilidade de restringir a consulta por período de entrega da declaração, todas as declarações entregues que tiveram críticas, seja na validação da declaração ou seja na validação da informação contida na declaração. O resultado da consulta preciso exportar o conteúdo da página ou de todas as páginas, em formato CSV.

Na visão do Jurisdicionado serão apresentados como filtro a seleção de Calendário de Obrigações e o período de entrega de declaração, o ultimo filtro composto por dois campos de data, um para a data inicial e o segundo para data final. Para pesquisar as declarações com críticas, apenas o campo do Calendário de Obrigações é obrigatório, devendo sempre ser informado.

Já na visão do Moderador, além dos campos na visão do jurisdicionado, também será apresentado o campo para informar o Órgão Jurisdicionado que se desejar consultar, sendo este de preenchimento opcional. Da mesma forma como na visão do Jurisdicionado, apenas o campo Calendário de Obrigações é obrigatório, devendo ser sempre informado.

A paginação do resultado da consulta será realizado a cada 50 declarações, com as opções além de navegar entre as páginas de forma sequencial, também será possível ir direto para a primeira e para a última pagina, e bem como ir direto para uma página específica, informando na caixa de edição situada no rodapé da grid de resultado.

Não faz parte do escopo desse projeto, nesse momento, o processamento das informações recebidas na integração com os sistemas de Controle Externo existente atualmente, como GORC (Gerencia de Orçamentária), GACE (Gerencia de Apoio ao Controle Externo), Art30 (Sistema de recepção de dados em atendimento ao Artigo 30 da constituição estatual), GRAD (Gerencia de Registro de Atos de Admissão), e entre outros.