Passo a passo: | A integração entre o Protheus e Swile ocorre para envio de Benefícios calculados. Os dados integrados são: - Filiais (SM0) - Grupos de Benefícios (RUA) - Funcionários (SRA) - Pedidos (SR0)
Além das tabelas citadas acima, existe também a tabela RFP que armazena os Tipo de Benefício + Código Swile. Recomendamos por boas práticas que ela seja Exclusiva.
Para que o Funcionário seja integrado, é obrigatório que exista em seu cadastro: > Email > CPF > Celular
OBS: para facilitar o entendimento, foram inseridos prints dos processos em todo o passo a passo. Todas as palavras em 'azul', representam uma imagem, para abri-la, basta clicar em cima da palavra com o hiperlink. Exemplo da uma imagem anexada a nossa documentação aqui.
Deck of Cards |
---|
| Card |
---|
| Para que a integração aconteça, é necessário que exista um ambiente criado na plataforma Swile e usuário/senha. O cliente conseguirá esses dados através do time Swile, ou seja, no momento de configurar a implantação no Protheus, ele já terá estes dados em mãos.
Para os testes do time de Suporte, serão utilizados os dados do ambiente TESTE abaixo: > URL da Plataforma: https://qa.veedigital.com.br/FinancialBackend/rest > Usuário: totvs.qa.flex > Senha: !Qaz3edc
Os parâmetros que devem ser preenchidos com estes dados são: → MV_APISWI1 → MV_APISWI2 → MV_APISWI3
|
Card |
---|
label | 2. Criação dos Menus |
---|
| Para que seja possível o envio dos dados e consulta das informações integradas com sucesso ou não, é necessária a inclusão de algumas rotinas no menu do SIGAGPE.
Para isso, acesse o Configurador - Ambiente - Cadastros - Menus - desmarque todos os menus e selecione apenas o 'Gestão de Pessoal' - clique em OK.
Adicione todos os menus do SIGAGPE à direita da tela para que não tenhamos problema com as demais rotinas existentes no módulo. Para melhor visualização, optei por criar uma nova 'pasta' de menu, chamada Swile. Você pode definir onde ela será criada, no meu exemplo, criei esta pasta dentro da opção 'Atualizações'. Para isso, basta posicionar em cima do menu já existente e clicar em 'Novo Grupo'. Será aberta uma nova janela, onde você deve informar o nome da nova pasta, após isso, dê um ok.
Após ter criado a nova pasta, posicione sobre ela e clique em 'Novo Item' para iniciarmos a criação dos menus. Vamos criar quatro três novas rotinas, que são: → De x Para de Cargos (GPEA944B) → De x Para de Departamentos (GPEA944C) → Integração (GPEM939) → Consulta (GPEM939B→ Grupos de Benefícios (GPEA950) → Integração Swile (GPEM940) → Consulta de Lote de Integração (GPEM940A)
Quando finalizar a inserção dos quatro três menus, clique em 'Gerar' - Informe o Arquivo SIGAGPE e Gerar novamente. Após finalizar, os menus já estarão disponíveis no SIGAGPE. OBS: faça esta etapa com o Protheus fechado, utilize apenas o Configurador nesta etapa. |
Card |
---|
label | 3. Criação dos Menus |
---|
| Para que seja possível a integração de dados do Protheus para o Quirons, bem como cadastro de usuário, senha e acesso à rotina de Monitor de Integração que possibilita que o usuário confira se o dado foi ou não integrado corretamente, será necessária a inclusão de três rotinas no menu do SIGAGPE através do Configurador, que são: • Carga Inicial - GPEM925 • Parâmetros - GPEM926 • Monitor - GPEM924 Para inclusão das rotinas no menu, é necessário acesso em modo exclusivo. Com isso, acesse o Configurador - Ambiente - Cadastro - Menus - selecione o módulo Gestão de Pessoal e Confirme: Posicione na primeira opção com o nome do módulo SIGAGPE e clique na opção Adicionar para que todos os menus existentes fiquem no painel à direita da nossa tela conforme exemplo: Os três novos menus podem ser adicionados em qualquer menu que já existe, mas também é possível criar um novo sub menu. No exemplo abaixo, decidi incluir um novo sub menu dentro do menu Atualizações. Para isso, posiciono no menu Atualizações e clico na opção Novo Grupo. Inseri como exemplo, o nome Quirons e com isso, o sub menu já fica visível para que consigamos incluir as rotinas. As rotinas devem ser incluídas com o nome de sua preferência, sendo importante apenas se atentar ao informar o nome do Programa (o fonte da rotina que está sendo incluída), Módulo que será o Gestão de Pessoal e Tipo que será Função Protheus, conforme este exemplo. Após finalizar as três inclusões, elas deverão aparecer no novo sub menu. Para confirmar os ajustes, basta clicar em Gerar - informar SIGAGPE e Gerar novamente. Caso não tenha conseguido incluir os menus, veja este vídeo: Incluindo Menus
Card |
---|
label | 4. Parâmetro envolvido na integração |
---|
| Para habilitar a integração no Protheus, é necessário configurarmos o parâmetro MV_RHNG com conteúdo .T. |
Definição de Benefício VT/VA/VR |
| A partir deste passo, teremos que fazer o cadastro dos benefícios que terão integração com a Swile, através das rotinas Cadastro de Vale Alimentação (GPEA013), Cadastro de Vale Refeição (GPEA012) e Meios de Transporte (GPEA140).
Como base para este teste, faremos a inclusão do benefício Vale Refeição , vinculado ao Código de Benefício Swile v51 - Refeição. OBS: a listagem exibida no campo 'Código de Benefício Swile' é obtida através do cadastro efetuado no sistema da Swile. |
Card |
---|
label | 4. Grupos de Benefícios |
---|
| Na rotina de Grupos de Benefícios (GPEA950), faremos o cadastro do grupo de benefícios existentes no Protheus, para vincular com os dados do grupo cadastrado na Swile.
Para isso, clique em Incluir, informe um Código e Descrição a seu critério, e no campo 'Grupo SWILE', informe o nome do grupo de benefícios existentes na plataforma Swile (no caso do time de Suporte, para os nossos testes, podemos informar qualquer nome neste campo). Na sequência, clique em Outras Ações - Carregar Benefícios. Nesta tela, você pode selecionar dentre os benefícios cadastrados no Protheus que possuam o campo 'Código de Benefício Swile', quais farão parte deste cadastro de Grupo de Benefícios. Após selecionar e salvar, na parte inferior da rotina serão mostrados os benefícios que serão vinculados à este Grupo de Benefícios, e estando tudo correto, basta Confirmar. |
Card |
---|
label | 5. Vínculo Funcionário x Benefício |
---|
| Através da rotina Atualização de Vales (GPEA133), faremos o vínculo entre o Funcionário e o benefício que criamos, neste caso, o Vale Refeição. Para isso, basta localizar o Funcionário e clicar em Manutenção. Posicione na aba correspondente ao benefício que será feito o vínculo, e informe os dados necessários nos campos 'Código' e 'Qt. Vale DUt.' e salve. Neste momento, você já pode fazer o cálculo do benefício através da rotina Cálculo (GP131CALC) de acordo com sua necessidade. Após isso, retornando na rotina Atualização de Vale, podemos ver que o benefício foi calculado para o Funcionário. |
Card |
---|
| Agora estamos prontos para iniciar nossas integrações =D
Para isso, vamos acessar a rotina Integração Swile (GPEM940) - Avançar até o passo 2 - Opções. Aqui, teremos a listagem dos dados que podemos integrar para a Swile, e a princípio, podemos ignorar os parâmetros relacionados à integração de pedidos. É extremamente importante que a ordem de integração seja respeitada conforme consta na rotina, caso contrário, não será possível mais a frente a integração de Funcionários e Pedidos. Inicialmente, podemos selecionar as opções Filiais e Grupos de Benefícios.
Após a integração dos dados acima, devemos retornar na rotina de Integração Swile e integrar os Funcionários.
Por fim, vamos integrar os Pedidos. Neste momento, é importante o correto preenchimento dos parâmetros, selecionando a Filial, informando as datas de Crédito do Benefício e Vencimento do Boleto, bem como selecionar a competência. Com isso, finalizamos a integração dos nossos dados com a Swile. |
Card |
---|
| Agora estamos prontos para iniciar nossas integrações =D
Para isso, vamos acessar a rotina Integração Swile (GPEM940) - Avançar até o passo 2 - Opções. Aqui, teremos a listagem dos dados que podemos integrar para a Swile, e a princípio, podemos ignorar os parâmetros relacionados à integração de pedidos. É extremamente importante que a ordem de integração seja respeitada conforme consta na rotina, caso contrário, não será possível mais a frente a integração de Funcionários e Pedidos. Inicialmente, podemos selecionar as opções Filiais e Grupos de Benefícios.
Após a integração dos dados acima, devemos retornar na rotina de Integração Swile e integrar os Funcionários.
Por fim, vamos integrar os Pedidos. Neste momento, é importante o correto preenchimento dos parâmetros, selecionando a Filial, informando as datas de Crédito do Benefício e Vencimento do Boleto, bem como selecionar a competência. Com isso, finalizamos a integração dos nossos dados com a Swile. | Card |
---|
label | 5. Configurando nossa URL para simular o envio do Protheus para Quirons |
---|
| Como não temos um ambiente Quirons para receber os dados, vamos utilizar a ferramenta Webhook para simular o Quirons, através do endereço https://webhook.site/#!/view Ao acessar o Webhook, será gerada uma URL única, e ela será usada nos cadastros do Protheus. No SIGAGPE, vamos acessar a rotina de Parâmetros que criamos no passo 3, e faremos o preenchimento desta forma: • URI = nossa URL única gerada no Webhook • Usuário e Senha = você pode informar seu email e qualquer senha, pois como estamos usando o Webhook, estes dados não serão validados efetivamente. Card |
---|
label | 6. Cadastro do Schedule |
---|
| A última etapa cadastral, se trata do Schedule da rotina GPEM923, para que os dados enviados através da nossa rotina de Carga Inicial, sejam gravados na tabela RJP, e com isso, o Schedule envie os dados da RJP para o Quirons através do nosso arquivo JSON. Para cadastrar o Schedule, será necessário acessar o Configurador - Ambiente - Schedule - Schedule. Devemos inicialmente cadastrar um Agent na opção de mesmo nome, levando em consideração: • IP = como faremos apenas testes em ambiente interno, podemos informar localhost • Porta = se trata da nossa porta TCP, contida no arquivo appserver.ini do nosso ambiente Após o cadastro, nosso Agent deve ficar com status Habilitado para o correto funcionamento. OBS: cadastre o Agent vinculado ao Grupo de Empresas em que a integração foi toda configurada. Por fim, vamos cadastrar o Job da rotina GPEM923, que será a responsável pelo envio dos dados da tabela RJP para o Quirons. • Para isso, vamos na opção Agendamentos e faremos a inclusão com a rotina GPEM923 • Na primeira parte do cadastro, informaremos a recorrência, ou seja, de quanto em quanto tempo queremos que o Job seja executado. Neste exemplo, estamos deixando como Sempre Ativo, ou seja, o Job sempre fará buscas na tabela por qualquer dado novo gravado, para que o envio ao Quirons seja feito em tempo real, porém, o cliente pode definir isso da melhor forma pra ele • Na segunda parte do cadastro, informaremos os dados do Grupo de Empresa, Filial e Módulo • Por fim, vamos conferir nosso cadastro para Concluir. Após o cadastro, o Job aparecerá com status Habilitado. Caso tenha dificuldade no cadastro de Agent e Job, veja este vídeo: Configuração do Schedule
Card |
---|
label | 7. Integrando dados do Protheus para o Quirons |
---|
| Com todos os cadastros necessários, estamos prontos para fazer nossa integração funcionar \õ/ No Protheus, vamos acessar a rotina de Carga Inicial e vamos selecionar os dados que queremos integrar para o Quirons. Após a confirmação de execução da rotina, ao consultar nossa tabela RJP, teremos o dado gravado corretamente, o que significa que podemos conferir o status do envio através da rotina de Monitor de Integração - GPEM924. Para isso, basta buscar o registro que tentamos integrar e clicar em Visualizar. No Webhook, assim que o Job do Schedule processar o envio, podemos conferir a estrutura do arquivo JSON com os dados integrados. Caso tenha dúvidas sobre o processo, veja este vídeo: Integrando Protheus x Quirons |
Card |
---|
| O Postman é uma ferramenta de mercado, onde conseguimos simular o envio de arquivos XML/JSON na integração via Mensagem Única (EAI), simulando integrações com o Protheus, ou seja, ao invés de termos que instalar o outro sistema e aprender como fazer o processo nele, usamos o Postman para simular os testes e validações necessárias. Link para baixar o Postman: https://www.postman.com/downloads/ Cabe ressaltar que usaremos o Postman apenas nos casos onde precisamos simular o consumo de dados no Quirons, por exemplo, se precisamos consumir os dados de um novo Centro de Custo cadastrado. Neste teste, usaremos o Postman para simular o consumo de dados no Quirons, por exemplo: nos casos onde foi cadastrado um novo Centro de Custo no Protheus, o usuário precisa acessar o Quirons, e através dele fazer o consumo deste dado, para que ele também exista no Quirons. Para isso, usaremos o método GET no Postman e também usaremos esta documentação para sabermos quais parâmetros são chave para que seja feita a requisição dos dados na nossa API. Simulando o consumo dos dados de um Centro de Custo: • devemos buscar na documentação os parâmetros que serão usados no nosso GET • acessar nosso REST, e procurar pela API informada na documentação, neste caso, a de nome payrollcostcenter. Ao localizá-la, clicar na opção For More Details. Aqui, vamos guardar os dados contidos no GET para usarmos na sequência no Postman • com o Postman aberto, criaremos um novo File e vamos iniciar o preenchimento do nosso GET. Primeiro, vamos informar o endereço do nosso REST + os dados copiados do GET do nosso REST • agora, vamos preencher os parâmetros conforme nossa documentação, informando manualmente um a um e contendo os dados do código de Filial e Grupo de Empresas. Com isso, poderemos ver que a barrinha do nosso GET ficará com todos estes parâmetros também • por fim, vamos clicar na opção Body - deixar marcada a opção None e clicar no Send Protinho, agora conseguimos visualizar o arquivo JSON contendo os dados do Centro de Custo de código 01, de nome Suporte Dica |
---|
| - A API RESTful é uma interface que dois sistemas usam para trocar informações de forma segura pela internet.
- Os Métodos existentes em uma API são como as ações que esta API permite que sejam realizadas através dela:
- DELETE: Método específico para remoção de dados, ou seja, permite deletar dados através da API;
- GET: Método para uma requisição que busca dados, ou seja, ele é usado para consultar dados através da API, não altera informações, apenas as carrega;
- POST: Método para uma requisição que envia dados, ou seja, é usado para inserir informações através da API;
- PUT: Método para atualização de dados, pode ser utilizado quando se deseja atualizar uma informação já existente.
|
| Card |
---|
label | 9. Fazendo um GET no Postman para simular o consumo de dados no Quirons |
---|
| Seu teste funcionou certinho =D Se tiver dúvidas, você pode assistir esse vídeo com o processo:Simulação via Postman x Protheus |
|
|