Histórico da Página

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

Possibilitar a geração do evento S-2299– Desligamento a partir da rotina de Rescisão e Transferências, conforme leiaute 2.1 2 do eSocial. 

Definição da Regra de Negócio

A cada demissão (a partir da rescisão GPEM040 ou GPEM630) que ocorrer (encerramento definitivo do vínculo trabalhista) deve ser gerado o registro S-2299.

Incluindo as demissões geradas a partir da rescisão em lote.

Regra para aceitar o registroRegra:

1 - O funcionário deve ter o registro S-2100 ou S-2200 integrado sem erros no RET:

Se

o registro

2200 ou 2100 estiver em trânsito (sendo transmitido ao ret) será apresentada a mensagem:

"Registro de Admissão do Funcionário está em trânsito TAF x RET. Verifique no sistema TAF. A rescisão não será efetivada."                                                                                                                                                                                                                                                                                                                                                                                        

Se o registro tiver o status de não enviado, ou retornou com erro do RET:

"Registro de Admissão do Funcionário ainda não foi transmitido ao RET ou consta inconsistências.. Verifique no sistema TAF. A rescisão não será efetivada."                                                                                                                                                 

A Rescisão não será efetivada, pois isso pode acarretar em erros no ambiente RETNão será possível efetivar rescisão  no SIGAGPE e no TAF pois o registro de Admissão ou Carga Inicial deste funcionário não integrado com o TAF. Caso o parâmetro MV_RHTAF tenha sido habilitado é necessário como primeiro procedimento realizar a CARGA INICIAL. Se o Carga Inicial foi realizada ou este funcionário foi admitido após a Carga Inicial é necessário verificar o Cadastro do funcionário pois alguma informação obrigatória não foi preenchida impedindo a integração com o TAF"   -Não efetivar a rescisão

2 -  Para Aviso Prévio Trabalhado  ou término de contrato - enviar o evento até o 1º dia útil seguinte a data de desligamento 

Testar o motivo de desligamento, no parâmetro 32 é possível verificar se é termino de contrato (tipo 06 do eSocial) e tipo de Aviso "T"

Se não for o dia seguinte ao da demissão apresentar a mensagem: "O prazo de envio deste evento foi ultrapassado. Passivel Passível de multa", 

Logo após continuar o processamento

3 - Para os demais casos , Data de Desligamento não ultrapassar 10 dias, apresentar a mensagem: 

"O prazo de envio deste evento foi ultrapassado. Passivel Passível de multa", 

Logo após continuar o processamento

4- Se tipo de desligamento 18,19,20,21,22,23,24,25  E Categoria do eSocial < 301 ou > 309:  Mensagem: Motivos de desligamento válidos apenas para Agentes Públicos

5-Numero da Certidão de óbito: Deve ser preenchido se motivo de desligamento 09 ou 10

Rotinas a serem alteradas

Definições Técnicas

RHUPDMOD/RHUPDGPE

1 – Criar um novo item no compatibilizador, este item só será visível para o usuário caso o MV_EFD esteja igual a .T.

Este MV_EFD é criado somente nos casos de SQA e empresas piloto através do APSDU, isso impede que o compatibilizador fique visivel a todos os usuários caso o RHUPDGPE seja liberado devido a outra alteração qualquer.

Esse controle já foi feito uma vez, veja a  alteração no TFS (rhupdgpe nas datas 11/03/2014 a 12/03/2014 – analista Alessandro)

O compatibilizador criará 3 campos:

• MV_INTTAF: Verificar com a equipe do TAF em qual compatibilizador existe a criação deste parâmetro e  copiar para nosso compatibilizador
• MV_RHTAF: Criar parâmetro tipo Lógico, com default .F. e a descrição: Integra dados do –eSocial  automaticamente com o TAF
• SRG_DTPRAP: Data de projeção do Aviso Prévio, tipo Data e apenas Visual.

GPEM040 – Rescisão

Na tela de rescisão, incluir o campo SRG_DTPRAP - Data Projetada para termino de aviso

Este campo será gatilhado quando o tipo de aviso prévio for Indenizado, com o conteúdo: Data de Aviso Prévio + quantidade de dias de aviso + 1

Atenção: Verificar a existência do campo SRG_DTPRAP – Porque o fonte vai subir para todos os usuários, mesmo os que não tem o compatibilizadorm então temos que nos certificar que não ocorrerá error log.

1 - Dicionário

Trazer a tabela RAW/RAZ para a versão 12, incluindo os campos:

Campo codCateg, que indica a categoria que o funcionário trabalha em outra empresa

Tipo de Movimento: (vide o campo indMV do leiaute 2299)

Processo (vide tabela RGB)

Período (vide tabela RGB)

Semana (vide tabela RGB)

Roteiro (vide tabela RGB)

Na Tabela SRG

Criar o campo: (aguarda retorno Renata E): Cumprimento Parcial Aviso Prévio

2 - Fontes

GPEM040 – Rescisão

Habilitar o tratamento  da variável lIntTaf, porém testando agora o parâmetro MV_RHTAF.

Solicitar em tela o campo  Cumprimento Parcial Aviso Prévio

Habilitar no fonte GPEA090 a chamada de Múltiplos vínculos, onde o usuário poderá alimentar a tabela RAZ

No momento da gravação da rescisão devemos controlar a existência da função IntDeslig e se o lIntTaf está como .t.

Não levar as verbas cujo o campo "Incide IRRF" seja igual a 31,32,33,34,35,51,52,53,54,55,81,82 e 83

Controle das verbas:

Antes de Gerar a estrutura, deve-se alimentar um array com as verbas, organizando por Centro de Custo.

A cada quebra de Centro de Custo gerar nova Tag ideEstabLot

Todas as verbas com o mesmo código devem ser agrupadaagrupadas, utilizar um array auxiliar para isso.

Feito isso, ler o array e a cada verba encontrada, verificar na tabela SRV se existe código de rubrica para a verba. As que não tiverem código de rubrica devem ser levadas para um log.

Se existir alguma verba sem código de rubrica:

Apresentar a mensagem: As verbas  999, 999. 999 estão sem código de rubrica cadastrada (rvRV_codrubr)NATUREZ. Não será possível integração com o TAF e a efetivação da rescisão”

Apresentar todas as verbas com inconsistência de uma vez, e não uma a uma. Todas as verbas que estiverem no corpo da rescisão têm que ter código de rubrica equivalente.

Plano de Saúde

Se encontrar a verba com natureza de rubrica 9219, significa que o funcionário tem plano de saúde. Nesse caso faremos o controle:

Alimentar o array, lendo na tabela RHR os dados integrados, a partir do código da verba e se estiver como INTEGRADO

Se encontrar:

Alimentar um array com:

Filial + Matricula + Codigo do fornecedor + verba + dependente + valor

Onde:  Código do fornecedor: ler na tabela RHR CODFOR/ Dependente: RHR_CODIGO / 

         Ler o array e alimentar os dados da estrutura infosaudecolet, cada vez que o campo Codigo do Fornecedor for alterado

GPEM630 - RESCISÃO EM LOTE

Para a rescisão em lote o controle será o mesmo, ou seja deve ser gerado um registro a cada rescisão calculada se o fgetstat estiver igual a 1.

Porém os dados de atestado de óbito, processo, etc, nunca serão preenchidos nesta rescisão porque neste caso o usuário deve utilizar o programa normal de rescisão de contrato.

As consistencias do item regra devem ser obedecidas e também sobre as verbas terem ou não código de rubrica.

Porém no programa de rescisão em lote existe um log que é impresso ao final do processamento, neste log colocar as mensagens de inconsistencias

Somente deverá ser gerado o registro para o TAF se for o tipo de rescisão efetiva, para o tipo Simulação não gerar o registro para o TAF

GPEA010

Se MV_RHTAF = .t.

Caso a alteração no Cadastro de Funcionários seja nos campos Data de Desligamento e Situação, onde o conteúdo novo for “D” informar ao usuário:

“Integração de dados com o eSocial está habilitada, é necessário utilizar a rotina de Rescisão de Contrato para que o registro S-2299 seja transmitido ao TAF”

Não efetivar a alteração.

 FUNÇÃO IntDeslig

Nesta função inserir os dados no XML no novo formato, conforme a seguir

mtvDeslig = Ler no parâmetro 32 o tipo de rescisão do eSocial, esta funcionalidade já foi feita através da função 
substr(fDesc("SRX","32"+cTipR+"2","RX_TXT",,SRA->RA_FILIAL),1,1)
Aqui deve ser lido um código, que corresponde ao código do eSocial.

DtDeslig = RG_DATADEM

indPagtoApi =          Se cAvPrev = “I” então “S” else “N”

dtProjFimAPI = SRG_DTPRAP

percAliment = Verificar o controle feito na impressão do termo de rescisão do campo RQ_IMPCTRE

nrCertObito: RG_OBITO

nrProcTrab = RG_NPROC

observação = RG_OBS

Para gerar as verbas, inicialmente deve acumular todas as verbas com códigos iguais.

ideRecPgto = “R”+ código do funcionário (RA_MAT)

vlrPagto = Verba com ID 126

Tipo de Inscrição,, Numero de Inscrição e Código de Lotação:  Efetuar mesmo controle que está no fonte GPEM026A, função fIntAdmiss

Entrar no loop e gravar quantas verbas existirem no SRR:

CodRubr = SRR_PD

ideTabRubr = verificar no fonte GPEM023A como é feito a gravação desta informação. Trata-se da tabela de rubricas múltiplas ou não

qtdRubri = RR_HORAS

vrRubr = RR_VALOR

GrauExp = Campo do Cadastro de Funcionários, aba funcionais, o campo chama-se Ocorrência

IndSimples = Informação do Parâmetro 14, só indicar aqui alguma coisa se a empresa for optante pelo SIMPLES, esta informação também está no parâmetro 14

ASO

Os dados do ASO são lidos do módulo MDT

Utilizar a função fGM26ASO(cFil, cMat)

Porém ao invés de ler o exame admissional, é necessário ler o exame demissional.

Controle para pensão alimentícia

For nI := 1 To Len(aCols) 

If (PosSrv(aCols[nI, nPosPd],SRA->RA_FILIAL,"RV_CODFOL")) $ "0126"

nValor := aCols[nI, nPosValor]

EndIf
if alltrim(PosSrv(aCols[nI, nPosPd],SRA->RA_FILIAL,"RV_DIRF")) $ "8/C/C1/C2/C3"

nPensao += aCols[nI, nPosValor]

EndIf

Next nI

if nPerPens <>0 .and. nPensao <>0
cXml += '<pensAlim>3</pensAlim>'
elseif nPerPens == 0 .and. nPensao == 0
cXml += '<pensAlim>0</pensAlim>'
elseif nPerPens <> 0 .and. nPensao == 0
cXml += '<pensAlim>1</pensAlim>'
elseif nPerPens == 0 .and. nPensao <> 0
cXml += '<pensAlim>2</pensAlim>'
Endif

Múltiplos Vínculos

Utilizar a tabela RAZ para a leitura, cujo o período seja o mesmo informado na demissãoObservar a tabela TMK, campo TMY_NATEXA para saber a natureza do exame

Tabelas Utilizadas

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.

• SRG – Cabeçalho da rescisão
• SRR – Itens.
• SRA - Cadastro de Funcionários
• Parametro 14
• Parametro 32

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

 Image Removed

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

• RAZ