BLV Técnico Versão 5.04 (Continuação)

Rotina GERA_FITABANCO em modo multi-empresa

Visão do usuário:

Para a rotina GERA_FITABANCO gerar os registros na tabela FITABANCO por empresa, foi necessário adicionar a função FLAG_PACK.GET_EMPRESA nos cursores principais da rotina.

As consultas dos parâmetros mês/ano e número da folha foram alteradas para consultarem as folhas para a empresa corrente.

Com essas modificações o procedimento correto para a execução da rotina GERA_FITABANCO deverá ser o seguinte:

1) Para gerar informações no FITABANCO para determinada folha, o usuário responsável pela execução, deverá estar com a transação "Executa Rotinas" conectada na empresa para a qual se deseja gerar a fita. Isso é feito acionando o botão "EMP" na barra de botões no cabeçalho da tela;

2) Completado o passo acima, selecionar a rotina e passar os parâmetros adequados, isto é, fornecer uma folha que pertença a empresa corrente (isso é determinado pela lista de valores dos próprios parâmetros);

3) Acompanhe a execução da rotina pela transação de "Auditoria de Processos!" e verifique que na indicação dos parâmetros de execução, agora é listada a empresa da execução selecionada.

4) Fazer o procedimento para cada empresa controlada pela sistema.

Detalhes Técnicos:

Para a rotina GERA_FITABANCO gerar os registros na tabela FITABANCO por empresa, foi necessário adicionar a função FLAG_PACK.GET_EMPRESA nos cursores principais da rotina, ou seja, os cursores C_FF e C_FFEXTRA. Além disso, foi adicionado também nos WHERE's do DELETE dos dados que estão sendo re-processados e no DELETE dos funcionários com estorno.

As consultas dos parâmetros mês/ano e número da folha foram alteradas para consultarem a tabela FOLHAS_EMP e na clausula WHERE foi adicionada a condição EMP_CODIGO = FLAG_PACK.GET_EMPRESA.

Com essas modificações o procedimento correto para a execução da rotina GERA_FITABANCO deverá ser o seguinte:

3) Acompanhe a execução da rotina pela transação de "Auditoria de Processos!" e verifique que na indicação dos parâmetros de execução, agora é listada a empresa da execução selecionada.

4) Fazer o procedimento para cada empresa controlada pela sistema.

Tabela TIPO_FOLHA independente de empresa

Visão do usuário:

Na transação Tipos de Folha, o cadastro dos tipos de folhas será independente de empresa.

Detalhes Técnicos:

Na transação Tipos de Folha, o cadastro dos tipos de folhas será independente de empresa.

Na tabela TIPO_FOLHA, o campo emp_codigo foi removido. Nos scripts de migração, a chave primária de TIPO_FOLHA será recriada, e terá como chave primária o campo TIPO. Para que seja possível ter como chave primária o campo TIPO, não deverá haver registros duplicados com o mesmo tipo. Registros com o mesmo tipo de folha serão removidos, de forma de exista somente um registro com um determinado tipo de folha.

Faça um backup dessa tabela antes da migração, e depois da migração verifique se está valida a chave primária TIPOFOL_PK de TIPO_FOLHA e a chave estrangeira FOLHA_TIPOFOL_FK.

Verifique que os selects em TIPO_FOLHA não deverá ser restrito por empresa.

Marcação de finais de semana

Visão do usuário:

Foi corrigido o problema para marcar os finais de semana na transação Tipos de Calendário.

Detalhes Técnicos:

Foi corrigido o problema para marcar os finais de semana na transação Tipos de Calendário. O problema acontecia quando o forms era instalado em português. Foi alterado a procedure MARCA_FIM_SEMANA.

Arquivo de PASEP sem caracteres com acentos

Visão do usuário:

Na transação Arquivos de PASEP, os arquivos serão gerados sem os acentos e em letras maiúsculas.

Detalhes Técnicos:

Na transação Arquivos de PASEP, os arquivos serão gerados sem os acentos e em letras maiúsculas.

Navegação na transação Informe de Rendimentos e Dirf

Visão do usuário:

Na transação Informe de Rendimentos e Dirf, foram corrigidos problemas de navegação. Os campos de Ano Base terão como valor inicial o ano anterior ao ano vigente. Se o usuário estiver na pasta Informe de Rendimentos e navegar para a pasta Totais da Dirf, os valores do filtro serão passados para o filtro da nova pasta. Nos filtros das pastas Informe de Rendimentos e Totais da Dirf, para que seja feito as pesquisas correspondentes, basta navegar através do teclado que o programa irá para o bloco de consulta.

Detalhes Técnicos:

Lista de valores de folhas na transação Cálculo Parcial

Visão do usuário:

Na transação Cálculo Parcial, a lista de valores para a folha irá mostrar apenas as folhas da empresa logada.

Detalhes Técnicos:

Na transação Cálculo Parcial, a lista de valores para a folha irá mostrar apenas as folhas da empresa logada.

Problema na geração do arquivo de crédito

Visão do usuário:

Na transação geração de arquivos de crédito bancário, foi corrigido o problema ORA-01400: Cannot insert NULL into ERG_TEMP_CARGAFB.SEQ

Detalhes Técnicos:

Na transação geração de arquivos de crédito bancário, foi corrigido o problema ORA-01400: Cannot insert NULL into ERG_TEMP_CARGAFB.SEQ

Quantidade negativa no cadastro de quadro

Visão do usuário:

Não será permitido o cadastro de compromissos, reservas , distribuições ou quadros com quantidade negativa.

Detalhes Técnicos:

Não será permitido o cadastro de compromissos, reservas , distribuições ou quadros com quantidade negativa.

Edição de tela para campos obrigatórios nas transações "Aposentadoria" e "Vacância"

Visão do usuário:

As transações "Aposentadoria" e "Vacância" apresentam algumas características especiais que geram problemas na edição de tela quando se configura algum campo como obrigatório. Sendo assim, não se deve configurar quaisquer campos destas transações como obrigatórios através da edição de tela. Em caso de necessidade, a equipe técnica deverá ser acionada para implementar estas consistências através de codificação específica.

Detalhes Técnicos:

As transações "Aposentadoria" e "Vacância" possuem uma característica que as diferencia das demais transações do sistema. Nestas transações, a exclusão é, na verdade, um UPDATE dos campos referentes à aposentadoria e vacância para NULL. Com isso, caso exista algum campo nestas transações que tenha sido configurado para "Obrigatório" através da edição de tela, ao tentar fazer a remoção o sistema acusará que o campo em questão deve ser preenchido.

Sendo assim, nenhum campo destas transações deverá ser configurado como "Obrigatório" através da edição de tela. Caso seja necessário realizar esta consistência de obrigatoriedade, a equipe técnica deverá implementá-la através da codificação de entry-points da tabela VINCULOS.

Otimização da 2ª VIA DA DIRF

Visão do usuário:

Este relatório se apresentava extremamente demorado para a emissão de um grupo de eleitos com poucos servidores.

A otimização foi feita reduzindo drasticamente o tempo de execução do relatório para um grupo de eleitos.

Além dessa otimização, foi adicionado o parâmetro "Código da Sub-Empresa" para permitir a emissão da segunda via por sub-empresa.

Uma observação importante é que esse relatório é baseado na view de C_Ergon "DIRF_VW_REG_9". Cada cliente tem a flexibilidade de alterar essa view conforme a suas necessidades, porém os nomes das colunas que estão no código padrão enviado com o CD de instalação do produto não podem ser alterados sob pena de produzir erros na execução desse relatório.

Detalhes Técnicos:

Este relatório se apresentava extremamente demorado para a emissão de um grupo de eleitos com poucos servidores.

O select baseado em UNION com as tabelas: FUNCIONARIOS, PENSIONISTAS, DEPENDENTES; e cada uma com join com a tabela ELEITOS_EXT, foi substituído por um código PL/SQL na trigger de AFTER PARAMETER FORM do relatório, gerando a string "D.CPF IN (CPF1, CPF2, ...)" que é passada na clausula WHERE da consulta principal do relatório.

Além dessa otimização, foi adicionado o parâmetro P_SUBEMPRESA ("Código da Sub-Empresa") para permitir a emissão da segunda via por sub-empresa.

Correção para permitir cargas paralelas de atributos

Visão do usuário:

A transação de "Carga de Atributos" utiliza uma tabela temporária para fazer as validações e emitir os arquivos de aceitos, rejeitados e erros. Para cada carga, é executado comando para limpar toda a tabela e gerado uma chave que indexa os registros da carga que serão inseridos na tabela temporária. Através dessa chave esses registros são consultados pelas rotinas internas à tela.

Como solução do problema, foi substituído o comando para limpar toda a tabela por outro que numa execução não removerá a execução de outro usuário.

A chave passou a ser gerada através de uma seqüência gerando um único número para cada execução e assim as informações que um usuário está carregando não entrarão em conflito com as informações de outra carga.

Foi feita uma otimização na tela, removendo algumas rotinas redundantes e melhorando a auditoria da tela.

As mensagens de auditoria são gravadas nas tabelas utilizadas pela transação "Auditoria de Processos" e o usuário poderá consultar essas informações pelo número da execução que a tela de carga fornecerá durante o processo da carga. Com esse número, o usuário poderá consultar o andamento da carga abrindo outra sessão do sistema.

Detalhes Técnicos:

A transação de "Carga de Atributos" utiliza a tabela temporária CARGA_ATRIB_TEMP para fazer as validações e emitir os arquivos de aceitos, rejeitados e erros. Para cada carga, é executado o comando TRUNCATE para limpar a tabela e gerado uma chave que indexa os registros da carga que serão inseridos na tabela temporária. Através dessa chave esses registros são consultados pelas rotinas internas à tela.

Como solução do problema, foi removido o comando TRUNCATE e substituído pelo comando DELETE e dessa forma uma execução não removerá a execução de outro usuário.

A chave passou a ser gerada através da SEQUENCE CARGA_ATRIB_TEMP que gera um único número para cada execução e assim as informações que um usuário está carregando não entrarão em conflito com as informações de outra carga.

Foi feita uma otimização na tela, removendo algumas rotinas redundantes e melhorando a auditoria da tela.

Anterior Próxima