GRFGTS – orientações técnicas

GRFGTS – orientações técnicas

Esta matéria trata das orientações técnicas para a Geração da GRFGTS - Guia de Recolhimento do FGTS.
SUMÁRIO:
 

1. Modelo conceitual

Este modelo se pauta na tecnologia webservice, sendo que o fluxo de comunicação será sempre iniciado pelo aplicativo do empregador através do envio de uma solicitação de processamento.

Para todas as solicitações feitas para o webservice sempre será retornada uma resposta. Os serviços de processamento, compostos pelas solicitações de processamento de eventos, terão como retorno um protocolo único, que representa a confirmação de recebimento da solicitação, a partir do qual os andamentos/resultados dos processamentos solicitados poderão ser recuperados.

Os serviços de processamento síncrono, compostos pelas solicitações de consulta, terão como retorno o resultado da consulta solicitada, de acordo com os parâmetros informados ao serviço.

O protocolo de recebimento serve para a identificação dos processamentos, assim ao se fazer uma consulta a partir do protocolo será retornado o andamento/resultado, com os erros gerados pelo processamento, caso existam, de cada um dos pedidos gerados.

 

2. Padrão XML

A especificação do documento XML adotada é a recomendação W3C para XML 1.0, disponível em http://www.w3.org/TR/REC-xml.

 

3. Padrão de codificação

Alguns caracteres especiais devem ser evitados para não gerar erros quanto a codificação do documento enviado à infraestrutura de serviços CAIXA. Para isto será necessário substituir os caracteres pelas sequências de caracteres escape adequadas, conforme a tabela abaixo demonstra:

 

4. Padrão de comunicação

A comunicação será baseada em webservices disponibilizados pela infraestrutura de serviços CAIXA.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo HTTPS (SSL versão 3.0), com autenticação mútua, que além de garantir um duto de comunicação seguro na Internet, permite a identificação do servidor e do cliente através de certificados digitais.

 

5. Padrão de certificado digital

O certificado digital utilizado pela infraestrutura de serviços CAIXA deverá ser emitido por Autoridade Certificadora credenciada pela Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil.

Este deverá pertencer à série A. Existem duas séries as quais os certificados podem pertencer: A e S.

  • A série A reúne os certificados de assinatura digital utilizados na confirmação de identidade na Web, em e-mails, em redes privadas virtuais (VPN) e em documentos eletrônicos com verificação da integridade de suas informações.
  • A série S reúne os certificados de sigilo que são utilizados na codificação de documentos, de bases de dados, de mensagens e de outras informações eletrônicas sigilosas.

O certificado digital deverá ser do tipo A1 ou A3. Certificados digitais de tipo A1 ficam armazenados no próprio computador a partir do qual ele será utilizado.

Certificados digitais do tipo A3 são armazenados em dispositivo portátil inviolável do tipo smart card ou token, que possuem um chip com capacidade de realizar a assinatura digital. Este tipo de dispositivo é bastante seguro, pois toda operação é realizada pelo chip existente no dispositivo, sem qualquer acesso externo à chave privada do certificado digital.

Para que um certificado seja aceito na função de transmissor de solicitações este deverá ser do tipo e-CPF (e-PF) ou e-CNPJ (e-PJ).

Os certificados digitais serão exigidos no momento da transmissão.

Antes de ser iniciada a transmissão de solicitações à infraestrutura de serviços CAIXA, o certificado digital do solicitante é utilizado para reconhecer o transmissor e garantir a segurança do tráfego das informações na INTERNET.

 

6. Modelo operacional

Para solicitação de serviços relacionados à GRFGTS (Guia Regular do FGTS), o empregador deverá ter encaminhado previamente à eSocial as informações trabalhistas através dos eventos em arquivos eletrônicos contendo o cadastro inicial, tabelas, eventos não periódicos e eventos periódicos.

A CAIXA disponibiliza uma infraestrutura de conexão segura padronizada para publicação de serviços na web como webservices, a qual provê serviços de Conexão SSL identificada com certificados digitais que garantem a identidade do solicitante, confiabilidade e privacidade. Essa infraestrutura é composta por dois tipos de serviços: Síncrono e Assíncrono.

As solicitações de processamentos relacionados à GRFGTS serão executados de forma assíncrona através de webservices, com geração de protocolos. Haverá outro processo síncrono disponibilizado para a recuperação dos processamentos previamente solicitados nos serviços assíncronos, através dos protocolos recebidos.

 

7. Processos síncronos

O serviço síncrono pode ser de dois tipos: consulta e solicitação.

O serviço síncrono de consulta normalmente é a solicitação da obtenção da resposta de uma solicitação assíncrona feita anteriormente.

O serviço síncrono de solicitação normalmente é atômico e tem seu fim em uma única interação.

O processo de um serviço síncrono é o descrito da seguinte forma:

1. Aplicação chama o serviço utilizando um certificado digital;

2. O SSL é negociado com o servidor da infraestrutura de serviços CAIXA. Nesta etapa cria-se o canal seguro de acesso ao webservice;

3. O filtro de certificados revogados verifica se o certificado é de uma cadeia aceita pela CAIXA e se o certificado ainda está ativo;

4. O controlador da infraestrutura de serviços CAIXA obtém a configuração do serviço para poder processar a requisição;

5. O controlador da infraestrutura de serviços CAIXA confere se o XML enviado é válido conforme seu XSD;

6. O controlador da infraestrutura de serviços CAIXA obtém os dados das tags informados na configuração;

7. O controlador da infraestrutura de serviços CAIXA posta a solicitação na fila configurada;

8. O controlador da infraestrutura de serviços CAIXA procura a resposta na fila de resposta configurada através do MQID da solicitação pelo período de “timeout” configurado;

9. O controlador da infraestrutura de serviços registra em banco de dados a solicitação;

10. O controlador da infraestrutura de serviços obtém a resposta e envia para o cliente, ou monta uma resposta compatível com SOAPFAULT informando o erro.

 

8. Processos assíncronos

O serviço assíncrono serve para solicitação de serviços que possuem um tempo significativo de processamento e, como dito anteriormente, retorna apenas um protocolo para utilização posterior.

Este tipo de serviço pode ser utilizado também para respostas que possuem dados muito volumosos e que não serão obtidos pelo mesmo canal e sim por outro mais apropriado.

O processo de um serviço assíncrono é o descrito abaixo:

1. Aplicação chama o serviço utilizando um certificado digital;

2. O SSL é negociado com o servidor da infraestrutura de serviços CAIXA. Nesta etapa cria-se o canal seguro de acesso ao webservice;

3. O filtro de certificados revogados verifica se o certificado é de uma cadeia aceita pela CAIXA e se o certificado ainda está ativo;

4. O controlador da infraestrutura de serviços CAIXA obtém a configuração do serviço para poder processar a requisição;

5. O controlador da infraestrutura de serviços CAIXA confere se o XML enviado é válido conforme seu XSD;

6. O controlador da infraestrutura de serviços CAIXA obtém os dados dos tags informados na configuração;

7. O controlador da infraestrutura de serviços CAIXA posta a solicitação na fila configurada;

8. O controlador da infraestrutura de serviços CAIXA produz o protocolo;

9. O controlador da infraestrutura de serviços CAIXA registra em banco de dados a solicitação;

10. O controlador da infraestrutura de serviços CAIXA monta o XML de resposta para envio do protocolo ou monta uma resposta compatível com SOAPFAULT informando o erro.

 

9. Respostas e controle de erros

As respostas dos serviços da infraestrutura de serviços CAIXA são sempre XML seguindo a seguinte lógica:

Serviços Síncronos: XML definidos pelas aplicações inquilinas, e

Serviços Assíncronos: XML definido pela infraestrutura de serviços CAIXA informando o Protocolo.

 

10. Procedimentos de contingência

O procedimento de contingência para a indisponibilidade do acesso aos webservices é a utilização do acesso online.

 

11. Padrão de mensagens dos Webservices

Os métodos de solicitação de processamento e de consultas dos webservices da infraestrutura de serviços CAIXA foram projetados para receberem mensagens no padrão XML como parâmetro de entrada dos métodos, assim como retornar mensagens no padrão XML.

 

12. Informação de controle e área de dados das mensagens

As alterações da estrutura de dados XML realizadas nas mensagens são controladas através da versão definida no namespace do Schema. A identificação da versão dos Schemas será realizada com o acréscimo do número da versão como sufixo no namespace do XML.

 

13. Validação da estrutura XML das mensagens dos Webservices

O webservice disponibilizado pela infraestrutura de serviços CAIXA possui como entrada de dados mensagens utilizando a linguagem de marcação XML, as quais são validadas com os Schemas que as definem, e rejeitadas caso seja encontrada alguma inconsistência.

Assim, os aplicativos que fazem solicitações à infraestrutura de serviços CAIXA devem estar preparados para gerar os arquivos no formato definido pelo XSD definido pelo sistema inquilino.

 

14. Validação do certificado digital

Os certificados digitais devem ser utilizados nas conexões SSL de transmissão dos arquivos para a infraestrutura de serviços CAIXA.

Os Certificados Digitais utilizados no acesso aos serviços disponibilizados pela infraestrutura de serviços CAIXA deverão atender aos seguintes critérios:

 

15. Matérias relacionadas

eSocial; GRFGTS