Validação final e ocorrências

O objetivo da tarefa é consolidar, validar e apresentar as informações produzidas pelas etapas anteriores do processo de Aposentadoria Civil, tratar eventuais ocorrências e permitir ao usuário decidir se o preenchimento deve ser concluído ou retornar para correção. A tarefa divide essa responsabilidade em duas partes:

Apresentar uma visão consolidada das informações relevantes do processo para conferência.

Apresentar as ocorrências, permitir o preenchimento das respectivas justificativas e definir o encaminhamento:

Concluir preenchimento e enviar ao TCE ou Retornar nos formulários para alteração

Além disso, a tarefa utiliza uma integração de consulta das variáveis do vínculo BPM. Essa integração recupera as variáveis do fluxo e armazena a coleção na variável todasVariaveis.

Na segunda etapa, a função:

buscaVariaveisFluxo_e_enviarDados()

percorre:

model.todasVariaveis

RN01 - A tarefa possui duas etapas

O JSON estabelece:

steps = 2

A primeira etapa corresponde ao resumo/conferência e a segunda às ocorrências e decisão de encaminhamento.

RN02 - Etapa 1 é somente leitura

Todos os campos de negócio da primeira etapa estão com:

readonly = true

Assim, essa etapa é utilizada para visualização/conferência, não para alteração direta dos dados.

RN03 - Ocorrências são apresentadas em tabela

Na segunda etapa existe:

Variável da tabela: tab_criticas5A2

Título: Ocorrências.

Seus campos são:

• Código;
• Descrição;
• Justificativa

RN04 - Código e descrição da ocorrência não são editáveis

Os campos:

col_codigoCritica

col_descCritica

possuem readonly=true.

Já:

col_justificativa

é editável.

RN05 - Encaminhamento é obrigatório

Na segunda etapa, o campo:

bt_comoDesejaProsseguir

é definido como:

required = true (Terefa aberta)

Portanto, o usuário deve indicar como deseja prosseguir.

RN06 - Existem dois possíveis encaminhamentos

RN07 - Retorno direcionado

O campo sel_etapaRetorno disponibiliza quatro destinos:

RN08 - Ocorrências não podem ser adicionadas/removidas manualmente

A função:

ocultaBotao_excluir_e_add_tab_criticas5A2()

oculta os botões de remoção das linhas e também:

add_tab_criticas5A2

Logo, a interface não permite ao usuário adicionar ou remover ocorrências manualmente por esses controles.

Nenhum desses campos é obrigatório na configuração da etapa.

Regra condicional

Os campos:

tempoCondicaoSegDeficienciaConversao

tempoCondicoesEspeciasConversao1

são exibidos quando:

model.cod_motivoAposentadoria == '5'

Destaque: todasVariaveis

Esta variável merece tratamento especial na documentação.

A integração Busca todas variáveis do fluxo possui retorno:​‌

value = array

name = todasVariaveis

Na etapa 2, buscaVariaveisFluxo_e_enviarDados() percorre a coleção utilizando:

model.todasVariaveis[r].name

model.todasVariaveis[r].value

para tratar as variáveis recuperadas durante a conclusão.

Mensagem quando não há ocorrência

A etapa possui msg_ocorrecias, um componente paragraph, cuja mensagem informa explicitamente que nenhuma ocorrência foi identificada até o momento e que outras verificações ocorrerão posteriormente na fiscalização do TCE-GO.

bt_comoDesejaProsseguir

1 = Concluir preenchimento e enviar ao TCE

2 = Retornar nos formulários para alteração

sel_etapaRetorno

1 = Dados básico

2 = Dados do fundamento jurídico

3 = Dados do histórico funcional

4 = Documentos de formalização

Esses campos são ocultados da tela e do próprio PDF por suas condições de exibição, funcionando como variáveis auxiliares de controle.

O agrupador Campos Ocultos da segunda etapa contém:

Considerando as duas etapas, existem duas integrações distintas.

Finalidade correta

A finalidade principal dessa integração é recuperar as variáveis existentes na instância BPM e preencher todasVariaveis como array, além dos retornos individualmente mapeados.

A segunda etapa possui a função:

buscaVariaveisFluxo_e_enviarDados()

Ela verifica a quantidade de registros em:

model.todasVariaveis.length

e percorre cada item através de:

model.todasVariaveis[r].name

model.todasVariaveis[r].value

Portanto, a consulta de todasVariaveis participa da rotina de conclusão do formulário, e não deve ser documentada simplesmente como uma integração destinada a carregar visualmente os campos readonly da aba 1.

Esta integração pertence à segunda etapa.

Entre os retornos configurados estão:

• dataHoraInfoSobreApostila;
• nomeRespAssApostila;
• tab_criticas5A2;
• bt_comoDesejaProsseguir;
• sel_etapaRetorno;
• variáveis auxiliares de PDF.

O mapeamento explícito:

nmUsuario → nomeRespAssApostila

recupera o nome do usuário para nomeRespAssApostila.

Prosseguir para próxima aba

Botão técnico de carregamento

Voltar para aba anterior

Key: btn_3

Função: formFunctions.previousStep

Retorna para a primeira etapa.

Salvar

Key: btn_salvar

Função: formFunctions.saveDraft

Concluir formulário

Key: submit_1

Tipo: submit

Função: finalizarTarefa

Botão técnico btn_load

Key: btn_load

Função: carregaDadosIniciais

showCondition: false

A tarefa separa a conferência dos dados, na etapa 1, da análise das ocorrências e decisão de encaminhamento, na etapa 2.

Código e descrição são readonly e a função ocultaBotao_excluir_e_add_tab_criticas5A2() remove da interface os controles para adicionar/remover ocorrências.

A coluna col_justificativa é o campo editável da tabela de ocorrências.

bt_comoDesejaProsseguir possui required=true.

Caso o fluxo de decisão seja de retorno para alteração, o formulário disponibiliza sel_etapaRetorno com quatro destinos configurados.

finalizarTarefa() executa Class_ocultaCampos() e interrompe o processamento quando identifica campos inválidos, exibindo alerta:

Existem campos com valores inválidos.

Antes da sequência de conclusão, finalizarTarefa() chama:

pdf_decideMostrarOuNaoNoPDF(form, model, context);

A primeira etapa possui 5 funções.

A segunda etapa possui um conjunto mais amplo de funções, incluindo:

Essa é uma das funções centrais da segunda etapa.

Ela utiliza:

model.todasVariaveis.length

e, para cada registro:

model.todasVariaveis[r].name

model.todasVariaveis[r].value

O código trata diferentes variáveis do processo, incluindo estruturas tabulares, e monta objetos a partir dos valores recuperados.

a {

  text-decoration: none;
  color: #464feb;

} tr th, tr td {

  border: 1px solid #e6e6e6;

} tr th {

  background-color: #f5f5f5;

}

A interpretação correta da arquitetura é:

a {

  text-decoration: none;
  color: #464feb;

} tr th, tr td {

  border: 1px solid #e6e6e6;

} tr th {

  background-color: #f5f5f5;

}

A variável todasVariaveis representa, portanto, uma estrutura intermediária importante para o processamento realizado na segunda etapa.

a {

  text-decoration: none;
  color: #464feb;

} tr th, tr td {

  border: 1px solid #e6e6e6;

} tr th {

  background-color: #f5f5f5;

}

Class_ocultaCampos() contém lógica para mostrar/ocultar campos e tratar obrigatoriedade dinamicamente. A função também participa da validação executada por finalizarTarefa().

A tabela tab_criticas5A2 não é livremente manipulável: o próprio JavaScript oculta os controles de inclusão e exclusão, enquanto código e descrição permanecem readonly.

a {

  text-decoration: none;
  color: #464feb;

} tr th, tr td {

  border: 1px solid #e6e6e6;

} tr th {

  background-color: #f5f5f5;

}

A tarefa Validação final e ocorrências é uma etapa de fechamento composta por duas abas funcionalmente distintas.

A primeira etapa concentra a conferência das informações produzidas anteriormente no processo, exibindo em modo somente leitura a identificação do servidor, cargo, fundamento jurídico, datas, tempos previdenciários e atos de aposentadoria/fixação de proventos.

A segunda etapa concentra o tratamento efetivo da validação: apresenta a tabela de Ocorrências, mantém código e descrição protegidos contra edição, permite registrar Justificativa e exige que o usuário escolha Como deseja prosseguir?. As opções são concluir o preenchimento e enviar ao TCE ou retornar aos formulários para alteração. Neste último caso, o usuário pode direcionar o retorno para Dados básicos, Dados do fundamento jurídico, Dados do histórico funcional ou Documentos de formalização.

Do ponto de vista técnico, a integração Busca todas variáveis do fluxo deve ser entendida em conjunto com todasVariaveis. A integração alimenta essa coleção com as variáveis da instância BPM e, na lógica da segunda etapa, buscaVariaveisFluxo_e_enviarDados() percorre os registros por name e value durante o processamento relacionado à conclusão. (Responsável por preencher a variável ''processoTceHub ''que é enviada no serviço de críticas dentro do fluxo)

A tarefa ainda possui uma segunda integração, Nome responsável apostila, executada no carregamento da segunda etapa para obter, entre outros retornos, nomeRespAssApostila. (Neste SIAP 2.0 a integração executa mas os dados de retorno não são utilizados nesta versão do SIAP)

Por fim, embora a rotina de conclusão manipule informações recuperadas de todasVariaveis, a versão 29 não demonstra registro ativo de novos campos emtab_relacoesInfoalteradas **, pois as referências observadas a preencheInformacoesAlteradas() estão comentadas. Por isso, a auditoria deve ser documentada como **não explicitamente implementada nesta tarefa, evitando atribuir incorretamente os campos editáveis da etapa 2 à tab_relacoesInfoalteradas.