O evento S-2200 – Cadastramento Inicial do Vínculo e Admissão registra a admissão de empregado ou o ingresso de servidores estatutários, a partir da implantação do eSocial. Ele serve também para o cadastramento inicial de todos os vínculos ativos pela empresa/órgão público, no início da implantação, com seus dados cadastrais e contratuais atualizados. As informações prestadas nesse evento servem de base para construção do "Registro de Eventos Trabalhistas" - RET, que será utilizado para validação dos eventos de folha de pagamento e demais eventos enviados posteriormente. Trata-se do primeiro evento relativo a um determinado vínculo – excetuada a situação prevista para o evento “S-2190 – Admissão de Trabalhador – Registro Preliminar”, registrando as informações cadastrais e do contrato de trabalho. Deve ser enviado também quando o empregado é transferido de uma empresa do mesmo grupo econômico ou em decorrência de uma sucessão, fusão ou incorporação.
Quem está obrigado: todo empregador/contribuinte/órgão público que mantém vínculos trabalhistas, assim como as empresas de trabalho temporário (Lei nº 6.019/74), que possuam trabalhadores temporários. Os vínculos desligados antes da implantação do eSocial não serão informados nesse evento.
Prazo de envio: deverá ser transmitido antes do envio de qualquer evento periódico ou não periódico relativo ao trabalhador e, ainda, conforme os seguintes prazos:
a) até o dia imediatamente anterior ao do início da prestação dos serviços para os empregados admitidos a partir do dia seguinte ao início da obrigatoriedade de envio dos eventos não periódicos ao eSocial. No caso de admissão por transferência, ou se o declarante fizer a opção de enviar as informações preliminares de admissão por meio do evento S-2190, o prazo de envio do evento S- 2200 é até o dia 15 (quinze) do mês subsequente ao da sua ocorrência, ou antes da transmissão de qualquer outro evento não periódico relativo a esse empregado;
b) até o dia 15 (quinze) do mês subsequente ao da entrada em exercício de servidor estatutário, independentemente do regime previdenciário ao qual ele esteja vinculado, ou antes da transmissão de qualquer outro evento não periódico relativo a esse servidor;
c) para os vínculos iniciados até o dia anterior ao do início da obrigatoriedade dos eventos não periódicos, o prazo é o definido em ato normativo;
d) no dia do início da prestação dos serviços para os empregados admitidos na data do início da obrigatoriedade de envio dos eventos não periódicos ao eSocial
Fonte: MOS Versão S-1.1
Informações Sistêmicas
Os eventos não periódicos não têm uma data pré-fixada para ocorrer, pois dependem de acontecimentos na relação entre o empregador/órgão público e o trabalhador que influenciam no reconhecimento de direitos e no cumprimento de deveres trabalhistas, previdenciários e fiscais como, por exemplo, a admissão/ingresso de um empregado/servidor, a alteração de salário, a exposição do trabalhador a agentes nocivos e o desligamento, dentre outros.
Os eventos não periódicos só serão enviados conforme a configuração do parâmetro MV_FASESOC, MV_RHTAF e MV_EFDMSG, que deve ser:
MV_FASESOC
" " - Default
1 - Não Periódicos (fase não periódicos)
2 - NP + Periódicos (fase não periódicos e periódicos)
MV_RHTAF
.T. (habilita integração de eventos não periódicos com o TAF)
MV_EFDMSG
.T. (apresenta aviso informando que o evento foi enviado para o TAF)
O Evento de S-2200 - Admissão registra a admissão do funcionário na empresa, trata-se do primeiro evento do funcionário, com exceção do evento S-2190, neste evento são levados todos os dados cadastrais e contratuais do funcionário.
Parâmetro MV_DTCGINI:
Quando é realizada a alteração de um trabalhador que não foi processado na Carga Inicial, o sistema irá gerar o evento S-2200 e no arquivo XML desse evento conterá o atributo CADINI, para indicar se as informações do vínculo do trabalhador são Anteriores ou Posteriores à data de início de obrigatoriedade do envio dos eventos não periódicos. Quando o vínculo é anterior, ou seja, o funcionário já estava admitido antes do envio das informações, o atributo será CADINI = S, e quando o vínculo for posterior, o atributo será CADINI = N. Para que esse atributo seja gerado com a informação correta (S ou N) o sistema avalia a data informada no parâmetro MV_DTCGINI, o qual determina a data que a carga inicial foi enviada para o governo e concluída.
1º Exemplo: MV_DTCGINI = 01/03/2018 (Data que iniciou-se envio da 2ª fase do eSocial (NÃO PERIÓDICOS) ao governo para empresas com faturamento > 78 milhões)
- Funcionário 1 admitido em 05/03/2018 => Arquivo XML gerado com atributo CADINI = N (porque a admissão do trabalhador ocorreu após a data informada no parâmetro MV_DTCGINI)
- Funcionário 2 admitido em 01/01/2018 => Arquivo XML gerado com atributo CADINI = S (porque foi realizada carga inicial e a admissão foi realizada anteriormente a data informada no parâmetro MV_DTCGINI)
2º Exemplo: MV_DTCGINI = 01/07/2018 (Data que iniciou-se envio da 2ª fase do eSocial (NÃO PERIÓDICOS) ao governo para empresas com faturamento < 78 milhões)
- Funcionário 1 admitido em 05/07/2018 => Arquivo XML gerado com atributo CADINI = N (porque a admissão do trabalhador ocorreu após a data informada no parâmetro MV_DTCGINI)
- Funcionário 2 admitido em 01/01/2018 => Arquivo XML gerado com atributo CADINI = S (porque foi realizada carga inicial e a admissão foi realizada anteriormente a data informada no parâmetro MV_DTCGINI)
Matrícula eSocial:
- A matrícula a ser enviada ao eSocial é uma junção de dados EMPRESA + FILIAL + MATRICULA + DATA + HORA. Este código de matrícula acompanhará o funcionário durante a vida laborativa na empresa, entende-se empresa, os 8 primeiros digitos do CNPJ do grupo - Matriz + Filiais.
- Sendo assim, se houver uma transferência entre filiais, a matrícula não será alterada.
- Se o funcionário for admitido em duas filiais da mesma empresa, ele terá dois S-2200, porém ao gerar a Folha, será agrupado por CPF.
Condições:
- Somente quando todos os dados obrigatórios estiverem preenchidos o evento é gerado
- O evento de Estabelecimento S-1005 (filial) deve ter sido previamente carregado
- O Evento de Lotação S-1020 deve ter sido previamente carregado
O Evento é disparado nas seguintes operações:
- Cadastro de Funcionários (GPEA010): - Operação INCLUSÃO (caso todos os dados obrigatórios do eSocial estejam preenchidos)
- Cadastro de Funcionários (GPEA010) - Operação ALTERAÇÃO:
- Caso o envio do S-2200 que foi integrado na Inclusão ainda não tenha sido efetuado pelo TAF
- Caso o evento S-2200 esteja no TAF com algum erro - no caso o usuário está corrigindo o que foi integrado incorretamente
- Caso no momento da inclusão o parâmetro MV_FASESOC estiver preenchido para o envio de não periódicos, e no momento da alteração o mesmo foi habilitado
- Cadastro de Dependentes (GPEA020): - Operação INCLUSÃO /ALTERAÇÃO
-
- Caso o envio do S-2200 que foi integrado na Inclusão ainda não tenha sido efetuado pelo TAF;
- Caso o evento S-2200 esteja no TAF com algum erro - no caso o usuário está corrigindo o que foi integrado incorretamente;
- Caso no momento da inclusão o parâmetro MV_FASESOC estiver preenchido para o envio de não periódicos,, e no momento da alteração sim;
- Cadastro de Dados do Temporário (GPEA927): - Operação INCLUSÃO /ALTERAÇÃO
-
- Caso o envio do S-2200 que foi integrado na Inclusão ainda não tenha sido efetuado pelo TAF;
- Caso o evento S-2200 esteja no TAF com algum erro - no caso o usuário está corrigindo o que foi integrado incorretamente;
- Caso no momento da inclusão o parâmetro MV_FASESOC estiver preenchido para o envio de não periódicos,, e no momento da alteração sim;
- Cadastro de Sucessão de Vinculo (GPEA926): - Operação INCLUSÃO /ALTERAÇÃO
-
- Caso o envio do S-2200 que foi integrado na Inclusão ainda não tenha sido efetuado pelo TAF;
- Caso o evento S-2200 esteja no TAF com algum erro - no caso o usuário está corrigindo o que foi integrado incorretamente;
- Caso no momento da inclusão o parâmetro MV_FASESOC estiver preenchido para o envio de não periódicos, e no momento da alteração sim;
- Transferência de Funcionários (GPEA180)
- Caso o evento S-2200 ainda não tenha sido transmitido será gerado outro com a nova filial, e o cadastro da Sucessão de Vínculo (GPEA926 - tabela RFZ) será preenchido conforme os dados da origem da transferência, para o registro destino.
Na ocasião do funcionário possuir afastamento, os dados do afastamento serão informados no evento S-2200.
Obs.: ocorre quando a transferência é entre empresas de CNPJ diferentes.
- Caso o evento S-2200 ainda não tenha sido transmitido será gerado outro com a nova filial, e o cadastro da Sucessão de Vínculo (GPEA926 - tabela RFZ) será preenchido conforme os dados da origem da transferência, para o registro destino.
Retificação do evento S-2200:
A retificação do S-2200 poderá ser feita habilitando o parâmetro MV_RETSOC, e realizando uma alteração no cadastro de funcionário, desde que o status do funcionário no TAF esteja com valor igual a 4. Será exibida a pergunta "Deseja gerar Retificador?", se o usuário responder com Sim, será gerado o evento retificador do S-2200 no TAF, caso contrário, será gerado o evento S-2205 ou S-2206 normalmente.
Exclusão:
A exclusão do evento está disponível através do TAF
CTPS Digital:
Os campos carteira de trabalho e série somente devem ser preenchidos para funcionário que possuem a carteira de trabalho no modelo antigo (carteira física). Para o novo modelo digital, esses campos não necessitam de preenchimento, pois a tag <nrCtps> será gerada com o valor do CPF e a tag <serieCtps> com "00000".
Principais alterações no evento com a simplificação:
- Não serão gerados os seguintes dados : PIS, Nome do Pai, mãe e código de município, grupo Documento e data de opção de FGTS.
- Não serão gerados os códigos de cargo ou função, porém as descrições serão geradas.
- Para gerar informação de horário, buscaremos os dados pela descrição das jornadas do funcionário por dia de semana, sequencia e turno
- Solicitamos que para funcionário estrangeiros seja efetuado o saneamento, pois o campo referente ao tipo de estrangeiro foi alterado, e seus códigos devem ser revistos.
- O preenchimento da tag codTreiCap - "Informar o código do treinamento, capacitação, exercício simulado ou outra anotação, conforme Tabela 28." será realizado através dos cursos informados através do módulo 26 - Treinamentos (SIGATRM) ordenados por data do treinamento decrescente
Para mais detalhes, sobre as informações de treinamento, Acesse: https://centraldeatendimento.totvs.com/hc/pt-br/articles/360050782713-RH-Linha-Protheus-TRM-Gera%C3%A7%C3%A3o-de-um-calend%C3%A1rio-para-treinamento
Abaixo as premissas a serem executadas antes de fazer a geração dos eventos não periódicos:
HOW TO - SIGAGPE - Integrando o evento S-2200
HOW TO - TAF - Transmitindo o evento S-2200
Produto: |
Microsiga Protheus |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ocorrência: |
Como deve ser definido o Compartilhamento de Tabelas SIGAGPE x SIGATAF? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Passo a passo: |
Antes de Iniciar a Carga Inicial, é necessário verificar se o compartilhamento das Tabelas do SIGAGPE x SIGATAF estão compatíveis, isto porque a integração dos dados de Folha com o TAF, utilizada pelo Protheus, é feita dentro do mesmo Banco de Dados, basicamente os registros são lidos das tabelas "origem", que são tabelas do SIGAGPE e gravados nas tabelas "destino" que são tabelas do SIGATAF. Por esta razão os compartilhamentos devem devem ser iguais, para que não haja duplicidade de dados e nem gravação em Filiais incorretas. Por exemplo: A Tabela CTT dá origem a Tabela C99 do TAF, então essas duas tabela devem ter o mesmo tipo de compartilhamento(modo de acesso). Por default todas as tabelas do TAF são criadas de forma totalmente exclusiva, sendo assim, reveja a configuração das tabelas, através do SIGACFG antes de iniciar a Carga Inicial. Abaixo a relação entre Tabelas: IMPORTANTE:
Tabelas que devem ser exclusivas por Empresa:
* A CTT pode ser utilizada como compartilhada caso o cadastro de lotações seja feito através da rotina Controle de Lotações, pois desse modo a informação para o evento S-1020 não vai partir da CTT. Para saber mais acesse: DT Novo Controle de Lotações Relação entre Tabelas GPE e TAF: As tabelas do GPE e TAF devem ter o mesmo compartilhamento (modo de acesso) para que não ocorra erros na integração dos dados, abaixo a relação de tabelas.
Obs:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Observações: |
Esta informação também esta disponível na central de Atendimento através do link: https://centraldeatendimento.totvs.com/hc/pt-br/articles/360004178832 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Abaixo procedimentos do Jobs de Alteração Salarial e Afastamento
Job para os Históricos Salariais
Cada alteração salarial deve gerar um registro S-2206, como a alteração salarial pode ser disparada de diversas rotinas, consideramos mais seguro gerar a partir dos Históricos Salariais, a partir de JOB.
Todas essas ações originam dados em SR3/SR7 - Tabelas de Alterações salariais, e são destas tabelas que o JOB buscará os dados para a geração do registro S-2206
Para configuração, siga os passos do documento:
1 - Preencher o MV_DTCGINI com a Data que indica, a partir de quando as alterações salariais serão consideradas no JOB
Atenção: O MV_DTCGINI representa a data de inicio da entrega dos eventos não periódicos que pode ser diferente para cada grupo de empresas, ou seja, o eventos serão enviados a partir da data informada no parâmetro.
2 - Em SIGACFG\SCHEDULE\CADASTROS realize a inclusão da rotina para o Schedule:
3 - Inclua a função de Agendamento:
4 - Inclua a função e as empresas que a rotina será executada.
5 - Após a confirmação da empresa\filial, é só terminar o preenchimento dos demais campos e configurar a quantidade de acionamento da rotina:
6 - A janela abaixo é apresentada a tela de acionamento:
7 - Configure agora os agentes, que são os responsáveis por executar as funções:
Possibilidades de cadastrar uma alteração salarial:
Job para integração afastamento
Conforme regras de Afastamento definidos pelo eSocial, o inicio e o fim de um afastamento são tratados em momentos distintos, devendo o "FIM" apenas ser enviado ao RET quando de fato ocorrer. Sendo assim foi implantada a integração de afastamento a partir de JOB.
A integração de um "fim" de afastamento, só pode ser enviada ao TAF quando o "inicio" do afastamento ja estiver transmitido e validado pelo RET. Caso contrario, o TAF não aceitará a inclusão do "fim" do afastamento pelo SIGAGPE.
Para configuração, siga os passos do documento:
1 - Preencher o MV_DTCGINI com a Data que indica, a partir de quando os eventos Não Periódicos serão consideradas no JOB
Atenção: O MV_DTCGINI representa a data de inicio da entrega dos eventos não periódicos que pode ser diferente para cada grupo de empresas, ou seja, o eventos serão enviados a partir da data informada no parâmetro.
2 - Em SIGACFG\SCHEDULE\CADASTROS realize a inclusão da rotina para o Schedule:
3 - Inclua a função de Agendamento:
4 - Inclua a função e as empresas que a rotina será executada.
5 - Após a confirmação da empresa\filial, é só terminar o preenchimento dos demais campos e configurar a quantidade de acionamento da rotina:
6 - A janela abaixo é apresentada a tela de acionamento:
7 - Configure agora os agentes, que são os responsáveis por executar as funções:
Abaixo procedimentos do Jobs de Alteração Salarial e Afastamento
Job para os Históricos Salariais
Cada alteração salarial deve gerar um registro S-2206, como a alteração salarial pode ser disparada de diversas rotinas, consideramos mais seguro gerar a partir dos Históricos Salariais, a partir de JOB.
Todas essas ações originam dados em SR3/SR7 - Tabelas de Alterações salariais, e são destas tabelas que o JOB buscará os dados para a geração do registro S-2206
Para configuração, siga os passos do documento:
1 - Preencher o MV_DTCGINI com a Data que indica, a partir de quando as alterações salariais serão consideradas no JOB
Atenção: O MV_DTCGINI representa a data de inicio da entrega dos eventos não periódicos que pode ser diferente para cada grupo de empresas, ou seja, o eventos serão enviados a partir da data informada no parâmetro.
2 - Em SIGACFG\SCHEDULE\CADASTROS realize a inclusão da rotina para o Schedule:
3 - Inclua a função de Agendamento:
4 - Inclua a função e as empresas que a rotina será executada.
5 - Após a confirmação da empresa\filial, é só terminar o preenchimento dos demais campos e configurar a quantidade de acionamento da rotina:
6 - A janela abaixo é apresentada a tela de acionamento:
7 - Configure agora os agentes, que são os responsáveis por executar as funções:
Possibilidades de cadastrar uma alteração salarial:
Job para integração afastamento
Conforme regras de Afastamento definidos pelo eSocial, o inicio e o fim de um afastamento são tratados em momentos distintos, devendo o "FIM" apenas ser enviado ao RET quando de fato ocorrer. Sendo assim foi implantada a integração de afastamento a partir de JOB.
A integração de um "fim" de afastamento, só pode ser enviada ao TAF quando o "inicio" do afastamento ja estiver transmitido e validado pelo RET. Caso contrario, o TAF não aceitará a inclusão do "fim" do afastamento pelo SIGAGPE.
Para configuração, siga os passos do documento:
1 - Preencher o MV_DTCGINI com a Data que indica, a partir de quando os eventos Não Periódicos serão consideradas no JOB
Atenção: O MV_DTCGINI representa a data de inicio da entrega dos eventos não periódicos que pode ser diferente para cada grupo de empresas, ou seja, o eventos serão enviados a partir da data informada no parâmetro.
2 - Em SIGACFG\SCHEDULE\CADASTROS realize a inclusão da rotina para o Schedule:
3 - Inclua a função de Agendamento:
4 - Inclua a função e as empresas que a rotina será executada.
5 - Após a confirmação da empresa\filial, é só terminar o preenchimento dos demais campos e configurar a quantidade de acionamento da rotina:
6 - A janela abaixo é apresentada a tela de acionamento:
7 - Configure agora os agentes, que são os responsáveis por executar as funções:
Parâmetros eSocial SIGAGPE
| Parâmetro | Descrição |
|---|---|
| MV_RHTAF | Parâmetro que habilita a integração dos eventos NÃO PERIÓDICOS com o TAF/Middleware, somente pode ser habilitado após a Carga Inicial ter sido transmitida para o RET com o retorno de Enviado com Sucesso. |
| MV_EFDAVIS |
Parâmetro utilizado para avisar ao usuário que campos obrigatórios do eSocial não foram preenchidos.
Cadastro de Funcionários - Versão 12Como não há integração offline do cadastro de Funcionários, mesmo que este parâmetro esteja configurado para não impedir o processo (0 ou 2), caso o MV_RHTAF esteja habilitado, a gravação na SRA não será efetuada. |
| MV_EFDMSG | Quando habilitado apresenta mensagem informando que o evento foi enviado ao TAF/Middleware com sucesso (válido somente para eventos não-periódicos) |
| MV_DTCGINI | Neste parâmetro o usuário informa a data que devem ser consideradas as alterações salariais, ausências. |
| MV_FASESOC |
Informar Branco, 1 ou 2, indica a fase do eSocial que o funcionário está. |
| MV_XMLGPE | Habilita a geração dos arquivos XML enviados do GPE para TAF, na pasta System. |
Parâmetros eSocial TAF
| Parâmetro | Descrição |
|---|---|
| MV_TAFVLES |
Versão do Layout do esocial |
| MV_TAFINIE |
Data de inicio da empresa no esocial |
| MV_TAFINI |
Data inicio dos eventos não periódicos |
Parâmetros eSocial Middleware
A configuração dos parâmetros a seguir é realizada através da rotina do Assistente de Configuração de Parâmetros/Certificado Digital.
| Parâmetro | Descrição |
|---|---|
| MV_MID | Ativação ou Desativação do Middleware. Ex.: .T. ou .F. |
| MV_APIMI01 | Endereço e Porta do serviço REST configurado. Ex.: http://localhost:8060 |
| MV_APIMI02 | Nome do Serviço, Classe e versão da API Setup utilizada pelo Middleware. Preenchimento automático, podendo ser ajustado manualmente. |
| MV_APIMI03 | Propriedade registrationType. Tipo da Entidade a ser criada: 1 - Pessoa Jurídica; 2 - Pessoa Física |
| MV_APIMI04 | Propriedade registrationNumber. CNPJ ou CPF, de acordo com o preenchimento da propriedade registrationType, do parâmetro MV_APIMI03. |
| MV_APIMI05 | Propriedade UF - Sigla da Unidade Federativa. Ex.: SP |
| MV_APIMI06 | Propriedade companyName - Nome da Pessoa/ Razão Social da Companhia. Ex.: Empresa S.A. |
| MV_APIMI07 | Propriedade branchName - Nome Fantasia |
| MV_APIMI08 | Propriedade countyCode - Código do município conforme Tabela do IBGE |
| MV_APIMI09 | Nome do Serviço, Classe e versão da API de Envio e Consulta de eventos do Middleware. Preenchimento automático, podendo ser ajustado manualmente |
| MV_GPEMURL | Endereço e Porta do serviço TSS. Ex.: localhost:8081 |
| MV_GPEINIE | Data de Início da obrigatoriedade de envio dos dados da empresa para o governo. Ex.: 01/01/2020 |
| MV_GPEAMBE | Ambiente onde as informações serão enviadas: 1 - Produção; 2- Produção restrita |
| MV_BACKEND | URL do serviço REST configurado. Utilizar o Assistente de configuração |
| MV_GCTPURL | URL do serviço HTTP configurado. Utilizar o Assistente de configuração |
Produto: |
Protheus. |
Ocorrência: |
Parâmetros 1ª Fase esocial |
Passo a passo: |
Produto: |
Protheus. |
Ocorrência: |
Parâmetros 2ª Fase esocial |
Passo a passo: |
Produto: |
Protheus. |
Ocorrência: |
Parâmetros 3ª Fase esocial |
Passo a passo: |
Linha de Produto: |
Microsiga Protheus |
||||||||||||
Segmento: |
Serviços |
||||||||||||
Módulo: |
SIGAGPE - Gestão de Pessoal |
||||||||||||
Rotina: |
|
||||||||||||
Chamados Relacionados |
MRH-8170 |
||||||||||||
País(es): |
Brasil |
||||||||||||
Banco(s) de Dados: |
Todos |
||||||||||||
Tabelas Utilizadas: |
RFZ – Sucessão de Vínculos, SR8 – Controle de Ausências, SRA – Funcionários, CTT – Centro de Custo, SR6 – Turnos de Trabalho, RBW – Informações de Temporários, SRV – Cadastro de Verbas, RCE – Sindicato de Empregados, SRB- Dependentes CTT - Centro de Custo SIGAMAT SPA - Regras SRJ - Função |
||||||||||||
Sistema(s) Operacional(is): |
Windows®/Linux® |
||||||||||||
Versões/Release: |
11.80 / 12.1.17 |
Linha de Produto: |
Microsiga Protheus |
||||||||||
Segmento: |
Serviços |
||||||||||
Módulo: |
SIGAGPE - Gestão de Pessoal |
||||||||||
Rotina: |
|
||||||||||
País(es): |
Brasil |
||||||||||
Banco(s) de Dados: |
Todos |
||||||||||
Tabelas Utilizadas: |
RFZ – Sucessão de Vínculos, SR8 – Controle de Ausências, SRA – Funcionários, CTT – Centro de Custo, SR6 – Turnos de Trabalho, RBW – Informações de Temporários, SRV – Cadastro de Verbas, RCE – Sindicato de Empregados, SRB- Dependentes CTT - Centro de Custo SIGAMAT SPA - Regras SRJ - Função |
||||||||||
Sistema(s) Operacional(is): |
Windows®/Linux® |
||||||||||
Versões/Release: |
11.80 / 12.1.17 |
Linha de Produto: |
Microsiga Protheus |
||||||
Segmento: |
Serviços |
||||||
Módulo: |
SIGAGPE - Gestão de Pessoal |
||||||
Rotina: |
|
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas