3105 - Informações da Ficha Básica que não são atualizadas x históricos
Problema: Verificamos que foram alteradas informações nos históricos de alguns colaboradores e ao consultarmos a Ficha Básica, continuam sendo demonstradas as informações anteriores.
Exemplos:
1 - Foram incluídos históricos de Afastamentos na situação 003 - Auxílio Doença para alguns colaboradores, para outros colaboradores foram calculadas rescisões, onde a própria rotina inclui um histórico de Afastamento na situação 007 - Demitido. Ao consultarmos a Ficha Básica destes colaboradores, continua sendo apresentada a situação 001 - Trabalhando.
2 - Foram realizadas alterações nos históricos de Centros de Custo e Cargos, e ao consultarmos a Ficha Básica, continuam sendo demonstradas as informações do histórico anterior ao da alteração.
Quando ocorre / onde se aplica: Colaboradores > Ficha Cadastral > Empregados
Solução: Esta situação pode ocorrer em virtude de algum problema na rotina de Atualização de Históricos ou devido a existência de objetos inválidos na base.
Neste caso, devem ser seguidos os passos abaixo para identificar a origem do problema:
1 - A rotina de Atualização de Históricos é disparada automaticamente pelo sistema no primeiro logon do dia e a cada hora ociosa. Esta rotina tem por objetivo atualizar a ficha básica quando são incluídos históricos futuros. Quando ocorre algum problema durante a rotina de atualização, a mesma é abortada e o motivo é gravado em log de processamento, tipo 64. Caso o problema não seja acertado, a rotina volta a executar e é abortada pelo mesmo motivo, gerando depois de algum tempo, várias informações desatualizadas na ficha básica, divergindo do que consta nos históricos.
Por este motivo, sempre que for identificado este tipo de problema, deve-se verificar o log de processamento disponível em Diversos > Log > Processamentos, consultando o tipo 64 - Atualização de Históricos, para identificar se ocorreu algum erro durante a execução desta rotina. Esta verificação no log deve ser periódica, pois pode ocorrer algum tipo de problema a qualquer momento.
2 - No caso de não haver informações a listar na consulta de log de processamentos do tipo 64 nos últimos dias, verificar se existe algum processo automático de Histórico (Recursos > Processos Automáticos > Históricos) cujo campo Executa Rotina Padrão esteja habilitada.
Quando este campo está com S o sistema deixa de executar a atualização dos históricos no primeiro acesso do dia (padrão) para ser executado somente através do Processo Automático. Se a periodicidade deste processo for muito grande ou ocorrer qualquer outro problema no Middleware que impossibilite a execução do processo, a atualização de históricos não será efetuado e a ficha básica permanecerá desatualizada.
3 - É bastante comum encontrarmos problemas de sobreposição de afastamento (informações antigas) que provocam erro na execução da rotina de Atualização de Históricos. Para verificar se existe alguma sobreposição, podem ser utilizados os relatórios existentes para esta finalidade: No Administração de Pessoal, Colaboradores > Históricos > Listar, modelo 17 e no Controle de Ponto, Colaboradores > Listar, modelo 12.
Após listar estes modelos, as inconsistências apresentadas devem ser ajustadas.
4 - Para entender o funcionamento da rotina de Atualização de Históricos, existe um campo de Status em cada uma das tabelas de histórico. Seu conteúdo pode identificar que o histórico é futuro, atual ou passado, dependendo da tabela. A rotina verifica a data atual, com a data do histórico e atualiza a informação do Status. A partir daí, a atualização da ficha básica (R034FUN) é feita através de Triggers e Stored Procedures. Caso elas estejam inválidas ou não existam na base, a situação a ser encontrada será: o Status estará de acordo, mas a informação na ficha básica não estará atualizada.
Neste caso, será necessário recriar as Stored Procedures e Triggers, seguindo as orientações abaixo:
=> Criação das Stored Procedures:
No CBDS, ir na Tree view (lista de pastas) localizada do lado esquerdo da tela e selecionar a última pasta (Stored Procedure);
Clicar com o botão direito do mouse;
Selecionar a opção Enviar para;
Selecionar a opção Executar.
=> Criação das Triggers:
No CBDS, selecionar a opção de menu Ferramentas > Alterar Tabelas;
Na tela que será exibida, selecionar todas as tabelas clicando no botão >> ;
Em Objetos selecionar Trigger e desabilitar as demais opções;
Em Comando selecionar a opção correspondente, sendo:
Criar - Se a base não possuir triggers ainda
Recriar - Caso já existam Triggers na base(situação padrão). Obs. Neste caso o CBDS irá apagar as triggers antigas antes de ativar as novas.
Em Destino habilitar a opção executar no banco;
Clicar em Processar.
Atenção! Quando executar o procedimento a cima, não poderá ter nenhum usuário conectado no Banco de Dados, somente o usuário Administrador do sistema que irá efetuar a recriação no aplicativo CBDS.exe.
5 - Para verificar se ainda existem objetos inválidos na base, se o Banco de Dados for Oracle, poderá ser utilizado o seguinte comando:
select * from user_objects where status='INVALID'
IMPORTANTE 1:
Foi implementada na versão 5.5.1.20, a guia 'Manut. Base de Dados' em Diversos > Assinalamentos com a finalidade de alertar o administrador do banco de dados via e-mail ou até bloquear o acesso ao sistema caso existam triggers inválidas, colocando a Base em manutenção no CBDS.
Esta guia possui 3 assinalamentos:
- Bloquear Acesso Triggers Inválidas: Possui as opções S (padrão) e N.
- Tipo de Verificação: Com os valores H - Somente Históricos e T - Todas as Tabelas.
- E-mail para Aviso: Permite informar o e-mail do administrador do banco.
A verificação ocorre somente no primeiro login do dia, e caso haja alguma trigger inválida a base é marcada como manutenção e a entrada no sistema é abortada. Caso o usuário defina para que a entrada no sistema não seja bloqueada, a rotina somente envia o e-mail e faz a gravação dos logs no primeiro login do dia.
Foi implementada consistência para que a verificação não seja realizada nos bancos SQL Server e Sybase Server, nos quais a implementação não está disponível.
Exemplos:
1 - Foram incluídos históricos de Afastamentos na situação 003 - Auxílio Doença para alguns colaboradores, para outros colaboradores foram calculadas rescisões, onde a própria rotina inclui um histórico de Afastamento na situação 007 - Demitido. Ao consultarmos a Ficha Básica destes colaboradores, continua sendo apresentada a situação 001 - Trabalhando.
2 - Foram realizadas alterações nos históricos de Centros de Custo e Cargos, e ao consultarmos a Ficha Básica, continuam sendo demonstradas as informações do histórico anterior ao da alteração.
Quando ocorre / onde se aplica: Colaboradores > Ficha Cadastral > Empregados
Solução: Esta situação pode ocorrer em virtude de algum problema na rotina de Atualização de Históricos ou devido a existência de objetos inválidos na base.
Neste caso, devem ser seguidos os passos abaixo para identificar a origem do problema:
1 - A rotina de Atualização de Históricos é disparada automaticamente pelo sistema no primeiro logon do dia e a cada hora ociosa. Esta rotina tem por objetivo atualizar a ficha básica quando são incluídos históricos futuros. Quando ocorre algum problema durante a rotina de atualização, a mesma é abortada e o motivo é gravado em log de processamento, tipo 64. Caso o problema não seja acertado, a rotina volta a executar e é abortada pelo mesmo motivo, gerando depois de algum tempo, várias informações desatualizadas na ficha básica, divergindo do que consta nos históricos.
Por este motivo, sempre que for identificado este tipo de problema, deve-se verificar o log de processamento disponível em Diversos > Log > Processamentos, consultando o tipo 64 - Atualização de Históricos, para identificar se ocorreu algum erro durante a execução desta rotina. Esta verificação no log deve ser periódica, pois pode ocorrer algum tipo de problema a qualquer momento.
2 - No caso de não haver informações a listar na consulta de log de processamentos do tipo 64 nos últimos dias, verificar se existe algum processo automático de Histórico (Recursos > Processos Automáticos > Históricos) cujo campo Executa Rotina Padrão esteja habilitada.
Quando este campo está com S o sistema deixa de executar a atualização dos históricos no primeiro acesso do dia (padrão) para ser executado somente através do Processo Automático. Se a periodicidade deste processo for muito grande ou ocorrer qualquer outro problema no Middleware que impossibilite a execução do processo, a atualização de históricos não será efetuado e a ficha básica permanecerá desatualizada.
3 - É bastante comum encontrarmos problemas de sobreposição de afastamento (informações antigas) que provocam erro na execução da rotina de Atualização de Históricos. Para verificar se existe alguma sobreposição, podem ser utilizados os relatórios existentes para esta finalidade: No Administração de Pessoal, Colaboradores > Históricos > Listar, modelo 17 e no Controle de Ponto, Colaboradores > Listar, modelo 12.
Após listar estes modelos, as inconsistências apresentadas devem ser ajustadas.
4 - Para entender o funcionamento da rotina de Atualização de Históricos, existe um campo de Status em cada uma das tabelas de histórico. Seu conteúdo pode identificar que o histórico é futuro, atual ou passado, dependendo da tabela. A rotina verifica a data atual, com a data do histórico e atualiza a informação do Status. A partir daí, a atualização da ficha básica (R034FUN) é feita através de Triggers e Stored Procedures. Caso elas estejam inválidas ou não existam na base, a situação a ser encontrada será: o Status estará de acordo, mas a informação na ficha básica não estará atualizada.
Neste caso, será necessário recriar as Stored Procedures e Triggers, seguindo as orientações abaixo:
=> Criação das Stored Procedures:
No CBDS, ir na Tree view (lista de pastas) localizada do lado esquerdo da tela e selecionar a última pasta (Stored Procedure);
Clicar com o botão direito do mouse;
Selecionar a opção Enviar para;
Selecionar a opção Executar.
=> Criação das Triggers:
No CBDS, selecionar a opção de menu Ferramentas > Alterar Tabelas;
Na tela que será exibida, selecionar todas as tabelas clicando no botão >> ;
Em Objetos selecionar Trigger e desabilitar as demais opções;
Em Comando selecionar a opção correspondente, sendo:
Criar - Se a base não possuir triggers ainda
Recriar - Caso já existam Triggers na base(situação padrão). Obs. Neste caso o CBDS irá apagar as triggers antigas antes de ativar as novas.
Em Destino habilitar a opção executar no banco;
Clicar em Processar.
Atenção! Quando executar o procedimento a cima, não poderá ter nenhum usuário conectado no Banco de Dados, somente o usuário Administrador do sistema que irá efetuar a recriação no aplicativo CBDS.exe.
5 - Para verificar se ainda existem objetos inválidos na base, se o Banco de Dados for Oracle, poderá ser utilizado o seguinte comando:
select * from user_objects where status='INVALID'
IMPORTANTE 1:
Foi implementada na versão 5.5.1.20, a guia 'Manut. Base de Dados' em Diversos > Assinalamentos com a finalidade de alertar o administrador do banco de dados via e-mail ou até bloquear o acesso ao sistema caso existam triggers inválidas, colocando a Base em manutenção no CBDS.
Esta guia possui 3 assinalamentos:
- Bloquear Acesso Triggers Inválidas: Possui as opções S (padrão) e N.
- Tipo de Verificação: Com os valores H - Somente Históricos e T - Todas as Tabelas.
- E-mail para Aviso: Permite informar o e-mail do administrador do banco.
A verificação ocorre somente no primeiro login do dia, e caso haja alguma trigger inválida a base é marcada como manutenção e a entrada no sistema é abortada. Caso o usuário defina para que a entrada no sistema não seja bloqueada, a rotina somente envia o e-mail e faz a gravação dos logs no primeiro login do dia.
Foi implementada consistência para que a verificação não seja realizada nos bancos SQL Server e Sybase Server, nos quais a implementação não está disponível.