Histórico da Página

A rotina conversão conhecida como GPECONV foi desenvolvida para auxiliar no upgrade para a nova folha de pagamento adequando às informações conforme a nova estrutura do produto.

O conversor foi desenvolvido baseando-se no Upgrade da versão 11.80 para a versão 12 devido à estrutura das tabelas, porém o mesmo poderá ser executado em ambientes advindos de outras versões, porém com a ressalva da validação das informações nas tabelas e que serão descritas no decorrer deste documento.

Importante ressaltar que a ferramenta disponibilizada tem como principal intuito ajustar as informações conforme a nova estrutura, porém como é muito comum no Protheus a intervenção através de customizações ou manuais no banco de dados, é necessário a validação completa dos dados, pois poderão ocorrer inconsistências nestas conversões. 

Antes do inicio da execução do conversor para a versão 12 é necessário realizar o planejamento das atividades e estratégias das atuações para os procedimentos.

Os pontos de atenção para a definição desta estratégia estão relacionados aos seguintes tópicos:

1. Definir se a conversão inicialmente ocorrerá para todas as filiais ou para apenas uma parte considerando a validação das conversões.
2. O ideal para conversão é que o período/competência da folha de pagamento na versão origem esteja com todos os processos fechados, ou seja, iniciando-se o próximo período de cálculo. Mas caso não seja possível será necessário a conferência na nova versão contemplando o fechamento para as baixas do período de férias, afastamentos, valores futuros e as verbas do mês seguinte (férias mês seguinte, insuficiência de saldo, etc.)
3. Na versão 11 o período aquisitivo de férias considerava apenas o último período em aberto e a conversão gera todo o histórico do período aquisitivo através dos cálculos de férias efetuadas. Deverá analisar se todos os períodos pagos desde a admissão dos funcionários fazem parte do histórico no sistema, pois caso não tenham sido importados no momento da implantação do Protheus, deverá ser definido a estratégia de carga, pois o conversor gerará os períodos inexistente no cálculo como aberto. Definir junto ao cliente se haverá necessidade de geração do histórico dos períodos aquisitivos dos funcionários inativos (demitidos).
4. O maior volume para a conversão esta relacionado ao histórico da ficha financeira (SRD) e o GPECONV permite a seleção por períodos, permitindo assim a definição das janelas de conversão.
5. Cálculo de Férias e Rescisão: Definir se houve cálculo de férias e as informações foram trazidas para a conversão dos períodos em aberto na versão 12. 

Além dos itens descritos acima, sugere-se alguns procedimentos para garantir a qualidade da conversão.

1. Realizar o backup das tabelas do RH para eventuais necessidades de novas execuções do GPECONV - evitar assim novos Upgrades de todo o ERP.
2. Verificar na tabela de histórico de lançamentos se possuem verbas na mesma competência com mesma sequencia – Existindo esta situação deverá ser ajustado a base.
3. Verificar se na tabela de cálculo das férias (SRH) não possuem registros com o campo RH_DTITENS com a mesma data e para o mesmo funcionário - Existindo esta situação deverá ser ajustado a base
4. Se a migração ocorreu em uma versão anterior à 11.80, as informações da tabela de parâmetros serão migradas incorretamente – Para esta situação deverá atualizar para a estrutura da versão 11.80 ou ajustar manualmente após a conversão.
5. Cálculo de férias: Se houver situações no ambiente migrado com férias calculas e com situações de de férias partidas, será necessário realizar novamente o cálculo destes funcionários na versão 12 devido à mudança das verbas geradas. Se possível, planejar o Upgrade para o período após o fechamento da folha de pagamento (rotina GPEM120) – desta forma evitará diversos problemas com o Conversor.

Após a conclusão da conversão de dados faz-se necessário a conferência das informações convertidas. As principais informações para a conferência são:

1. Verbas Mês Seguinte: validar se as informações geradas na tabela de Incidências (RGB) foram convertidas corretamente na conversão ou após a execução do fechamento, de acordo com a estratégia adotada
2. Período Aquisitivo (SRF): Esta tabela é uma das mais impactadas, pois considera-se todo o histórico do período aquisitivo desde sua admissão, e sua correta conversão dependerá do histórico de pagamento das férias. A conferência destas informações deverá considerar os períodos aquisitivos gerados, o saldo de dias de férias para cada período, o status do período, as faltas e afastamentos que impactam diretamente na perda dos dias de férias ou até mesmo do período aquisitivo.
   O conversor fará a geração de todos os períodos desde sua admissão e a atualização de status será realizada através do cálculo gravado na tabela (SRH). Conferir as informações principalmente de funcionários muito antigos e que possuem histórico de NÃO MIGRAÇÃO do cálculo para avaliarem se as informações estão corretas.
3. Cálculo de Férias: Este tema tem impacto nos casos em que o upgrade ocorreu com cálculo de férias e folha de pagamento em aberto. Para estes casos será necessário recalcular as férias e realizar a conferência dos valores pagos ao funcionário na versão 11 e a verba líquida deverá ser idêntica entre as 2 versões. A diferença esta no desmembramento analítico do cálculo das verbas de adicionais e férias do mês e mês seguinte.
4. Cadastro de períodos: Validar os períodos gerados de acordo com o histórico contido no sistema. De acordo a estratégia adotada para os cálculos consultar se a data de integração foram preenchidos. Os períodos são gerados considerando informações informações históricas das seguintes tabelas:
   
   • SRD: Histórico de movimentos (RD_DATARQ)
   • SRH: Cabeçalho de Férias (RH_DATABAS)
   • SR8: Afastamentos (R8_DATAINI)
   • SRI: Tabela de 13º. Salário (RI_DATA)
   • Criação dos períodos atuais (através do MV_FOLMES
   Cadastro de funcionários: Verificar se os campos foram preenchidos e seguindo as regras definidas para a conversão.:
    
   1. RA_PROCES:
      
      1. RA_TIPOPGT = 'M' ==> '00003'
      2. RA_CATFUNC = 'A' ou 'P' e RA_TIPOPGT = 'S' ==> '00004'
      3. RA_TIPOPGT = 'S' ==> '00002'
      4. Para os demais será gravado com o código '00001'
   2. RA_HRSDIA ==> RA_HRSMES / 30
   3. RA_ADCINS 
      1. RA_INSMIN > 0 ==> ‘2’
      2. RA_INSMED > 0 ==> ‘3’
      3. RA_INSMAX > 0 ==> ‘4’
      4. Para as demais situações será gravado como ‘1’
   4. RA_INSMAX
      1. RA_INSMAX = 0 e RA_INSMED >= 999 ==> RA_HRSMES
      2. RA_INSMAX = 0 e RA_INSMED > 0 ==> RA_INSMED
      3. RA_INSMAX = 0 e RA_INSMIN >= 999 ==> RA_HRSMES
      4. RA_INSMAX = 0 e RA_INSMIN > 0 ==> RA_INSMIN
      5. RA_INSMAX >= 999 ==> RA_HRSMES
      6. Para as demais situações RA_INSMAX
         
   5. RA_ADCPERI
      1. RA_PERICUL > 0 è ‘2’
      2. Para as demais situações ‘1’
   
   
5. Cadastro de períodos: 
   
   • SRD: Histórico de movimentos (RD_DATARQ)
   • SRH: Cabeçalho de Férias (RH_DATABAS)
   • SR8: Afastamentos (R8_DATAINI)
   • SRI: Tabela de 13º. Salário (RI_DATA)
   • Criação dos períodos atuais (através do MV_FOLMES
   
   
6. Verbas Mês Seguinte: validar se as informações geradas na tabela de Incidências (RGB) foram convertidas corretamente na conversão ou após a execução do fechamento, de acordo com a estratégia adotada
   
   
7. Período Aquisitivo (SRF): Esta tabela é uma das mais impactadas, pois considera-se todo o histórico do período aquisitivo desde sua admissão, e sua correta conversão dependerá do histórico de pagamento das férias. A conferência destas informações deverá considerar os períodos aquisitivos gerados, o saldo de dias de férias para cada período, o status do período, as faltas e afastamentos que impactam diretamente na perda dos dias de férias ou até mesmo do período aquisitivo.
   O conversor fará a geração de todos os períodos desde sua admissão e a atualização de status será realizada através do cálculo gravado na tabela (SRH). Conferir as informações principalmente de funcionários muito antigos e que possuem histórico de NÃO MIGRAÇÃO do cálculo para avaliarem se as informações estão corretas.
   
   
8. Cálculo de Férias: Este tema tem impacto nos casos em que o upgrade ocorreu com cálculo de férias e folha de pagamento em aberto. Para estes casos será necessário recalcular as férias e realizar a conferência dos valores pagos ao funcionário na versão 11 e a verba líquida deverá ser idêntica entre as 2 versões. A diferença esta no desmembramento analítico do cálculo das verbas de adicionais e férias do mês e mês seguinte.
   
   
9. Cadastro de Verbas: Com o desmembramento das verbas de adicionais no cálculo das férias para atender ao salário complexivo, foi necessário a criação de novos identificadores de cálculos que são gerados no momento da conversão. Conferir se as verbas foram realmente criadas e se as incidências estão de acordo com as necessidades dos clientes.
   E outras alterações são realizadas com a execução do conversor:
   • Com a alteação do tamanho do campo Identificador de Cálculo (RV_CODFOL) foi realizado a inclusão do zero (0) à esquerda.
   • Para a versão 12 foi criado o campo de INSS Férias (RV_INSSFER) e deveria ser conferido se está de acordo com as necessidades do cliente.
   • Gravação do campo Verba Mês Seguinte (RV_CODMSEG) e que deve ser conferido. Este campo é de extrema importância para o fechamento da folha de pagamento e sua incorreta configuração poderá gerar problemas de cálculos e perdas financeiras. Exemplos utilizados para este campo são as verbas de Férias do Mês seguinte e Insuficiência de Saldo.
   • Para as novas verbas de Adicionais é gravado o campo de verba p. Dissidio (RV_CODCOM_) devido a quebra das verbas de adicionais.
   • Campo para informar a Verba de Diferença de Férias no cálculo da Folha – Se não estiver preenchido o sistema não calcula. Na versão 11 o calculo esta definido dentro do fonte e para flexibilizar a configuração de acordo com a necessidades dos clientes foi disponibilizado este novo ampocampo.Por exemplo, o cliente poderá configurar a diferença de adicionais em verbas especificas.
     
     
10. Cadastro de Sindicato: Diversas configurações que na Versão 11 estavam definidas em parâmetros foram transferidas para campos criados na tabela de Sindicato (RCE). As principais alterações estão vinculadas ao cálculo de Adicionais por tempo de serviço, Periculosidade e Insalubridade. Estas configurações devem ser revistas e discutidas com o cliente se realmente estão de acordo com suas necessidades.
    
    
11. Cadastro Manutenção de Tabelas: A opção da versão 11 de Parâmetros (SX5) foi descontinuada na versão 12 e suas configurações parametrizações foram transferidas para a Manutenção de tabelas. Conforme citado anteriormente a estrutura utilizada para esta transferência de informações foi o Release 11.80 e deverá ser conferido que todos os parâmetros foram transferidos corretamente.
    
    
12. Cadastro do tipo de ausências: Na versão 11 os afastamentos eram controlados através de códigos pré-definidos pela TOTVS e configurações através de parâmetros (SX6), limitando assim a possibilidade de um controle maior pelos clientes. Para melhorar esta funcionalidade foi criado a tabela de tipos de ausências (RCM), no qual já realiza a carga inicial com todos os tipos de ausências que o produto já tratava na versão 11. O conversor realiza os ajustes dos parâmetros (SX6) que foram desativados na versão 12 para os cadastros. Necessário a revisão destas configurações junto ao cliente para garantia dos cálculos. Os parâmetros substituídos por esse cadastro são:
    
    1. MV_MCOMISS: Campo RCM_MESMED – Define o número de meses para comissionado.
    2. MV_ABATAFA: Campos RCM_DECIMO e RCM_PROV13 – Abatimento para cálculo de 13º. Salário
    3. MV_PFCALAC: Campo RCM_PROVFE - Provisões de funcionários afastados por Acidente de Trabalho
    4. MV_PFCALAD: Campo RCM_PROVFE - Provisões de funcionários afastados por Auxilio Doença
    5. MV_TAFAFER: Campo RCM_PROVFE - Tipos de afastamento que serão avaliados para a possível troca de período aquisitivo.
    6. MV_PDCALAC: Campo RCM_PROV13  - Abater avos de afastamento funcionários que se afastaram por  Ac.Trabalho  no Ano
    7.                MV_PDCALAD: Campo RCM_PROV13  -  Abater avos de afastamento funcionários que se afastaram por  Aux.Doença no Ano 
    8. MV_PDCADOC: Campo RCM_PROV13  -  Abate avos por afastamento de Adoção
       
       
13. Lançamento de Ausências/Afastamentos (SR8): Os ajustes realizados na tabela de ausências estão vinculados aos novos campos de controle dos dias de pagamentos (empresa, saldo, dias pagos, etc.)
    Validar as informações dos seguintes campos:
    1. Tipo do Afastamento (R8_TIPOAFA): Verificar se as configurações dos tipos de afastamentos estão de acordo com as regras do cliente.
    2. Verba de Cálculo (R8_PD): Verificar se as verbas geradas para os afastamentos estão de acordo com as definidas pelo cliente.
    3. Dias Empresa (R8_DIASEMP): O número de dias pagos pela empresa passaram a ser controlados diretamente no lançamento do registro e de acordo com as configurações do Tipo de Ausências. Na versão 11 está informação era tratada internamente no fonte e por parâmetros.
    4. Dias de Afastamento (R8_DURACAO): Conferir se o número de dias estão corretos de acordo com a data inicio e fim do afastamento – Para data fim em branco será considerado 999 dias.
    5. Saldo Dias (R8_DPAGAR): Número de dias que ainda restam para a empresa pagar.
    6. Saldo de Dias (R8_SDPAGAR): Saldo de dias a serem pagos pela empresa.
    7. Dias Pagos (R8_DPAGOS): Quantos dias já foram pagos pela empresa.
    8. Sequencia de Afastamento (R8_CONTAFA): Analisar se as sequencias de afastamentos estão de acordo com a migração.
       
       
14. Benefícios: Foi disponibilizado na Versão 12 um novo controle e configuração de benefícios – chamado de Outros Benefícios, e as configurações existentes no cadastro de funcionários da versão 11 foram transferidos para esta nova funcionalidade. As validações necessárias neste contexto são:
    
    1. Transferência dos benefícios do cadastro de funcionários para o novo controle de benefícios – Vale Cultura, Cesta Básica, Seguro de Vida
    2. Ajuste das tabelas de Vale Transporte, Vale Alimentação e Refeição
       
       
15. Importação de Variáveis: A configuração de importação na versão 11 era realizada através da configuração de parâmetros e o mesmo foi transferido para uma nova funcionalidade disponibilizada no menu. Para os clientes que utilizam esta funcionalidade deverá ser validada se a conversão foi realizada corretamente.
    
    
16. Fórmulas e roteiros de cálculo: Para os clientes que possuem fórmulas ou roteiros customizados, o GPECONV fará os ajustes para adequação ao novo motor de cálculo. Realizar os cálculos e a conferência para garantir que não houveram impactos nas conversões.
    
    
17. Cálculos e lançamentos (SRC/RGB): Na versão 12 as tabelas de lançamentos e de cálculo foram segregadas. Desta forma, para adequação a esta nova estrutura, o conversor faz a transição das tabelas considerando
    
    1. Transferência dos lançamentos da tabela de resultado de cálculo (SRC) para a tabela de lançamentos (RGB) com os tipos de movimentos iguais a: I,V,F,G,E.
    2. Se a opção de parametrizações estiver marcado para Excluir Movimentos, serão excluídos todas as informações da tabela de resultado de cálculo (SRC).
    3. Se a opção estiver desmarcada, será atualizado os campos de Processo, Período, Número de Pagamento e Roteiro de Cálculo.
       
       
18. Histórico de movimentos (SRD): Trata-se da maior tabela do sistema e o conversor realiza os ajustes nos seguintes campos:
    
    1. Processo (de acordo com a Categoria)
    2. Período (através do campo RD_DATARQ)
    3. Roteiro
    4. Número de Pagamento (Semana)
    A conversão ainda realiza os ajustes para os seguintes cálculos e que necessitam ser validados:
    1. Adiantamentos: São gerados informações na tabela de históricos para as informações de Adiantamentos com o roteiro de Cálculo (ADI).
    2. 2ª. Parcela 13º. Salário: Geração das informações da 2ª. Parcela do 13º. Salário através do roteiro de cálculo (132).