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

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

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 GFIP, a transação "FGTS" (form ERG0095) 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 "Gerar Arquivo FGTS" permite processar os cálculos e os Arquivos de maneira independente. Para o primeiro cálculo ou se for necessário um novo cálculo, a opção "Reprocessa ?" deve estar selecionada. Se for necessário o cálculo para competência 13 (décimo terceiro), selecionar a opção "Compet 13 ?". Preenchido o ano base, o grupo de eleitos (valor em branco processa todos os funcionários), disparado a geração através do botão "Gerar Arquivo", a geração do arquivo será sempre disparada independente da seleção ou não das opções anteriores. Internamente no código do botão, em função da opção selecionada, será executado o procedimento PACK_SEFIP.PROCESSA_SEFIP e/ou a rotina de geração dos arquivos.

Nesse ponto, deve-se verificar a configuração do leiaute dos registros dos arquivos. O cadastro e a montagem do leiaute é feito nos blocos "Registro" e "Campo". Nesses blocos, 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 mês e ano base de início (campo "Início" na tela) e mês e ano base de término (campo "Fim" na tela). Com isso, se não houver mudanças no leiaute de um mês para outro não haverá a necessidade de replicar o leiaute para o novo mês, apenas será necessário que o período de validade formados pelo "Início" e "Fim" incluam os dois meses em questão. Se houver alguma mudança no leiaute de um mês/ano para outro, basta copiar automaticamente os registros para um novo leiaute e alterar aonde for necessário. Para isso, no bloco de "Registro" foi adicionado o botão chamado "Criar Novo Layout Copiando o Anterior". Acionando o botão, todos os registros válidos no "Mês/Ano Base" fornecido e com o mês/ano de término em aberto, serão copiados para um conjunto de novos registros e campos válidos a partir do "Mês/Ano Base" e com o mês/ano de término ("Fim") em aberto. Os registros anteriores serão fechados no mês/ano anterior ao "Mês/Ano Base". Se esse 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 mês/ano atual.

Feitos os ajustes no leiaute para gerar os arquivos da "GFIP" por sub-empresa, os procedimentos GERA_ARQ e GRAVA_REG foram alterados, tendo a adição do parâmetro "código da sub-empresa". Ao disparar a geração dos arquivos para "GFIP", 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, com o nome fantasia da empresa e o mês/ano de direito para cada "Mês/Ano Base". 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. Os cálculos em banco possuem uma auditoria independente da auditoria da geração dos arquivos.

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

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 GFIP, a transação "FGTS" (form ERG0095) 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 "Gerar Arquivo FGTS" permite processar os cálculos e os Arquivos de maneira independente. Para o primeiro cálculo ou se for necessário um novo cálculo, a opção "Reprocessa ?" deve estar selecionada. Se for necessário o cálculo para competência 13 (décimo terceiro), selecionar a opção "Compet 13 ?". Preenchido o ano base, o grupo de eleitos (valor em branco processa todos os funcionários), disparado a geração através do botão "Gerar Arquivo", a geração do arquivo será sempre disparada independente da seleção ou não das opções anteriores. Internamente no código do botão, em função da opção selecionada, será executado o procedimento PACK_SEFIP.PROCESSA_SEFIP e/ou a rotina de geração dos arquivos.

Nesse ponto, deve-se verificar a configuração do leiaute dos registros dos arquivos. O cadastro e a montagem do leiaute é feito nos blocos "Registro" e "Campo". Nesses blocos, 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 mês e ano base de início (campo "Início" na tela) e mês e ano base de término (campo "Fim" na tela). Com isso, se não houver mudanças no leiaute de um mês para outro não haverá a necessidade de replicar o leiaute para o novo mês, apenas será necessário que o período de validade formados pelo "Início" e "Fim" incluam os dois meses em questão. Se houver alguma mudança no leiaute de um mês/ano para outro, basta copiar automaticamente os registros para um novo leiaute e alterar aonde for necessário. Para isso, no bloco de "Registro" foi adicionado o botão chamado "Criar Novo Layout Copiando o Anterior". Acionando o botão, todos os registros válidos no "Mês/Ano Base" fornecido e com o mês/ano de término em aberto, serão copiados para um conjunto de novos registros e campos válidos a partir do "Mês/Ano Base" e com o mês/ano de término ("Fim") em aberto. Os registros anteriores serão fechados no mês/ano anterior ao "Mês/Ano Base". Se esse 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 mês/ano atual.

Feitos os ajustes no leiaute para gerar os arquivos da "GFIP" por sub-empresa, os procedimentos GERA_ARQ e GRAVA_REG foram alterados, tendo a adição do parâmetro "código da sub-empresa". Ao disparar a geração dos arquivos para "GFIP", 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, com o nome fantasia da empresa e o mês/ano de direito para cada "Mês/Ano Base". Existe o entry-point PACK_CERG_SEFIP.NOME_ARQUIVO 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. Os cálculos em banco possuem uma auditoria independente da auditoria da geração dos arquivos.

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

A package body PACK_SEFIP foi alterada para buscar o CGC da empresa diretamente da tabela SUBEMPRESAS. O código da sub-empresa é pego diretamente da tabela FITABANCO. Com isso, uma simples consulta na tabela SUBEMPRESAS se obtém o CGC.

Todas as consultas baseadas em FICHAS_VINCULOS foram substituídas por consultas sobre a tabela FITABANCO. Assim com a adição do parâmetro P_SUBEMPRESA no procedimento PACK_SEFIP.PROCESSA_SEFIP, foi possível restringir a geração do arquivo de FGTS por sub-empresa.

Todos as rotinas da package que fazem operações nas tabelas ERG_FGTS_REG00 e ERG_FGTS_REG90 tiveram a adição da coluna EMP_CODIGO. As que fazem operações nas tabelas ERG_FGTS_REG10, ERG_FGTS_REG12, ERG_FGTS_REG30, ERG_FGTS_REG32 tiveram a adição da coluna EMP_CODIGO e SUBEMP_CODIGO. Isso permite um controle maior do processo por empresa e sub-empresa.

Outra alteração, é a diferença no cálculo do CBO até o final do ano de 2002 e a partir de 2003, pois o código é alterado de um ano para outro.

Funcionários inativos não entram no cálculo da GFIP, sendo essa exclusão feita diretamente pela view de C_ERGON, a "ERG_VW_FGTS_REG30".

Foram criados os procedimentos SET_VP_MESANO, SET_VP_NUMERO e as funções GET_VP_MESANO, GET_VP_NUMERO. 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 GFIP e para a tela de geração, os valores do mês/ano e número da folha de pagamento, base do geração das informações que estão sendo processadas. Isso permite facilitar e otimizar consultas e outras operações.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_REG00 e na sua primary key ERG_FGTS_REG00_PK.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_ERRO_REG00 e na sua primary key ERG_FGTS_ERRO_REG00_PK.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_DETALHE_ERRO_REG00 e na sua foreign key ERG_FGTS_ERRO_REG00_FK.

Foi adicionada a coluna EMP_CODIGO e SUBEMP_CODIGO na tabela ERG_FGTS_REG10.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_ERRO_REG10 e na sua primary key ERG_FGTS_ERRO_REG10_PK.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_DETALHE_ERRO_REG10 e na sua foreign key ERG_FGTS_ERRO_REG10_FK.

Foi adicionada a coluna EMP_CODIGO e SUBEMP_CODIGO na tabela ERG_FGTS_REG12.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_ERRO_REG12 e na sua primary key ERG_FGTS_ERRO_REG12_PK.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_DETALHE_ERRO_REG12 e na sua foreign key ERG_FGTS_ERRO_REG12_FK.

Foi adicionada a coluna EMP_CODIGO e SUBEMP_CODIGO na tabela ERG_FGTS_REG30.

Foi adicionada a coluna EMP_CODIGO e SUBEMP_CODIGO na tabela ERG_FGTS_REG32.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_REG90 e na sua primary key ERG_FGTS_REG90_PK.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_ERRO_REG90 e na sua primary key ERG_FGTS_ERRO_REG90_PK.

Foi adicionada a coluna EMP_CODIGO na tabela ERG_FGTS_DETALHE_ERRO_REG90 e na sua foreign key ERG_FGTS_ERRO_REG90_FK.

Na tabela dos registros dos arquivos da GFIP, a tabela FGTS_REGISTRO teve a adição das colunas:

MES_ANO_INI DATE NOT NULL,

MES_ANO_FIM DATE,

EMP_CODIGO NUMBER(2) NOT NULL

Foi elaborado um script de migração para preencher as colunas MES_ANO INI com o valor da coluna antiga MES_ANO, MES_ANO_FIM igual ao MES_ANO do layout posterior menos 1 e a EMP_CODIGO com a empresa 1. Foi removida e recriada a primary key FGTS_REG_PK com as colunas (REGISTRO, MES_ANO_INI, EMP_CODIGO).

Na tabela dos campos dos leiautes dos registros dos arquivos da GFIP, a tabela FGTS_CAMPO teve a adição das colunas:

MES_ANO_INI DATE NOT NULL,

EMP_CODIGO NUMBER(2) NOT NULL

Foi elaborado um script de migração para preencher as colunas MES_ANO_INI com o valor da coluna antiga MES_ANO e a EMP_CODIGO com a empresa 1. Foi removida e recriada a primary key FGTS_CAMPO_PK com as colunas (REGISTRO, CAMPO, MES_ANO_INI, EMP_CODIGO), e criada a foreign key FGTS_CAMPO_REGISTRO_FK com as colunas (REGISTRO, MES_ANO_INI, EMP_CODIGO).

Foi elaborado um conjunto de rotinas para compatibilizar os cálculos anteriores da SEFIP para a nova versão.

Anterior Próxima