Histórico da Página

...

Deck of Cards

id	Conversão_GPECONV

Deck of Cards

id	Conversão

Card

id	Conversão_Conv
label	Conversão Versão 11 para Versão 12

Deck of Cards

id	Descritivo

Card

id	Objetivo
label	Upgrade de Versão

A versão 12 da Folha de Pagamento Microsiga Protheus® trouxeram diversas novidades ao mercado brasileiro, inclusive com mudanças estruturais e que necessitam de adequações no upgrade da versão 11. Esta rotina deverá ser executada após o upgrade da versão.

Card

id	Planning
label	Planejamento e Checklist

Deck of Cards

id	Planning

Card

id	Obj_Planning
label	Objetivo

O objetivo é direcionar e definir um checklist de Upgrade para a versão 12 da Folha de Pagamento Protheus advindo de releases/versões anteriores. Importante lembrar que poderão existir novas situações não mapeadas neste documento e poderão impactar em alguns clientes com cenários diferentes ao citado.

Card

id	Plan_Upgrade
label	Upgrade Versão 12

1. Upgrade Protheus

Antes dos procedimentos específicos da Folha de Pagamento faz-se necessário a realização do upgrade da versão 11, utilizando-se dos direcionamentos definidos pelo Framework

Para maiores detalhes consulte o link:

http://tdn.totvs.com/pages/viewpage.action?pageId=271659404

2. Upgrade Folha de Pagamento

Após o upgrade descrito no tópico acima, faz-se necessário a conversão de dados para adaptação à nova estrutura da folha de pagamento, porém é importante um planejamento e um revisão de dados para o correto funcionamento do produto.

Card

id	Planejamento
label	Planejamento

Deck of Cards

id	Planejamento

Card

id	Descricao_Planning
label	Descritivo

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.

Card

id	Checklist_Pre
label	Checklist antes da Conversão

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:

Definir se a conversão inicialmente ocorrerá para todas as filiais ou para apenas uma parte considerando a validação das conversões.
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.)
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).
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.
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.

Realizar o backup das tabelas do RH para eventuais necessidades de novas execuções do GPECONV - evitar assim novos Upgrades de todo o ERP.
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.
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
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.
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.

Card

id	Checklist_Pos
label	Checklist depois da Conversão

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:

Cadastro de funcionários: Verificar se os campos foram preenchidos e seguindo as regras definidas para a conversão:
1. RA_PROCES:
  1. RA_CATFUNC = 'A' ou 'P' e 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’
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
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
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.
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.
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 campo.Por exemplo, o cliente poderá configurar a diferença de adicionais em verbas especificas.
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.
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.
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
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.
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
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.
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.
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.
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).

Card

id	Tools
label	Ferramenta Conversão (GPECONV)

Table Filter

id	1545234215862_1918011569

GPECONV - Manual de Conversão Gestão de Pessoal Versão 12.

1 - Pré-requisito: Já ter efetuado o procedimento de conversão da base 11 para 12, conforme a faq: Migração de Versão - Para Protheus 12

2 - Para converter os programas da área de Recursos Humanos, é necessário rodar o GPECONV, conforme abaixo:

Obs: Abaixo iremos demonstrar o processo item por item porém pode ser feito marcando todos de uma unica vez ficando a critério do usuário.

Caso tenha um volume muito grande de dados, sugerimos executar primeiramente os ítens da primeira tela conforme print abaixo e depois

os movimentos da segunta tela isoladamente, ou seja, um por vez.

Obs 2: Só faça o processamento da segunda tela ( SRC, SRD etc ) depois que todos itens da primeira tela estiverem sido aplicados.

3 - Inverter seleção:

Marca e desmarca todas as opções:

4 - Assistente para criação de novas verbas (SRV)

Devido às mudanças de conceitos, as verbas foram desmembradas:

Grid com todas as verbas obrigatórias no novo modelo e que não existem na base, indicando um modelo (verba espelho) para criação dos novos identificadores:

Conferir se todas as verbas do grid acima foram criadas no cadastro de verbas (SRV):

Exemplo verba com ID 0678 (GPEA040- Atualizações/Definições de Cálculo/Verbas):

5 - Cadastro de Verbas (SRV)

Conferir se as modificações foram efetuadas:

i. Inclusão do zero (0) à esquerda devido alteração do tamanho (Ajuste do campo RV_CODFOL para 4 dígitos, conforme definição do novo modelo da Folha de Pagamento)

GPEA040- Atualizações/Definições de Cálculo/Verbas

ii. Carga dos campos novos com os inicializadores padrões.

Criação dos novos ID’s de cálculo utilizados no cálculo dos adicionais e férias (será aberta janela para definição das novas verbas, caso não existam, no momento que acessar a rotina de Cadastro de verbas - GPEA040).

Os seguintes IDs foram liberados para associação às verbas ref. à Adicionais no cálculo de Férias:

Os seguintes IDs foram liberados para associação às verbas ref. à Adicionais no cálculo de Décimo Terceiro Salário:

Exemplo de ID criado (GPEA040- Atualizações/Definições de Cálculo/Verbas)::

iii. Mudança do conteúdo do campo RV_INSSFER de S/N para ½ (GPEA040- Atualizações/Definições de Cálculo/Verbas):

iv. Preenchimento do campo Código mês Seguinte (RV_CODMSEG) – até V11 tratado nos fontes (GPEA040- Atualizações/Definições de Cálculo/Verbas):

v. Preenchimento do campo Férias mês seguinte com a verba de diferença de férias (SRV->RV_FERSEG) – até V11 tratado nos fontes. (GPEA040- Atualizações/Definições de Cálculo/Verbas):

vi. Troca dos identificadores de cálculo das verbas de dissídio devido ao novo conceito de adicionais desmembrados

6 - Tipos de Ausência (RCM)

Cria os tipos de ausência mais usados nos afastamentos.

GPEA430 - Atualizações/Definições de Cálculo/Tipos de Ausências - Verificar se carregou corretamente os tipos de ausências (RCM):

i. Com o novo modelo dos tipos de ausência vinculado a um cadastro, o sistema realiza a configuração dos itens utilizados até a versão 11 neste cadastro.
ii. Transferência da parametrização de cálculo dos afastamentos da versão 11 que eram realizada via parâmetros SX6 para o Cadastro de Tipos de Ausências (RCM) - MV_MCOMISS, MV_ABATAFA, MV_PFCALAC, MV_PFCALAD, MV_TAFAFER, MV_PDCALAC, MV_PDCALAC, MV_PDCADOC.

7 - Cadastro de Sindicatos (RCE)

i. Transferência de informações do cadastro de parâmetros - 'Adicional Tempo Serviço' (SRX - Versão 11) para a Aba ‘Adic. Tempo Serv.’ do cadastro de Sindicatos

(RCE - Versão 12) - (GPEA340 - Atualizações/ Cadastros/ Sindicatos):

ii. Transferência da configuração de Insalubridade, Periculosidade do cadastro de funcionários (SRA - Versão 11) para sindicatos a Aba 'Peric./Insal.' do cadastro de Sindicatos

(RCE - Versão 12) - (GPEA340 - Atualizações/ Cadastros/ Sindicatos):

8 - Cadastro de Funcionários (SRA)

Converte todos os funcionários da base, adicionando o novo campo chave para cálculo PROCESSO (RA_PROCES) baseado na categoria e tipo de pagamento dos funcionários.

Atualização dos campos: Horas dia (RA_HRSDIA), Adicional de Insalubridade (Mínimo, Médio e Máximo), Insalubridade Máxima (RA_INSMAX) e Adicional Periculosidade.

Regra de Preenchimento:
Categoria Horista e o tipo de pagamento Semanal – processo Semanalista ( código 00002).
Categoria Semanalista e o tipo de pagamento Semanal – processo Semanalista ( código 00002).
Categoria Autônomo e o tipo de pagamento Mensal – Autônomo Mensalista ( código 00003).
Categoria Autônomo e o tipo de pagamento Semanal – Autônomo Semanalista ( código 00003).

Observação: Qualquer outra combinação de categoria com o tipo de pagamento será considerada Mensalista (código 00001).

GPEA010 - Atualizações/ Funcionários/ Funcionários - Verificar se carregou as informações dos funcionários corretamente:

9 - Cadastro de Períodos (RCJ, RFQ, RCH, RCF, RCG)

Geração dos períodos através das competências dos históricos de movimentos da Versão 11.
    Atualização das tabelas RCF e RCG e geração das novas tabelas de Períodos RFQ e RCH através das informações das tabelas de:
    i. Histórico de Movimentos (SRD)
    ii. Cálculo de Férias e Rescisão (SRH)
    iii. Afastamentos (SR8)
    iii. 2ª. Parcela do 13º. Salário (SRI)

GPEA400 - Atualizações/ Definições de Cálculo/ Períodos - Verificar se os períodos foram criados corretamente:

10 - Cadastro de Ausências (SR8)

Ajuste nos dados do cadastro de ausências para o novo modelo.

GPEA011 - Atualizações/ Funcionários/ Gestão Funcionários/ Funcionários/ Ausências/ Manutenção

Verificar se o sistema preencheu corretamente os campos abaixo em destaque amarelo:

11 - Movimento 2ª Parc. 13º Sal.

Transferência dos movimentos em aberto da tabela de 2ª. Parcela do 13º. Salário (SRI Versão 11) para a tabela de movimentos (SRC versão 12) com o roteiro de cálculo da 2ª. Parcela (Roteiro 132).

GPEA100 - Consultas /Cálculos / Por Verba - Consultar a verba de 13º Salário e verificar se os dados da tabela SRI foram replicados para a tabela SRC e se os campos referentes ao Processo e Roteiro foram corretamente preenchidos.

12 - Manutenção de Tabelas (RCC e RCB)

Conversão dos dados cadastrados nos parâmetros (SRX) para Manutenção de Tabelas (RCB e RCC). Os seguintes dados serão atualizados:

GPEA320 - Atualizações/ Definições de Cálculo/ Manutenção de Tabelas - Verificar se os itens acima foram criados corretamente pelo sistema.

GPEA320 - Atualizações/ Definições de Cálculo/ Manutenção de Tabelas - Verificar se os valores de cada tabela acima também foram trazidos corretamente da versão 11.

O exemplo abaixo mostra que trouxe corretamente os valores da tabela de INSS que estavam na versão 11.

13 - Valores Futuros (SRK)

Atualização dos campos de Processo, Período Inicial, Status e Número de pagamento

GPEA110 - Atualizações/ Lançamentos Futuros - Verificar se os campos novos abaixo em destaque amarelo foram carregados corretamente pelo sistema:

14 - Transferências

GPEA180 - Atualizações/ Funcionários/ Transferências - Verificar se os campos "Processo De" e "Processo Para" foram preenchidos corretamente:

15 - Outros Benefícios

Transferência dos benefícios do cadastro de funcionários para o novo controle de benefícios

16 - Bloqueio de Períodos (RG3)

GPEA710 - Atualizações/ Definições de Cálculo/ Períodos, então ir em Outras Ações / Bloq. por Períodos - Verificar se o sistema atualizou corretamente o campo de Roteiro no controle de bloqueio de período:

17 - Fórmulas (SRM, SRY, RC2, RC3, RC5, RC4)

Os nomes das fórmulas serão alterados e ao fim do processo será exibido um log com as alterações. As fórmulas deverão ser revistas após a conversão, principalmente quanto ao uso de RDMAKES.

O Sistema disponibiliza fórmulas padrões preparadas para atender aos cálculos específicos agrupados nos Roteiros de Cálculo. As fórmulas geradas pelo sistema são apenas para visualização.

GPEA290 - Atualizações/ Definições de Cálculo/ Fórmulas - Verificar se as fórmulas e roteiros de usuários foram convertidas para o novo modelo do formulador:

GPEA160 - Atualizações/ Definições de Cálculo/ Roteiros - O Sistema disponibiliza roteiros padrões preparados para atender aos cálculos da legislação vigente ou que servirão como apoio durante cálculos específicos. Conforme abaixo:

18 - Mnemonicos (RCA)

Faz a conversão dos mnemônicos de usuário para o novo modelo. Os nomes dos mnemônicos serão alterados e ao fim do processo será gerado um log informando as alterações.

Atualização da nomenclatura dos mnemônicos considerados como parâmetros com início de P_ para diferenciação de configuração e controle de alterações.
São eles: M_PERCAUTO, CAVPROPPDEM, NANOAVIPRO, CCAVISTRA, CCODPGIND, CDESCMEDAV, CLIMAUXE15, LMESATU, NDRECALS, NTOTDIAS, CPAGINDFD, CPAGRECES, NPERBCIR1, NPERBCIR2, LPGSALFEV, CPIDEM1SM, CPIDEM2SM, LPROPCOMS, LPROPCONTR, NSESTSENAT, LSOMAINC, CTRANSPAD, CTRANSPAP, NVLLIMDIRF, NVLLIMOUT

Observação: Mnemônicos que iniciam com M_ passaram a ter a nomenclatura de P_.

GPEA300 - Atualizações/ Definições de Cálculo/ Mnemonicos - Verificar se as alterações foram efetuadas conforme o log de mensagem acima:

19 - Importação de Variáveis (RGB, RHO, SRK)

Transferir as configurações da tabela de Parâmetros para o novo modelo de configuração (Menu Layout de Importação)

Converte o Layout de Importação da versão 11 para o Layout de Importação da Versão 12.

Na versão 11, o Layout de Importação era definido no GPEA150- Atualizações/Definições Cálculo/Parâmetros-2 (SRX)

Na versão 12, o Layout de Importação é definido no GPEA200 - Atualizações/Definições Cálculo/Layout de Importação (RGB, RHO, SRK)

GPEA200 - Atualizações/Definições Cálculo/Layout de Importação - Verificar se o modelo de importação da versão 11 foi convertido corretamente para a versão 12:

20 - Movimento Mensal (SRC)

Converte os dados da tabela do movimento mensal para o novo modelo e envia os lançamentos manuais para a tabela RGB. Conforme as opções abaixo:

Opção 1 - Marcar as opções "Excluir Lançamentos?" e "Enviar Lançamentos para a RGB":

Esta é a opção padrão.

Ao setar "Excluir Lançamentos?", serão excluídos TODOS os dados da tabela SRC.

Ao setar "Enviar Lançamentos para a RGB" os lançamentos manuais da SRC (RC_TIPO2 = "I" - "Informado") serão levados para a tabela RGB.

Importante: Ao escolher esta opção, será necessário reprocessar a folha na versão 12 para recarregar o movimento mensal. Somente os lançamentos manuais serão mantidos na RGB.

GPEA590 - Atualizações/ Lançamentos/ Por Verba (RGB) - Verificar se os lançamentos manuais foram enviados corretamente para a tela abaixo:

Opção 2 - Desmarcar as opções "Excluir Lançamentos?" e "Enviar Lançamentos para a RGB".

Caso o cliente tenha convertido da V11 para V12 com a folha calculada e apenas restando o fechamento as opções deverão ser desmarcadas.

Ao desmarcar "Excluir Lançamentos?", os dados da tabela SRC serão mantidos e convertidos para o novo modelo.

Ao desmarcar "Enviar Lançamentos para a RGB" os lançamentos manuais da SRC (RC_TIPO2 = "I" - "Informado") não serão levados para a tabela RGB, serão mantidos na SRC.

GPEA100 - Consultas/ Cálculos/ Por Verba (SRC) - Verificar se os dados do movimento mensal foram convertidos corretamente para o novo modelo, preenchendo corretamente os campos em destaque amarelo abaixo, Processo e Roteiro.

21 - Histórico de Movimentos (SRD)

Este ítem faz a conversão da tabela SRD (Historico de acumulados), incluindo os campos chave como processo, período, roteiro e número de pagamento. Caso os campos de período De/Até estiverem em branco sistema irá converter todo o perido dos acumulados.

Atualização dos seguintes campos de acordo com o Cadastro de períodos (RCH):

i. Processo (de acordo com a Categoria) - RD_PROCES

ii. Período (através do campo RD_DATARQ) - RD_PERIODO

iii. Roteiro - RD_ROTEIR

iv. Número de Pagamento (Semana) - RD_SEMANA

IMPORTANTE: Para problemas de performance, verificar se está atualizado conforme a faq: 571958 MRH-8658 DT Melhoria performance conversao historico movimento, e executar periodos de um a dois anos por vez.

GPEA120 - Consultas\ Cadastros \ Acumulados - Verificar se os campos foram atualizados corretamente conforme destaques em amarelo abaixo:

22 - Férias (SRH e SRR)

i. Ajustar o valor dos campos de Processo (RH_PROCES e RR_PROCES), Roteiro (RH_ROTEIR e RR_ROTEIRO), Período (RH_PERIODO e RR_PERIODO) e Número de Pagamento (RH_NPAGTO e RR_SEMANA ) no cabeçalho de Férias e nos itens de Férias e Rescisão.

iii. As Férias calculadas no período mensal da base de dados não serão convertidas através do GPECONV, estas férias deverão ser recalculadas dentro da Versão 12 de forma a garantir a conversão e geração de dados dentro dos padrões da nova versão.

GPEM030 - Miscelanea/ Cálculos/ Férias - Verificar se os campos referente a Processo, Roteiro e Período foram atualizados corretamente conforme abaixo:

Observação: Visando evitar erros no calculo da folha, devido a mudança de conceito existente na P12. Sempre exclui o movimento aberto, não existe mais opção.

Somente as férias de meses que já estão no acumulado serão convertidas para o novo modelo, para isso o sistema compara o valor do parâmetro MV_FOLMES.

23 - Rescisão (SRR e SRG)

i. Ajustar o valor dos campos de Processo (RG_PROCES e RR_PROCES), Período (RG_PERIODO e RR_PERIODO), Roteiro (RG_ROTEIR e RR_ROTEIR) e Número de Pagamento (RG_SEMANA e RR_SEMANA) no cabeçalho de Rescisão e nos itens de férias e rescisão.

ii. Exclusão dos cálculos de movimentos em aberto, conforme definição na tela de Parametrizações.

GPEM040 - Miscelanea/ Cálculos/ Rescisão - Verificar se os itens em destaque amarelo foram atualizados corretamente pelo GPECONV

24 - Controle de Dias de Direito (SRF e SRH)

Ajuste no período em aberto na tabela SRF e geração do histórico dos períodos aquisitivos de férias através da tabela de cálculo (SRH).
Observação: É possível inibir a conversão dos períodos de férias de funcionários demitidos.

GPEA050 - Atualizações/ Funcionários/ Controle de Dias de Direito - Verificar se o sistema carregou corretamente o controle de dias de direito dos funcionários:

25 - Selecionar Filiais para Processamento

Apresenta tela para seleção de 1 filial. Para as primeiras conversões sugere-se que faça uma filial pequena e depois as demais.

Obs: Antes de marcar as Empresas\Filiais certifique-se que realmente existe movimento para o SIGAGPE, caso contrario

deixe desmarcado.

Outros links relacionados ao GPECONV

GPECONV- Ao executar o GPECONV o sistema não atualiza o Menu da P12.

GPECONV- A função AFY811 nao foi encontrada no repositório.

GPECONV - Erro: "Falha na gravação da Verba de Diferença de Férias (RV_FERSEG). As verbas com os seguintes identificadores não foram encontradas.".

GPECONV - Erro: "Falha na gravação da Verba de Diferença de Férias (RV_FERSEG). ID 0891 - Recesso de Estagiario".

GPECONV - Erro: "Os identificadores Abaixo são Obrigatórios e não estão relacionados a uma verba. 1415 1 Parc. 13 Antecipado mesmo mês rescisão".

GPECONV- Na abertura do módulo, a mensagem "A base deve ser convertida para atender a P12. Verificar a documentação referente ao GPECONV disponivel no TDN.

GPECONV- Possíveis erros / F_ULTDIA