Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

Informações
titleNota I

Antes de realizar o envio dos adicionais de periculosidade / Insalubridade, observe que os atendentes devem estar alocados, os atendimentos das ordens de serviço devem ser gerados e deve haver período ativo para o mês que pretende lançar os adicionais, no módulo Gestão de Pessoal, referente ao código de processo do funcionário em questão. 

Informações
titleNota II

É importante notar que as configurações de adicional de periculosidade e insalubridade ficam localizados no orçamento de serviços, aba de Recursos Humanos. Os campos são os seguintes:

Campo:

Descrição

TFF_INSALU 

Indica a configuração de insalubridade para o item

 1 - Não possui

 2 - Integral

 3 - Proporcional

Exemplo:                                           

2 - Integral

TFF_GRAUIN

Indica o grau de insalubridade do item.

 1 - Nenhuma

 2 - Minima

 3 - Média

 4 - Máxima

Exemplo: 

3 - Média

Mais informações, vide documentação do Cálculo de Insalubridade

TFF_PERICU  

Indica a configuração de periculosidade para o item.

 1 - Não possui

 2 - Integral

 3 - Proporcional

Exemplo:

2 - Integral

Mais informações, vide documentação do Cálculo de Periculosidade


Figura 1 - Campos do orçamento de serviço, referente às configurações de insalubridade / periculosidade

Informações
titleNota III

No Cadastro de Verbas (GPEA040) informar N no campo "Lançamento Diário" (RV_LCTODIA), caso contrário apresentará a mensagem: "Data de referência não deve ser informada pois a verba não possui configuração para lançamento diário"

Image Added

Figura 2 - Campo do Cadastro de Verbas, referente às configurações de insalubridade / periculosidade

...

Deck of Cards
id1
Card
id1
labelParâmetros

Parâmetros

Figura 2 3 - Parâmetros da rotina de Envio de Adicionais de Periculosidade e Insalubridade


Campo:

Descrição

Atendente De ?

Selecione o primeiro atendente que será utilizado como parâmetro.

Para caso de utilização de todos os atendentes, não preencha esse campo

Exemplo:                                           


Atendente Ate ?

Selecione o último atendente que será utilizado como parâmetro.

Para caso de utilização de todos os atendentes, preencha esse campo com a letra 'z' em todas as posições.

Exemplo: 

ZZZZZZZZZZZZZZ

Data De ? 

Data inicial a ser considerada no envio de adicionais.

Exemplo:

01/01/2019 

Data Até ? 

Data final a ser considerada no envio de adicionais.

Exemplo:

30/01/2019 

Data de Referência ?

Data de referência a ser enviado para os lançamentos por funcionários.

Exemplo:

30/01/2019

Processamento? 

Indica se o processamento a ser realizado será de envio das informações ou então o estorno.

1 - Envio

2 - Estorno

Exemplo:

1 - Envio

Geração de Log?

Indica como deverá ser realizada a geração do log.

1 - Total (Os logs serão gerados para casos de sucesso ou erro)

2 - Apenas Erro (Os logs serão gerados apenas em caso de erro)

Observação

Os arquivos de log são gerados na pasta Protheus_data\system\gestaoservicos\-adicionais<yyyymmdd>.txt

Card
id2
labelMV_GSOUT

Esta rotina possui 3 opções de saída, conforme o conteúdo do parâmetro MV_GSOUT

  • Caso uma das opções de saída seja o Ponto de Entrada, a saída será definida no ponto de Entrada At353EvRH

Importante: Esta rotina não possui opção de saída em arquivo CSV. Caso haja necessidade, utilize o ponto de Entrada dessa funcionalidade 

  • Caso uma das opções de saída seja o Protheus, a saída pode ser verificada na rotina  Lançamentos por períodos (GPEA580) - do módulo Gestão de Pessoal - selecionando  o período ativo para o qual foram lançados os adicionais. 

Figura 3 4 - Visualização de lançamento de adicional de Periculosidade e Insalubridade, via rotina GPE580 (Lançamentos por Funcionário)

Card
id3
labelAPI REST

É possível utilizar a rotina "Envio de Adicional de Periculosidade / Insalubridade" via API REST.

É necessário possuir o fonte TECM353.prw compilado no repositório. O caminho da API é o api/tec/v1/SMInsalubrity/ e a requisição é através de uma operação de POST.

A tabela abaixo indica quais propriedades do JSON no POST correspondem com quais parâmetros da rotina:

PropriedadeParâmetroTipoObrigatório
employeeFromMV_PAR01textoSim, se não possuir a propriedade employees.
employeeToMV_PAR02textoSim, se não possuir a propriedade employees.
employees
arraySim, se não possuir as propriedades employeeFrom employeeTo
startDateMV_PAR03texto, no formato YYYY-MM-DDSim
endDateMV_PAR04texto, no formato YYYY-MM-DDSim
referenceDateMV_PAR05texto, no formato YYYY-MM-DDSim
operationMV_PAR06

numérico (1 ou 2)

1 = Envio

2 = Estorno

Sim
logTypeMV_PAR07

numérico (1 ou 2)

1 = Total

2 = Apenas Erros

Sim

A propriedade "employees" pode ser utilizada para listar quais atendentes (AB9_CODTEC) devem ser considerados.


Exemplo 1 de requisição:

{
"employees": ["D MG 01 000001", "D MG 01 000002", "D MG 01 000003"],
"startDate": "2019-04-01",
"endDate": "2019-04-30",
"referenceDate": "2019-04-15",
"operation": 1,
"logType": 1
}


Exemplo 2 de requisição:

{
"employeeFrom": " ",
"employeeTo": "ZZZZZZZZZZZZZZZ"
"startDate": "2019-04-01",
"endDate": "2019-04-30",
"referenceDate": "2019-04-15",
"operation": 1,
"logType": 1
}

A API pode retornar status 200 - OK caso algum lançamento seja incluso ou 400 caso nenhum lançamento seja processada. No retorno também existe uma propriedade "message" que exibe o mesmo retorno que seria exibido caso a rotina fosse executada via interface.

{
"message": "Funcionário 000001 / MATEUS BOIANI \r\n##Lançamento realizado com sucesso##Processo finalizado"
}

Saiba mais em:

Web Services REST/Server

Configuração REST do Protheus

FWRestModel - API RESTful dos modelos de dados do Protheus

...