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

Migração de dados do Ergon para o Hades

Detalhes Técnicos:

A partir da versão 2.23 do Hades e 5.03 do Ergon, os dados de publicação foram incorporados ao Hades também. Isso permitirá que os demais sistemas Archon (incluindo aí o Hades) tenham acesso a este tipo de estrutura.

Para tanto, algumas tabelas do Ergon foram renomeadas e, em virtude disso, as packages PCK_AFTER_CERGON e PCK_BEFORE_CERGON ficariam inválidas se as deixássemos como estavam na versão 5.02. Para evitar o problema de deixar todos os objetos inválidos, recriamos as packages PCK_AFTER_CERGON e PCK_BEFORE_CERGON. Favor reajustá-las após a migração (ler pré-requisitos da versão).

As antigas tabelas do Ergon (ERG_MOTIVOPUBL_, ERG_MOTIVOPUBL_EMPRESA, ERG_MOTIVOPUBL_TABELA, ERG_PUBLICACOES, ERG_PUBLX, ERG_TRANS_PUBL) foram renomeadas com o sufixo _OLD e migradas para as novas tabelas do Hades (HAD_MOTIVOPUBL_, HAD_MOTIVOPUBL_EMPRESA, HAD_MOTIVOPUBL_TABELA, HAD_PUBLICACOES, HAD_PUBLX, HAD_TRANS_PUBL).

Bloqueio de lançamento de registros por empresa

Visão do usuário:

A partir desta versão, só será possível lançar/alterar um registro de uma determinada empresa se o seu registro pai estiver cadastrado para a mesma empresa. Por exemplo, uma especialidade não poderá ser lançada na empresa 2 se o seu cargo correspondente não existir na empresa 2.

Detalhes Técnicos:

A partir desta versão, só será possível lançar/alterar um registro de uma determinada empresa se o seu registro pai estiver cadastrado para a mesma empresa.

Por exemplo : a tabela ESPECIALIDADE_ é dependente da empresa. Assim, ao lançar uma nova especialidade, esta é cadastrada para a empresa na qual o usuário está logado (tabela ESPECIALIDADE_EMPRESA). Ocorre que na tabela ESPECIALIDADE_ existe o campo CARGO que é uma foreign key para a tabela CARGOS_. Sendo assim, ao lançar uma nova especialidade, só será permitido este lançamento se o cargo ao qual ela está associada também existir na empresa para a qual ela está sendo cadastrada. Estas consistências serão geradas automaticamente nas triggers das tabelas, através da execução do script GERA_TRG.SQL.

Bloqueio de remoção de registros por empresa

Visão do usuário:

A partir desta versão, só será possível remover um registro de uma determinada empresa se não houver registros filhos na mesma empresa. Por exemplo, não será possível remover um cargo da empresa 2 se houver especialidades a ele relacionadas também na empresa 2.

Detalhes Técnicos:

A partir desta versão, só será possível remover um registro de uma determinada empresa se não houver registros filhos na mesma empresa.

Por exemplo : para remover um cargo de uma determinada empresa, é necessário que não haja especialidades relacionadas a este cargo na mesma empresa. Caso contrário, uma mensagem de erro será retornada, impedindo a remoção do registro. Estas consistências são geradas automaticamente nas triggers das tabelas, através da execução do script GERA_TRG.SQL.

Cálculo da sub-empresa na geração do arquivo bancário

Visão do usuário:

A partir de agora, o conceito de sub-empresa passa ser utilizado pelo sistema de forma essencial. Sendo assim, é necessário que o cadastro das sub-empresas seja mantido corretamente, sob pena de exclusão de funcionários das diversas rotinas e relatórios do sistema.

Detalhes Técnicos:

Foi adicionada a coluna SUBEMP_CODIGO (NOT NULL) à tabela FITABANCO. Para isso, foi elaborado um script de migração para calcular e popular essa coluna com o código da sub-empresa. Se um setor existe no FITABANCO, mas não existe mais na tabela HSETOR, será populado o valor -1 nessa coluna. Se a sub-empresa for nula, será emitida uma mensagem de erro abortando o processo.

Foi criado o índice FITABANCO_EMP_SUBEMP_FUNC_I sobre as colunas MES_ANO, NUMERO, NUMFUNC,NUMVINC, NUMDEPEN, NUMPENS, EMP_CODIGO, SUBEMP_CODIGO, para otimizar as consultas sobre a tabela.

Na função GERA_FITABANCO foi utilizada a função PACK_HADES.GET_SUBEMPRESA para calcular o código da sub-empresa do setor de lotação do funcionário. Se um setor existe no FITABANCO, mas não existe mais na tabela HSETOR, será populado o valor -1 para a SUB-EMPRESA. Se a sub-empresa for nula, será gravada uma mensagem de erro na auditoria e o valor da SUB-EMPRESA será de -1.

Portanto, a partir de agora, o conceito de sub-empresa passa ser utilizado pelo sistema de forma essencial e qualquer problema no cadastro da sub-empresa, ocasionará a exclusão do funcionário das diversas rotinas e relatórios do sistema. E com esse novo procedimento, a sub-empresa será pega da tabela FITABANCO.

Alteração no mecanismo de geração da DIRF.

Visão do usuário:

O conceito de sub-empresas passou a ser fundamental para o sistema. Qualquer setor que possua um CGC diferente do CGC da Instituição passa a ser uma sub-empresa. Ao menos o cadastro de uma sub-empresa passa a ser obrigatório, ou seja, a própria Instituição passa a ter um código de sub-empresa e a medida que surgirem setores com CGC próprio, uma sub-empresa correspondente deverá ser cadastrada. Para se adequar a geração dos arquivos por sub-empresa e às mudanças na forma de cadastro e administração dos layout dos registros que compõem os arquivos da DIRF e do Informe de Rendimentos, a transação "DIRF" (form ERG0072) teve que ser alterada. Ao chamar a transação, o usuário terá que fornecer obrigatoriamente um código para a sub-empresa. Se for "0" (zero) representa que o processo será executado para todas as sub-empresas. No bloco "Geração de Informações para Dirf'" permite gerar o Informe de Rendimentos e a DIRF de maneira independente. Preenchido o ano base, o grupo de eleitos (valor "0" processa todos os funcionários), deve-se selecionar no mínimo um processo e disparar a geração através do botão "Gerar Informações". Se for selecionado os dois processos, na ordem de processamento será primeiro o Informe de Rendimentos e depois a DIRF. Internamente no código do botão, em função da opção selecionada, será executado o procedimento PACK_DIRF.PRC_GERA_INFO_REND ou o procedimento PACK_DIRF.PRC_GERA_INFO_DIRF, ou ambos. Após a finalização da geração das informações é possível gerar os arquivos de Informe de Rendimentos e da DIRF.

Nesse ponto, deve-se verificar a configuração do leiaute dos registros dos arquivos. O cadastro e a montagem do leiaute é feito na ficha "Layout do Arquivo". Nessa ficha, outras mudanças foram feitas para facilitar a edição do leiaute. O leiaute, formado pelos registros e pelos seus campos, apresenta um período de validade determinado pelo "Ano Inicial" e "Ano Fim". Com isso, se não houver mudanças no leiaute de uma ano base para outro não haverá a necessidade de replicar o leiaute para o novo ano base, apenas será necessário que o período de validade formados pelo "Ano Inicial" e "Ano Fim" incluam os dois anos bases. Outra facilidade apresentada, é que não há mais a necessidade de se cadastrar um novo leiaute apenas para preencher o ano base, pois fornecendo a palavra chave ANOBASE no "Campo View", a tela determinará automaticamente o ano base do processamento. Se houver alguma mudança no leiaute de um ano para outro, basta copiar automaticamente os registros para um novo leiaute e alterar aonde for necessário. Para isso, no bloco de "Tipos de Registro para DIRF" foi adicionado o botão chamado "Criar Novo Layout Copiando o Anterior". Acionando o botão, todos os registros válidos no ano base fornecido e com o "Ano Fim" em aberto, serão copiados para um conjunto de novos registros e campos válidos a partir do ano base e com o "Ano Fim" em aberto. Os registros anteriores serão fechados no ano anterior ao ano base. Se o ano base for nulo, a consulta será feita sobre todos os registros de layout e ao criar um novo layout automaticamente, será gerado um válido a partir do ano atual.

Feito os ajustes no leiaute, para gerar os arquivos de "Informe de Rendimentos" e da "DIRF" por sub-empresa, os procedimentos GERA_ARQ_DIRF, GERA_ARQ_INFODECL e GERA_REG foram alterados, tendo a adição do parâmetro "código da sub-empresa". Ao selecionar a geração do arquivo para "Informe de Rendimentos" ou para "DIRF", se o valor fornecido para a sub-empresa for "0" (zero), será gerado um arquivo por sub-empresa concatenando o nome fornecido pelo usuário com o nome fantasia da sub-empresa e com o nome fantasia da empresa. Existe a possibilidade de customizar os nomes dos arquivos. Alterações no mecanismo de geração, permitem várias gerações de arquivos simultaneamente por várias telas. Por fim, todo processo é monitorado através da auditoria de processos.

As fichas "Informe de Rendimentos" e "Totais da DIRF" também sofreram alterações. A finalidade dessas fichas é permitir a consulta aos resultados da geração do Informe de Rendimentos e da DIRF. Porém, novas funcionalidades foram adicionadas.

Outra facilidade incorporada é a adição no bloco de "Filtros" os campos de identificação do funcionário e do CPF, permitindo selecionar o funcionário desejado para consulta. Se os campos forem deixados em branco a consulta será geral. Outra mudança é a adição da descrição do fator na ficha de "Informe de Rendimentos".

Foi elaborado um conjunto de rotinas para acertar os "FATORES DA DIRF" após a migração para a versão 5.03. Os fatores com nome diferentes dos presentes nesses scripts serão removidos. Somente os fatores de uso no sistema permanecerão cadastrados.

Detalhes Técnicos:

Feito os ajustes no leiaute, para gerar os arquivos de "Informe de Rendimentos" e da "DIRF" por sub-empresa, os procedimentos GERA_ARQ_DIRF, GERA_ARQ_INFODECL e GERA_REG foram alterados, tendo a adição do parâmetro "código da sub-empresa". Ao selecionar a geração do arquivo para "Informe de Rendimentos" ou para "DIRF", se o valor fornecido para a sub-empresa for "0" (zero), será gerado um arquivo por sub-empresa concatenando o nome fornecido pelo usuário com o nome fantasia da sub-empresa e com o nome fantasia da empresa. Existe os entry-points PACK_CERG_DIRF.GET_NOMEARQ_DIRF e PACK_CERG_DIRF.GET_NOMEARQ_INFOREND para customizações dos nomes dos arquivos. Alterações no mecanismo de geração, permitem várias gerações de arquivos simultaneamente por várias telas. Por fim, todo processo é monitorado através da auditoria de processos.

Agora é possível fazer alterações de valores e remoção de registros em ambas as fichas. Essa nova característica exige um controle de segurança maior sobre essa transação o que pode ser feito facilmente com a utilização de um padrão de acesso específico para usuários qualificados a fazer essas operações. A maior alteração foi na ficha "Totais da DIRF". O bloco "Totais" não é baseado mais na tabela DIRF_TOTAIS e sim numa consulta. Essa consulta foi elaborada para extrair a remuneração mensal do funcionário dentro de um determinado ano base e mostrá-la linha por linha, cada qual correspondendo a um mês do ano. Mas cada linha corresponde na realidade a uma única linha na tabela que contém todas as informações. Para controlar as operações de UPDATE e DELETE para o bloco, foi criado um bloco auxiliar e algumas trigger de bloco do tipo "Key-..." para controlar e executar as alterações e as remoções de registros neste bloco.

Na parte de banco de dados, para refletir as alterações na transação da "DIRF" algumas rotinas tiveram que ser alteradas.

O procedimento PRC_GERA_INFO que pertencia ao form, foi removido. No seu lugar, foi criada a package PACK_DIRF que tem por finalidade conter as rotinas de geração da DIRF, do Informe de Rendimentos e outras tarefas pertinentes a esses processos.

A seguir será descrito a finalidade de cada procedimento/função pertencente à package:

1) procedimento PRC_GERA_INFO_REND: esse procedimento é responsável pela geração do Informe de Rendimentos. O cursor utilizado para buscar as informações anuais em fichas financeiras para os cálculos necessários, foi otimizado. As consultas foram modificadas, substituindo a tabela FICHAS_VINCULOS pela tabela FITABANCO. Com isso, o código da sub-empresa é pego diretamente da tabela FITABANCO. Isso também permite restringir a geração por sub-empresa, além da restrição por grupo de eleitos com já era feito. Ainda, com a finalidade de otimizar o procedimento, os comandos de insert nas tabelas DIRF_ITENS e DIRF_CPF_NOME e update na DIRF_CPF_NOME foram elaborados com BIND ARRAY. O procedimento é todo monitorado, mostrando toda a seqüência de execução do processo na transação de "Auditoria de Processos".

2) procedimento PRC_GERA_INFO_DIRF: esse procedimento é responsável pela geração da DIRF. O cursor utilizado para buscar as informações anuais em fichas financeiras para os cálculos necessários, foi otimizado. As consultas foram modificadas, substituindo a tabela FICHAS_VINCULOS pela tabela FITABANCO. Com isso, o código da sub-empresa é pego diretamente da tabela FITABANCO. Isso também permite restringir a geração por sub-empresa, além da restrição por grupo de eleitos com já era feito. Ainda, com a finalidade de otimizar o procedimento, os comandos de insert na tabela DIRF_TOTAIS foi elaborado com BIND ARRAY. O procedimento é todo monitorado, mostrando toda a seqüência de execução do processo na transação de "Auditoria de Processos".

3) procedimentos SET_SUBEMPRESA, SET_ELEITOS, SET_ANOBASE e as funções GET_SUBEMPRESA, GET_ELEITOS e GET_ANOBASE: os procedimentos são utilizados para atribuir valores para variáveis internas cujos valores serão retornados pelas funções. A finalidade é disponibilizar para as views do layout dos arquivos de Informe de Rendimentos e da DIRF e para a tela de geração, os valores do código da sub-empresa, do grupo de eleitos e do ano base que estão sendo processados. Isso permite facilitar e otimizar consultas e outras operações.

A coluna SUBEMP_CODIGO da tabela DIRF_TOTAIS foi modificada para o tamanho 4.

Para melhorar a performance nas inserções de dados da DIRF, a tabela foi colocada em NOLLOGGING. Como as informações nesta tabela são reprodutíveis a qualquer momento, não há riscos de utilizar essa opção. Para melhorar também as consultas, o parâmetro PARALLEL foi colocado em DEGREE DEFAULT. Além dos parâmetros de banco para essa tabela, foi recriado o índice DIRF_TOTAIS_CPF sobre as colunas (EMP_CODIGO, SUBEMP_CODIGO, ANOBASE, CPF) e criado o índice DIRF_TOTAIS_SUBEMP_I sobre as colunas (EMP_CODIGO, SUBEMP_CODIGO, ANOBASE). Os parâmetros dos índices da tabela também foram configurados para NOLOGGING e PARALLEL (DEGREE DEFAULT).

A coluna SUBEMP_CODIGO da tabela DIRF_ITENS foi modificada para o tamanho 4.

Para melhorar a performance nas inserções de dados do Informe de Rendimentos, a tabela foi colocada em NOLLOGGING. Como as informações nesta tabela são reprodutíveis a qualquer momento, não há riscos de utilizar essa opção. Para melhorar também as consultas, o parâmetro PARALLEL foi colocado em DEGREE DEFAULT. Além dos parâmetros de banco para essa tabela, foi recriado o índice DIRF_ITENS_CPF sobre as colunas (EMP_CODIGO, SUBEMP_CODIGO, ANOBASE, CPF) e criado o índice DIRF_ITENS_SUBEMP_I sobre as colunas (EMP_CODIGO, SUBEMP_CODIGO, ANOBASE). Os parâmetros dos índices da tabela também foram configurados para NOLOGGING e PARALLEL (DEGREE DEFAULT).

A tabela DIRF_CPF_NOME_TEMP foi renomeada para DIRF_CPF_NOME. A coluna SUBEMP_CODIGO foi modificada para o tamanho 4. Para melhorar a performance nas inserções de dados do Informe de Rendimentos, a tabela foi colocada em NOLLOGGING. Como as informações nesta tabela são reprodutíveis a qualquer momento, não há riscos de utilizar essa opção. Para melhorar também as consultas, o parâmetro PARALLEL foi colocado em DEGREE DEFAULT. Foi elaborada uma rotina para popular a coluna SUBEMP_CODIGO com valores diferentes de nulo, já que essa coluna não poderá ser mais nula. Ao final da rotina os registros com CPF´S inexistentes serão removidos. Foi removida e recriada a primary key DIRF_CPF_NOME_PK da tabela com as colunas (CPF, SUBEMP_CODIGO, EMP_CODIGO). Os parâmetros dessa primary key também foram configurados para NOLOGGING e PARALLEL (DEGREE DEFAULT).

As colunas SUBEMP_CODIGO (4) e EMP_CODIGO(2) foram adicionadas na tabela CARGADIRF. Para melhorar a performance nas inserções de dados do Informe de Rendimentos, a tabela foi colocada em NOLLOGGING. Como as informações nesta tabela são reprodutíveis a qualquer momento, não há riscos de utilizar essa opção. Para melhorar também as consultas, o parâmetro PARALLEL foi colocado em DEGREE DEFAULT. Foi removida e recriada a primary key CARGADIRF_PK da tabela com as colunas (ORDEM, SUBEMP_CODIGO, EMP_CODIGO). Os parâmetros dessa primary key também foram configurados para NOLOGGING e PARALLEL (DEGREE DEFAULT).

O procedimento EXEC_SELECT_DIRF foi alterado para utilizar as funções FLAG_PACK.GET_EMPRESA e PACK_DIRF.GET_SUBEMPRESA. Assim é possível fazer a seleção de qual empresa e sub-empresa pertencem as informações que serão inseridas na tabela temporária CARGADIRF, permitindo a geração simultânea de vários arquivos da DIRF e Informe de Rendimentos por mais de uma transação ativa. O tamanho da linha de um arquivo não pode ultrapassar 4000, senão uma mensagem de erro é emitida. A variável que contém essa linha foi aumentada para VARCHAR2(4000).

Na tabela dos registros dos arquivos da DIRF e de Informe de Rendimentos, a tabela DIRF_REGISTRO teve a adição das colunas:

ANO_BASE_INI NUMBER(4) NOT NULL,

ANO_BASE_FIM NUMBER(4),

EMP_CODIGO NUMBER(2) NOT NULL

Foi elaborado um script de migração para preencher as colunas ANO_BASE_INI com o valor da coluna antiga ANO_BASE, ANO_BASE_FIM igual ao ANO_BASE do layout posterior menos 1 e a EMP_CODIGO com a empresa 1. Para o ano de 2002, os registros e as views de C_ERGON correspondentes que compõe o layout dos arquivos para este ano, são inseridos por scripit. Foi removida e recriada a primary key DIRF_REG_PK com as colunas (REGISTRO, ANO_BASE_INI, EMP_CODIGO).

Na tabela dos campos dos leiautes dos registros dos arquivos da DIRF e de Informe de Rendimentos, a tabela DIRF_CAMPO teve a adição das colunas:

ANO_BASE_INI NUMBER(4) NOT NULL,

EMP_CODIGO NUMBER(2) NOT NULL

Foi elaborado um script de migração para preencher as colunas ANO_BASE_INI com o valor da coluna antiga ANO_BASE e a EMP_CODIGO com a empresa 1. Foi removida e recriada a primary key DIRF_CPO_PK com as colunas (REGISTRO, ORDEM, ANO_BASE_INI, EMP_CODIGO), e foi removida e recriada a unique key IRF_CAMPO_UK com as colunas (REGISTRO, CAMPO, ANO_BASE_INI, EMP_CODIGO).

Foi elaborado um conjunto de scripts para acertar os "FATORES DA DIRF" após a migração para a versão 5.03. Os fatores com nome diferentes dos presentes nesses scripts serão removidos. Somente os fatores de uso no sistema permanecerão cadastrados.

Anterior Próxima