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 {

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

} tr th, tr td {

  border: 1px solid #e6e6e6;

} tr th {

  background-color: #f5f5f5;

}

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

a {

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

} tr th, tr td {

  border: 1px solid #e6e6e6;

} tr th {

  background-color: #f5f5f5;

}

e, para cada registro:

model.todasVariaveis[r].name

model.todasVariaveis[r].value

a {

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

} tr th, tr td {

  border: 1px solid #e6e6e6;

} tr th {

  background-color: #f5f5f5;

}

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

Neste ponto é importante separar consulta das informações já auditadas no processo de registro de nova auditoria nesta tarefa.

Na implementação da etapa 2, o código de buscaVariaveisFluxo_e_enviarDados() identifica e manipula estruturas provenientes de todasVariaveis, inclusive uma estrutura denominada no código como tabelaRelacoes. Entretanto, as chamadas encontradas para preencheInformacoesAlteradas() aparecem comentadas no código apresentado.

Assim, **não é seguro afirmar que a tarefa 5A2 registra novos campos em tab_relacoesInfoalteradas ** apenas com base nessa implementação.

Importante: esses são os campos editáveis/de decisão da tarefa. O JSON analisado **não demonstra de forma explícita que eles sejam gravados emtab_relacoesInfoalteradas **. Por isso, não devem ser classificados automaticamente como “campos auditados” nessa variável.