BLV Técnico Versão 5.03 (Continuação)
Alteração no mecanismo de geração da RAIS.
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 RAIS, a transação "RAIS" (form ERG0192) 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 e neste caso o usuário tem mais a opção "Gerar um arquivo por Sub-empresa?". Se for selecionada, será gerado um arquivo por sub-empresa. Em caso contrário, será gerado um arquivo único para todas as sub-empresas. No bloco "Geração de Informações para RAIS" permite gerar a RAIS em três fases. 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". Portanto, é possível gerar as informações para a RAIS e depois calcular os valores ou executá-los em um único processamento. Internamente, no código do botão, esses processos foram colocados na package PACK_RAIS. Em função da opção selecionada, será executado o procedimento PACK_RAIS. PRC_GERA_INFO ou o procedimento PACK_RAIS. PRC_GERA_VALORES, ou ambos. Após a finalização da geração das informações e dos valores, é possível gerar os arquivos da RAIS.
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. 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 replicá-lo para o novo ano base, apenas será necessário que o período de validade formado 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 "Registro" 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 da "RAIS" por sub-empresa, os procedimentos GERA_ARQ e GERA_REG foram alterados, tendo a adição do parâmetro "código da sub-empresa". Ao disparar a geração dos arquivos para "RAIS", se o valor fornecido para a sub-empresa for "0" (zero) e a opção "Gerar um arquivo por Sub-empresa?" estiver marcada, 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.
Foi elaborado um conjunto de rotinas para compatibilizar os cálculos anteriores da RAIS para a nova versão.
Detalhes Técnicos:
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 RAIS, a transação "RAIS" (form ERG0192) 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 e neste caso o usuário tem mais a opção "Gerar um arquivo por Sub-empresa?". Se for selecionada, será gerado um arquivo por sub-empresa. Em caso contrário, será gerado um arquivo único para todas as sub-empresas. No bloco "Geração de Informações para RAIS" permite gerar a RAIS em três fases. 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". Portanto, é possível gerar as informações para a RAIS e depois calcular os valores ou executá-los em um único processamento. Internamente, no código do botão, esses processos foram colocados na package PACK_RAIS. Em função da opção selecionada, será executado o procedimento PACK_RAIS. PRC_GERA_INFO ou o procedimento PACK_RAIS. PRC_GERA_VALORES, ou ambos. Após a finalização da geração das informações e dos valores, é possível gerar os arquivos da RAIS.
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. 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 replicá-lo para o novo ano base, apenas será necessário que o período de validade formado 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 "Registro" 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 da "RAIS" por sub-empresa, os procedimentos GERA_ARQ e GERA_REG foram alterados, tendo a adição do parâmetro "código da sub-empresa". Ao disparar a geração dos arquivos para "RAIS", se o valor fornecido para a sub-empresa for "0" (zero) e a opção "Gerar um arquivo por Sub-empresa?" estiver marcada, 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 o entry-point PCK_CERG_RAIS.GET_NOMEARQ_RAIS para customizações dos nomes dos arquivos da RAIS. 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.
Na parte de banco de dados, para refletir as alterações na transação da "RAIS" algumas rotinas tiveram que ser alteradas.
Os procedimentos PRC_GERA_INFO e PRC_GERA_VALORES que pertenciam ao form, foram removidos e recriados na PACK_RAIS que tem por finalidade conter as rotinas de geração da RAIS e outras tarefas pertinentes a esse processo.
A seguir será descrita a finalidade de cada procedimento/função pertencente à package:
1) procedimento PRC_GERA_INFO: esse procedimento é responsável pela geração das informações para a RAIS. O cursor utilizado para buscar as informações anuais em fichas financeiras para os cálculos necessários, foi otimizado. As consultas foram modificadas, utilizando a 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 como já era feito. Outra alteração, foi a adição do entry-point PCK_CERG_RAIS.EP__RAIS_SELECIONA_FUNC que permite a cada cliente determinar as características dos funcionários que serão excluídos da RAIS. Ainda, com a finalidade de otimizar o procedimento, o comando de insert na tabela RAIS_INFO foi elaborado com BIND ARRAY. Outras mudanças foram feitas na rotina com a finalidade de melhorar a performance. Funcionários inativos desde o primeiro dia de janeiro do ano base serão excluídos da RAIS. O restante do procedimento manteve a estrutura anterior. 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_VALORES: esse procedimento é responsável pelo cálculo dos valores financeiros da RAIS. 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. O que permite restringir a geração por sub-empresa, além da restrição por grupo de eleitos. Ainda, com a finalidade de otimizar o procedimento, os comandos de update na tabela RAIS_INFO 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".
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 da RAIS 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.
4) função RAIS_SALARIO_CTR: essa função utilizada para calcular o salário contratual do funcionário, já existia como uma "stored function". Para facilitar a localização de todas as rotinas envolvidas no processo da RAIS, a função foi removida e incorporada a essa package.
A coluna SUBEMP_CODIGO da tabela RAIS_INFO foi modificada para o tamanho 4.
Para migrar os registros da RAIS que foram calculados em versões anteriores, foi elaborada uma rotina para preencher a coluna SUBEMP_CODIGO com o valor correspondente a sub-empresa do funcionário, ou valor -1 se não for encontrada a sub-empresa. Essa coluna não poderá conter mais valores nulos. Para melhorar a performance nas inserções de dados da RAIS, 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 removida a constraint RAIS_INFO. Foi removida e recriada a primary key RAIS_INFO_PK da tabela com as colunas (NUMFUNC, NUMVINC, ANOBASE, SUBEMP_CODIGO, EMP_CODIGO). Os parâmetros dos índices da tabela também foram configurados para NOLOGGING e PARALLEL (DEGREE DEFAULT).
As colunas SUBEMP_CODIGO (4) e EMP_CODIGO(2) foram adicionadas na tabela CARGARAIS. 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 CARGARAIS_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_RAIS foi alterado para utilizar as funções FLAG_PACK.GET_EMPRESA e PACK_RAIS.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 CARGARAIS, permitindo a geração simultânea de vários arquivos da RAIS 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 RAIS, a tabela RAIS_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 RAIS_REG_PK com as colunas (REGISTRO, ANO_BASE_INI, EMP_CODIGO).
Na tabela dos campos dos leiautes dos registros dos arquivos da RAIS, a tabela RAIS_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 RAIS_CAMPO_PK com as colunas (REGISTRO, CAMPO, ANO_BASE_INI, EMP_CODIGO).
A função RAIS_SALARIO_CTR foi removida e colocada na package PACK_RAIS.
A package PCK_RAIS_INFO foi gerada dentro do padrão sem conter nenhuma rotina importante para o processo da RAIS.
Foi elaborado um conjunto de rotinas para compatibilizar os cálculos anteriores da RAIS para a nova versão.