BANCO DE DADOS E LÓGICA NO SENIOR HCM: CBDS, CURSORES E SEÇÕES ADICIONAIS

A criação de relatórios complexos no Senior HCM muitas vezes exige ir além dos relacionamentos padrões estabelecidos entre as seções de detalhe. Quando o layout demanda composições sob medida ou tratamentos pontuais de registros subordinados, o domínio do banco de dados e da linguagem de regras torna-se essencial.

Nesse cenário, a Central de Banco de Dados Senior (CBDS) atua como o ponto focal para a manutenção da integridade da base, dicionários de dados e estruturas customizadas. Qualquer modificação estrutural que fuja das regras desse gerenciador pode comprometer o ecossistema e inviabilizar o uso de campos em relatórios e telas.

Neste artigo, serão abordados os fundamentos do gerenciamento de tabelas e campos customizados no CBDS, o ciclo de vida do dicionário TBS, a implementação de cursores SQL em regras e a impressão controlada por meio de seções adicionais no Gerador de Relatórios.

No ecossistema Senior, todas as novas tabelas e campos personalizados devem ser criados obrigatoriamente através da Central de Banco de Dados Senior (CBDS). A criação direta em ferramentas externas, como o SQL Server Management Studio, não atualiza o dicionário de metadados da aplicação.

Os objetos criados pelo usuário recebem nomenclaturas padronizadas pelo sistema para assegurar compatibilidade em futuras atualizações:

- Tabelas customizadas: recebem automaticamente o prefixo USU_ seguido de identificador (como USU_T...).

- Campos customizados: assumem o prefixo USU_ associado ao nome atribuído pela regra de negócio.

- Dicionário de dados TBS: armazena as definições das tabelas e colunas, permitindo o reconhecimento dos campos na tecla de atalho F8 e no gerador.

Após desenhar uma tabela ou campo no CBDS, o objeto permanece em estado lógico (marcado em vermelho). A efetivação física no banco de dados e a sincronização do arquivo TBS ocorrem somente após a execução do processo de aplicação de alterações.

A aplicação de alterações físicas no banco de dados exige cautela operacional por parte do desenvolvedor ou consultor. Alterar tabelas centrais com milhões de registros, como a R034FUN, recria estruturas e pode provocar locks severos no banco.

Diretrizes indispensáveis para manutenção de estruturas:

- Executar procedimentos de recriação de tabelas e inclusão de colunas fora do expediente comercial ou durante janelas planejadas.

- Utilizar a função de assinalamento de base em manutenção ou treinamento, bloqueando novos logins de usuários até o término do processo.

- Manter backups regulares dos arquivos TBS, observando que o CBDS gera versões de segurança com extensão incremental (.001, .002) a cada atualização.

- Desconectar e reconectar o usuário no sistema após a efetivação física, viabilizando o carregamento das novas colunas na sessão local.

Quando determinado campo comporta apenas um conjunto finito e reduzido de opções fixas, a criação de tabelas adicionais torna-se desnecessária. Nesses casos, o Senior HCM adota o conceito de listas enumeradas.

As enumerações definem uma relação interna entre valores armazenados no banco e suas respectivas descrições de tela. Ao criar uma enumeração no CBDS:

- Define-se o tipo do identificador como numérico ou caractere, associado à sua precisão ou máscara.

- Cadastram-se as chaves e valores válidos (por exemplo, 1 para Opção A, 2 para Opção B).

- Associa-se a lista enumerada diretamente à coluna correspondente na tabela customizada.

Essa padronização preserva o desempenho do banco, reduz a ocupação em disco e assegura a integridade das opções selecionáveis pelo usuário final.

Em modelos onde se opta por não utilizar múltiplas seções visuais de detalhe, a manipulação de dados subordinados é realizada via programação através de cursores SQL integrados às regras do Gerador.

A rotina de consulta via cursor obedece a um ciclo rígido de declaração e manipulação:

- Declaração do cursor: realizada por meio da instrução Definir Cursor, atribuindo um nome referencial (exemplo: Definir Cursor CUR_R036DEP).

- Montagem da consulta: atribuição do comando SQL via propriedade .SQL, parametrizando as cláusulas WHERE com as variáveis do registro pai.

- Controle de execução: abertura explícita com o método .Abrir() e encerramento obrigatório com .Fechar() para liberação de memória.

- Laço de repetição: iteração sobre os registros encontrados com estrutura Enquanto e avanço obrigatório através do método .Proximo().

A omissão do método .Proximo() dentro do bloco de repetição causa laço infinito, resultando no congelamento do processo de emissão do relatório.

Para exibir informações obtidas por um cursor sem sobrecarregar a linha principal de detalhe, utiliza-se a Seção Adicional. Diferente de um subdetalhe tradicional, a seção adicional é renderizada exclusivamente sob demanda da regra.

A chamada da seção ocorre através da função de sistema ListaSecao:

- A seção adicional é criada no layout do relatório e identificada com um nome semântico (como Adicional Dependentes).

- No evento de regra apropriado, invoca-se a função ListaSecao informando exatamente o nome da seção entre aspas.

- Os campos contidos na seção adicional recebem os valores das variáveis alimentadas pelo cursor durante cada ciclo da iteração.

O evento de disparo influencia diretamente a ordenação dos dados: para que a lista subordinada seja exibida logo abaixo do colaborador titular, a chamada da regra deve ser posicionada no evento "Depois de Imprimir" do detalhe principal.

Campos baseados em listas enumeradas (como grau de parentesco e tipo de sexo) retornam códigos internos que necessitam de conversão textual antes da renderização na seção adicional.

Recursos de formatação e decodificação utilizados nas regras:

- Função DescItemLista: recebe o nome da lista de sistema, o código numérico ou caractere e devolve a descrição textual correspondente em uma variável alfanumérica.

- Função ConverteMascara: transforma valores numéricos para formatos editados ou strings, exigindo a identificação do tipo do dado e a máscara de destino.

- Tipagem de variáveis: variáveis alfanuméricas exigem declaração prévia obrigatória com a instrução Definir Alfa, enquanto tipos numéricos comportam declaração implícita.

Para a correta impressão do texto decodificado em campos de fórmula, utiliza-se a associação via variável ValStr combinada à instrução Cancel(2), liberando a impressão pontual do componente.

Em determinadas situações gerenciais, o relatório não deve listar registros mestres caso estes não possuam itens associados na tabela secundária (como colaboradores sem dependentes).

Para implementar esse filtro lógico sem alterar a estrutura da consulta primária:

- Vincula-se uma verificação via regra no evento "Antes de Imprimir" da seção de detalhe do colaborador.

- Executa-se uma consulta pontual no cursor subordinado validando a existência de registros associados à chave atual.

- Caso o cursor não encontre registros, executa-se a instrução Cancel(1), cancelando integralmente a exibição da linha do colaborador corrente.

Esse mecanismo atua como um filtro pós-processamento, garantindo que o relatório final apresente apenas os dados de interesse.

A flexibilidade de um relatório reside na capacidade de permitir seleções dinâmicas pelo usuário final através da tela de entrada.

Recomendações técnicas para a construção de filtros:

- Chaves compostas agrupadas: posicionar os campos de empresa, tipo e matrícula em sequência lógica para facilitar o preenchimento.

- Configuração de abrangência: ativar a propriedade de abrangência em parâmetros alfanuméricos para permitir a inserção de intervalos e listas separadas por vírgula.

- Máscaras coerentes: definir máscaras cujo tamanho do nível seja rigorosamente compatível com o comprimento total da variável de entrada.

Veja como esse conteúdo foi abordado na aula:

A seguir, veja os passos para criar um relatório que lista colaboradores e imprime seus respectivos dependentes utilizando regras, cursores e seção adicional:

1. Acesse o Gerador de Relatórios e crie um novo modelo customizado com numeração superior a 100.

2. Configure a seção Detalhe Colaboradores associando a tabela R034FUN e adicione os campos NumEmp, TipCol, NumCad e NomFun.

3. Crie uma nova Seção Adicional no layout e renomeie-a para "Adicional Dependentes".

4. Na Seção Adicional, insira componentes do tipo formulário para o código, nome, parentesco e sexo do dependente.

5. Acesse o evento "Depois de Imprimir" da seção Detalhe Colaboradores e declare as variáveis alfanuméricas com a instrução Definir Alfa.

6. Defina o cursor apontando para a tabela R036DEP: Definir Cursor CUR_R036DEP.

7. Monte a instrução SQL filtrando por NumEmp, TipCol e NumCad equivalentes aos dados do colaborador ativo.

8. Abra o cursor com CUR_R036DEP.Abrir() e inicie a estrutura de repetição Enquanto.

9. Dentro do laço, alimente as variáveis com os campos do cursor e utilize DescItemLista para decodificar o sexo e o parentesco.

10. Execute o comando ListaSecao("Adicional Dependentes") para imprimir cada dependente encontrado.

11. Insira a chamada CUR_R036DEP.Proximo() e feche o cursor com CUR_R036DEP.Fechar() ao término do laço.

12. Salve o modelo, execute o teste no depurador para validar a passagem dos ponteiros e confirme a emissão dos dados em tela.

A integração entre a Central de Banco de Dados Senior e o Gerador de Relatórios proporciona um leque avançado de soluções para atender a demandas analíticas do departamento de Recursos Humanos. O respeito à arquitetura do dicionário TBS e a realização de manutenções em janelas programadas garantem a estabilidade de todo o sistema.

A aplicação de cursores em conjunto com seções adicionais revela-se uma alternativa poderosa ao uso tradicional de múltiplos subdetalhes visuais. Essa técnica confere maior controle sobre os momentos de impressão, paginação e decodificação dinâmica de literais.

Compreender a ordem lógica dos eventos, o tratamento de listas enumeradas e as instruções de controle condicional capacita os desenvolvedores a criar relatórios enxutos, performáticos e com alto rigor técnico no Senior HCM.